The C++ Standard Template Library is something which I've been taking for granted lately but every once in a while something happens that makes you stand back and appreciate the functionality it provides. Today was one of those days.
For reasons I'll not go into I encountered the situation today where I needed to take a hexadecimal value representing a 32 bit value and convert that into an IEEE 754 type single precision value. Fortunately after some looking around I found the entry on wikipedia which explained how a single precision value is represented in a 32bit binary value, at that point however I was having nightmares about bit shifting and XOR'ing with values to determine which bits were set!
Enter the STL, which allowed me to implement a solution which although maybe not as compact or efficient as other methods is at least easy to follow and maintain/comment. And it was all thanks to the bitset class which takes an unsigned long and represents it as an array of bits. From this point it becomes trivial to determine the sign bit, the 8 exponent bits and the 23 (plus 1 implicit) mantissa bits. So after a little reading and some coding I ended up with a method which reliably transforms hexadecimal strings (i.e. DEADBEEF) into single precision values.
Maybe not the most interesting of posts but I felt the need to share :)
Tuesday 21 April 2009
Thursday 16 April 2009
The D Programming Language
For some reason last night I decided to have a quick look at the D programming language, it's something I've looked at briefly in the past but only in passing and never really with much enthusiasm, not because it's a lousy language but because I just didn't commit the time to having a proper look.
As I had some time off today I figured I would have a slightly more in-depth look at the D language and set up my laptop so I could compile applications. D has two compilers available, the compiler from Digital Mars and the GNU D compiler, as only the latter is in the Ubuntu repositories I opted for installing this which was a simple case of opening a terminal and typing in:
sudo apt-get install gdc
All other dependencies were taken care of and a minute later I can compile D code. Next up was an editor, I wasn't to bothered about a fully fledged IDE as I don't like to use them when I'm learning a language as I prefer to make mistakes and learn from them, but syntax highlighting would be useful as it lets me know I'm on the right lines. To my surprise my favourite Linux text editor, Geany, already comes with D support which is great because Geany also has compile/build/run options from the editor which makes it a very easy editor to work with as you can compile your code without building it and identify errors without leaving the editor. It's probably also worth noting that after a very quick investigation it also turns out the GEdit (the Gnome text editor) has syntax highlighting for D as well and Code::Blocks also has built in support.
Now for the downer, unfortunately because D is still a fairly immature language there are very few tutorials or examples out on the web so it looks like if you want to get into it then it's largely a case of studying the language specification and standard library reference. Althought from doing this it's nice to see so much functionallity in the standard library including such wonders as threading, XML processing, networking as well as standard features expected such as generating hashes (via MD5), regular expressions and string manipulation. Also available through the standard library is support for specific windows and Linux calls which makes it easier to write platform specific code.
There is also under active development a seperate library intended as a replacement for the standard library called Tango which looks promising but it is under active development so doesn't necessarily provide stability of the standard library.
So what makes D so appealing as a language? Well for a start there is the C/C++/Java style syntax which makes it easy for programmers to pick up and read. Not convinced then how about memory management? That's right D utilises a garbage collector for managing memory which means that there is less emphasis on the developer to get it right, although that doesn't mean memory is no longer a concern, for instance variables should still be declared only in the scope for which they are required.
Also of interest is design by contract, this is an interesting concept which I'm going to spend a little longer investigating but essentially it means that when you write a method you can specify a contract which can state something like "If you give me a value which meets these conditions then I will guarantee that I will return a value meeting these conditions". So when a program consumes that method it enters into a contract with the method and if either party violates that contract then the call fails, it seems a little odd at first as you can do this by running checks in code on a methods parameters and return value but with the contract you outline the requirements formally, the intention being that the contract is not broken when the program executes if it does then the program fails and fails hard.
So where does D sit in a world with .Net and Java as the two main programming architectures? Is it a niche language, a hobbyist language or something that should be taken seriously? It's certainly to early to tell how life is going go for D but I hope it goes well, at the moment I would say that it falls into the hobbyist category as it certainly doesn't seem as mature as other languages but it is getting there which is why I don't think it will always stay a hobbyist language. So should it be taken seriously? Well, yes, because D is very much C++ done right and there is still a requirement for compiled langauges instead of ones running in a VM, I am sure there will be those who will recoil in horror at the thought of having a garbage collector managing memory but I think that they work and a good garbage collector can do as good a job as a good programmer who is on the ball with memory management.
I think the future looks promising for D, as long as it doesn't slow down in development and stays relevant then in a few years we may start to see it getting some decent commercial use. I for one will be spending a little more time looking into D and getting to know it.
As I had some time off today I figured I would have a slightly more in-depth look at the D language and set up my laptop so I could compile applications. D has two compilers available, the compiler from Digital Mars and the GNU D compiler, as only the latter is in the Ubuntu repositories I opted for installing this which was a simple case of opening a terminal and typing in:
sudo apt-get install gdc
All other dependencies were taken care of and a minute later I can compile D code. Next up was an editor, I wasn't to bothered about a fully fledged IDE as I don't like to use them when I'm learning a language as I prefer to make mistakes and learn from them, but syntax highlighting would be useful as it lets me know I'm on the right lines. To my surprise my favourite Linux text editor, Geany, already comes with D support which is great because Geany also has compile/build/run options from the editor which makes it a very easy editor to work with as you can compile your code without building it and identify errors without leaving the editor. It's probably also worth noting that after a very quick investigation it also turns out the GEdit (the Gnome text editor) has syntax highlighting for D as well and Code::Blocks also has built in support.
Now for the downer, unfortunately because D is still a fairly immature language there are very few tutorials or examples out on the web so it looks like if you want to get into it then it's largely a case of studying the language specification and standard library reference. Althought from doing this it's nice to see so much functionallity in the standard library including such wonders as threading, XML processing, networking as well as standard features expected such as generating hashes (via MD5), regular expressions and string manipulation. Also available through the standard library is support for specific windows and Linux calls which makes it easier to write platform specific code.
There is also under active development a seperate library intended as a replacement for the standard library called Tango which looks promising but it is under active development so doesn't necessarily provide stability of the standard library.
So what makes D so appealing as a language? Well for a start there is the C/C++/Java style syntax which makes it easy for programmers to pick up and read. Not convinced then how about memory management? That's right D utilises a garbage collector for managing memory which means that there is less emphasis on the developer to get it right, although that doesn't mean memory is no longer a concern, for instance variables should still be declared only in the scope for which they are required.
Also of interest is design by contract, this is an interesting concept which I'm going to spend a little longer investigating but essentially it means that when you write a method you can specify a contract which can state something like "If you give me a value which meets these conditions then I will guarantee that I will return a value meeting these conditions". So when a program consumes that method it enters into a contract with the method and if either party violates that contract then the call fails, it seems a little odd at first as you can do this by running checks in code on a methods parameters and return value but with the contract you outline the requirements formally, the intention being that the contract is not broken when the program executes if it does then the program fails and fails hard.
So where does D sit in a world with .Net and Java as the two main programming architectures? Is it a niche language, a hobbyist language or something that should be taken seriously? It's certainly to early to tell how life is going go for D but I hope it goes well, at the moment I would say that it falls into the hobbyist category as it certainly doesn't seem as mature as other languages but it is getting there which is why I don't think it will always stay a hobbyist language. So should it be taken seriously? Well, yes, because D is very much C++ done right and there is still a requirement for compiled langauges instead of ones running in a VM, I am sure there will be those who will recoil in horror at the thought of having a garbage collector managing memory but I think that they work and a good garbage collector can do as good a job as a good programmer who is on the ball with memory management.
I think the future looks promising for D, as long as it doesn't slow down in development and stays relevant then in a few years we may start to see it getting some decent commercial use. I for one will be spending a little more time looking into D and getting to know it.
Friday 10 April 2009
Assignment FAIL!
One of the things I've been having to do lately is make sure that my C++ complies with high integrity C++ rules and guidelines (HICPP) which though interesting has been a massive pain as I've gotten use to doing things in a certain way and now I have to double-check everything I write for compliance. One which takes more getting use to than most is the use of the comparison operator in control statements, normally I (along with most people I think) would do a check something along the lines of "if my value is equal to three then...", or
Now this is invalid in HICPP because a programmer could accidentally type "if (x = 3)" which of course is assignment instead of comparison, so the rule states that instead the comparison should be written as
The reason for this is that the former is perfectly valid C++ syntax and will compile and run (but not work), whereas the latter will cause a compiler error because you cannot assign a value to a literal value.
This is one of a few rules which I am likely to carry into my every day coding as it helps to prevent me from making stupid mistakes which as a human I am more than capable of making. Another one which takes only a little more effort but can save until problems is when looping over a collection, the rules state that instead of doing this...
It should be written as...
Which again makes sense as with the latter method you avoid problems if the length of your collection changes. Of course this doesn't work so well if the loop is suppose to change the size of the collection, but that's a reasonable exception.
int x = 3;
if (x == 3) { ... }
Now this is invalid in HICPP because a programmer could accidentally type "if (x = 3)" which of course is assignment instead of comparison, so the rule states that instead the comparison should be written as
int x = 3;
if (3 == x) { ... }
The reason for this is that the former is perfectly valid C++ syntax and will compile and run (but not work), whereas the latter will cause a compiler error because you cannot assign a value to a literal value.
This is one of a few rules which I am likely to carry into my every day coding as it helps to prevent me from making stupid mistakes which as a human I am more than capable of making. Another one which takes only a little more effort but can save until problems is when looping over a collection, the rules state that instead of doing this...
vectorvalues;
// Add values to collection
for (int i = 0; i < values.size(); i++) { ... }
It should be written as...
vectorvalues;
// Add values to collection
int size = values.size()
for (int i = 0; i < size; i++) { ... }
Which again makes sense as with the latter method you avoid problems if the length of your collection changes. Of course this doesn't work so well if the loop is suppose to change the size of the collection, but that's a reasonable exception.
Subscribe to:
Posts (Atom)