C++ The Ultimate Language For All Time?
-
I've coded in: COBOL (2 years) Advanced Revelation (2 years) 4D on the Macintosh (1 year) Delphi (8 years) C# (2 years) (for both the desktop and the web). Given my background in these development environments, and my latest addiction to the managed aspects of C#, what are the biggest "gotchas" I can expect if I start coding in C++?
-
I've coded in: COBOL (2 years) Advanced Revelation (2 years) 4D on the Macintosh (1 year) Delphi (8 years) C# (2 years) (for both the desktop and the web). Given my background in these development environments, and my latest addiction to the managed aspects of C#, what are the biggest "gotchas" I can expect if I start coding in C++?
If ever there was a language designed to trap the unwary, it's C++. However, given your experience, it shouldn't be too tricky to pick up. Templates are probably going to be the main thing you haven't encountered, most newer C++ is very template heavy, and probably a little intimidating at first. Have a look at the Boost[^] library, it fills in many missing features from the standard lib that you would expect in a modern platform - serialisation, high level threading, regular expressions, signals(events) , decent string operations etc. Have fun :) Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
-
I've coded in: COBOL (2 years) Advanced Revelation (2 years) 4D on the Macintosh (1 year) Delphi (8 years) C# (2 years) (for both the desktop and the web). Given my background in these development environments, and my latest addiction to the managed aspects of C#, what are the biggest "gotchas" I can expect if I start coding in C++?
pointers. they look something like this void *pVoid;
-prakash
-
pointers. they look something like this void *pVoid;
-prakash
Delphi has pointers, though they are no where near as common as they are in C++. Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
-
Delphi has pointers, though they are no where near as common as they are in C++. Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
Ryan Roberts wrote:
Delphi has pointers, though they are no where near as common as they are in C++.
Are you sure its pointers? I guess its references. Not sure though. I just reminded him one of the "gotchas" in C++.
-prakash
-
I've coded in: COBOL (2 years) Advanced Revelation (2 years) 4D on the Macintosh (1 year) Delphi (8 years) C# (2 years) (for both the desktop and the web). Given my background in these development environments, and my latest addiction to the managed aspects of C#, what are the biggest "gotchas" I can expect if I start coding in C++?
Well havinga Delphi background mysefl, here's some things I found different, if not down right weird. Any comparisons I may make between Delphi and C++ is with Delphi 3 - haven't used the newer varieties. - with C++ you have the ability for a class instance to be declared either on the heap (same as Delphi) or on the stack. Both have pros and cons that you may need to way, depending on what you're doing. Since classes can be on teh stack in C++, this means the memory management and invoking of destructor's is done automatically. This leads to some useful patterns like RAII. - virtual methods won't work correctly in C++ constructors/destructors. This is by design, although I thinks it's silly. - no built in string type - lot's of string classes, of varying usefulness, but not as easy as it was in Delphi. - type casting is much easier in C++. This is a plus and a minus. It's possible to typecast a class instance into some other, valid type, but the resulting value still be "wrong". This is particularly tru with classes that use multiple inheritance. Using dynamic_cast helps out here, but it's the most expensive of the three casting operators ( static_cast, reinterpret_cast, and dynamic_cast), and it requires that the C++ RTTI system be turned on - very little RTTI support. - no try/finally construct. - operator overloading can be lots of fun, but you can also screw yourself too. Use wisely. - templates. The basics are not hard to get a handle on, but some of the more advanced things you can do with them will make your head spin. Plus the syntax is kind of ugly, or can be depending on how they are used. - C++ is not a single rooted class hierarchy. Unlike Delphi there is no TObject that everything defaults to. - no interfaces. You can fake this, but it's not quite the same :) - Multiple inheritance - cool, but easy to screw up if your not careful - see the "Deadly Diamond" effect. And then there's always "virtual" inheritance. - the mutable key word. I'm not going to go there. - the fact that no C++ compiler really implements the standard completely. Some come close, but all have their little nits, so you have to be careful how you write code if you want to be portable across compilers. - Macros - just don't use them, please, I'm begging you. -insanely slow compile times, especially compared to Delphi. To give you a comparison: 250K loc project would compile in 30 seconds in Delphi on a PII 233Mhz m,achine with 128Mb RAM. A 110K loc project in C++ would take 20 <
-
Delphi has pointers, though they are no where near as common as they are in C++. Ryan
O fools, awake! The rites you sacred hold Are but a cheat contrived by men of old, Who lusted after wealth and gained their lust And died in baseness—and their law is dust. al-Ma'arri (973-1057)
Actually they are! Classes are pointers! They can only be allocated on the heap (at least from a programmers perspective). The difference is that a Record type can be stack or heap based, and with records you need the "pointer" syntax because you can dereference them. With a class instance you can't deference it. This tends to make it clearer (IMHO) what's going on. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
Well havinga Delphi background mysefl, here's some things I found different, if not down right weird. Any comparisons I may make between Delphi and C++ is with Delphi 3 - haven't used the newer varieties. - with C++ you have the ability for a class instance to be declared either on the heap (same as Delphi) or on the stack. Both have pros and cons that you may need to way, depending on what you're doing. Since classes can be on teh stack in C++, this means the memory management and invoking of destructor's is done automatically. This leads to some useful patterns like RAII. - virtual methods won't work correctly in C++ constructors/destructors. This is by design, although I thinks it's silly. - no built in string type - lot's of string classes, of varying usefulness, but not as easy as it was in Delphi. - type casting is much easier in C++. This is a plus and a minus. It's possible to typecast a class instance into some other, valid type, but the resulting value still be "wrong". This is particularly tru with classes that use multiple inheritance. Using dynamic_cast helps out here, but it's the most expensive of the three casting operators ( static_cast, reinterpret_cast, and dynamic_cast), and it requires that the C++ RTTI system be turned on - very little RTTI support. - no try/finally construct. - operator overloading can be lots of fun, but you can also screw yourself too. Use wisely. - templates. The basics are not hard to get a handle on, but some of the more advanced things you can do with them will make your head spin. Plus the syntax is kind of ugly, or can be depending on how they are used. - C++ is not a single rooted class hierarchy. Unlike Delphi there is no TObject that everything defaults to. - no interfaces. You can fake this, but it's not quite the same :) - Multiple inheritance - cool, but easy to screw up if your not careful - see the "Deadly Diamond" effect. And then there's always "virtual" inheritance. - the mutable key word. I'm not going to go there. - the fact that no C++ compiler really implements the standard completely. Some come close, but all have their little nits, so you have to be careful how you write code if you want to be portable across compilers. - Macros - just don't use them, please, I'm begging you. -insanely slow compile times, especially compared to Delphi. To give you a comparison: 250K loc project would compile in 30 seconds in Delphi on a PII 233Mhz m,achine with 128Mb RAM. A 110K loc project in C++ would take 20 <
Thanks Jim, great reply. I thought you were going to cover the two most obvious ones which I know, but perhaps you missed them, because they are so obvious... 1. The code is based on files. Variables can be only allocated once, and it is done in the .cpp file. If you attempt to allocate a variable in a .h file, then you will get an error when the file is #include'd twice. 2. Memory de-allocation. For each time you allocate memory with a "new", you must de-allocate it with a "delete". The "delete" is (mostly) done in the destructor (the ~ method) of the class which allocated the memory. Make sure that you catch memory leaks as you go along, by inspecting the output from each run, rather than leaving it to later. Regards, Javaman
-
Thanks Jim, great reply. I thought you were going to cover the two most obvious ones which I know, but perhaps you missed them, because they are so obvious... 1. The code is based on files. Variables can be only allocated once, and it is done in the .cpp file. If you attempt to allocate a variable in a .h file, then you will get an error when the file is #include'd twice. 2. Memory de-allocation. For each time you allocate memory with a "new", you must de-allocate it with a "delete". The "delete" is (mostly) done in the destructor (the ~ method) of the class which allocated the memory. Make sure that you catch memory leaks as you go along, by inspecting the output from each run, rather than leaving it to later. Regards, Javaman
Good point. Which reminds me about the unit init and finalize (or something like that) syntax which is great for global initializations! - C++ doesn't guarantee when globally called constructor's will be called. You can have memory leaks in Delphi too. There is (or was, this may be different now) no automatic garbage collector. If you create a new instance of a class, someone has to free it, or you'll have a leak. The only reason it seems "automatic" is that if you create new components and add them to either a control or some other component, then the owner component will destroy all it's "child" component's. The stuff you add with the form designer works this way, so it seems like it's all magic, but it's not. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
Thanks Jim, great reply. I thought you were going to cover the two most obvious ones which I know, but perhaps you missed them, because they are so obvious... 1. The code is based on files. Variables can be only allocated once, and it is done in the .cpp file. If you attempt to allocate a variable in a .h file, then you will get an error when the file is #include'd twice. 2. Memory de-allocation. For each time you allocate memory with a "new", you must de-allocate it with a "delete". The "delete" is (mostly) done in the destructor (the ~ method) of the class which allocated the memory. Make sure that you catch memory leaks as you go along, by inspecting the output from each run, rather than leaving it to later. Regards, Javaman
Yes these are two "gotchas" for people coming from the same background as you. Since C++ is not a garbage collected environment (unless you're using Managed C++ or C++/CLI) then it's the programmers responsibility to ensure there are no memory leaks, hence the need for a "pairing" of new/delete. In practice, many people use "smart pointers" or "auto pointers" which are, respecitively reference counted pointer classes or pointer ownership classes. The syntax of C++/CLI (VS2005) is MUCH MUCH nicer than that of Managed C++ (VS2003) so use VS2005 if possible for an environment similar to that of C#. In this environment the same .NET Framework is available, but is access using a slightly different syntax. Namespaces are separated by :: and data members and functions are accessed using the . operator. good luck
-
Well havinga Delphi background mysefl, here's some things I found different, if not down right weird. Any comparisons I may make between Delphi and C++ is with Delphi 3 - haven't used the newer varieties. - with C++ you have the ability for a class instance to be declared either on the heap (same as Delphi) or on the stack. Both have pros and cons that you may need to way, depending on what you're doing. Since classes can be on teh stack in C++, this means the memory management and invoking of destructor's is done automatically. This leads to some useful patterns like RAII. - virtual methods won't work correctly in C++ constructors/destructors. This is by design, although I thinks it's silly. - no built in string type - lot's of string classes, of varying usefulness, but not as easy as it was in Delphi. - type casting is much easier in C++. This is a plus and a minus. It's possible to typecast a class instance into some other, valid type, but the resulting value still be "wrong". This is particularly tru with classes that use multiple inheritance. Using dynamic_cast helps out here, but it's the most expensive of the three casting operators ( static_cast, reinterpret_cast, and dynamic_cast), and it requires that the C++ RTTI system be turned on - very little RTTI support. - no try/finally construct. - operator overloading can be lots of fun, but you can also screw yourself too. Use wisely. - templates. The basics are not hard to get a handle on, but some of the more advanced things you can do with them will make your head spin. Plus the syntax is kind of ugly, or can be depending on how they are used. - C++ is not a single rooted class hierarchy. Unlike Delphi there is no TObject that everything defaults to. - no interfaces. You can fake this, but it's not quite the same :) - Multiple inheritance - cool, but easy to screw up if your not careful - see the "Deadly Diamond" effect. And then there's always "virtual" inheritance. - the mutable key word. I'm not going to go there. - the fact that no C++ compiler really implements the standard completely. Some come close, but all have their little nits, so you have to be careful how you write code if you want to be portable across compilers. - Macros - just don't use them, please, I'm begging you. -insanely slow compile times, especially compared to Delphi. To give you a comparison: 250K loc project would compile in 30 seconds in Delphi on a PII 233Mhz m,achine with 128Mb RAM. A 110K loc project in C++ would take 20 <