The journey of a life time.....

[Nigel Goodwin]

Hmmm... My personal opinion about the curly brackets is rather good... they keep the code logical and simply readable... it's not unclear where a function ends, and where it starts.

So do begin/end, and it's less ambiguous - it's far too easy to mistake which curly bracket is which!.

 

[ApochPiQ]

Just for starters:

C++ has a broken and horribly outdated compilation model. Direct textual inclusion of files and find/replace model preprocessing is a horrible evil. It worked fine in the 70's and 80's, but it's the 21st century now, and we have much more powerful machines. Closely related is the horrific lack of consistent namespacing support (e.g. see the behavior of enums embedded in a namespace). It's far better than C, since it has namespacing in the first place, but compared to alternative languages like the .Net CLR family it's pretty weak. Using templates in large codebases is effectively hell because of the compilation model.

Those are largely historical artifacts, granted, but then so is the backwards compatibility to C. Although C++ never would have succeeded without it, that single point causes a huge amount of mess in the language itself. How many people properly cast rather than using C-casts, for instance? C-strings versus string classes? There's a lot of baggage here, and due to the compatibility arrangement, many many people think that C and C++ are related. Worse, they write C code and call it C++, which is misguided at best and fodder for extremely poor-quality software at worst.

C++ also slaughters one of the points that made C so elegant: consistency. There are several semantic interpretations of operators like &. Worse, the use of angle brackets for template parameters leads to well-known issues with conflicting over the bitshift operators. Overloading the bitshift operators for stream IO is just gross. Some blocks require semicolon termination for consistency with C (since C permits instantiating structs/etc. directly from the definitions) whereas others do not (namespaces, etc.). Object constructors/destructors violate the "has a return value" convention of every other executable block of code in the language.

C++ is a minefield of corner cases and obscure errata; you literally have to memorize the language spec to know how to use the language safely in many cases. Consider temporary-value semantics: do you actually know all the cases where temporaries may be instantiated according to the standard? Sure, most people beyond the hapless-newbie level know to prefer preincrement to postincrement in order to avoid temp/copy overhead, but what about temporaries introduced due to implicit type conversions? What about all the other corner cases I can't name because I myself haven't memorized them all?

Here's a fun exercise: read the C++ language spec, and count the number of times the phrase "undefined behavior" is mentioned. A common joke is that C++ has more undefined behavior than defined behavior. Uninitialized variables, the handling of incomplete types, hell the existence of the very notion of incomplete types (artifact of the compilation model), the ability to perform bogus casts (which are impossible to catch at compile-time!), the behavior of destructors vs. virtual destructors, misuse of placement new/manual destructor calls, member availability semantics in class constructors... I could go on.

There are plenty of other flaws in the language itself - problems with what is there. But the real killer is what C++ doesn't have: higher-order functions (function pointers are a miserably poor hack), reliable multiple dispatch, proper support for subtyping (not to be confused with subclassing), pattern matching, garbage collection... look at a more powerful language and there are scores of features that would be nightmarishly fragile if not outright impossible to replicate in C++. Even C# has outstripped C++ in power with the 2.0 inclusion of anonymous delegates, and this promises to improve still further in the 3.0 language revision. Ruby's consistency and potency puts C++ to shame, although it has its share of flaws. Then there's the real heavy-hitter languages: the Lisp family, the ML family (particularly OCaml), Haskell, Erlang...


C++ is crap. The only reason it persists is a combination of self-reinforcing market inertia and historical accident.

 

[dknguyen]

So do begin/end, and it's less ambiguous - it's far too easy to mistake which curly bracket is which!.

I dunno...I mistake which being goes to which end all the time because the one it actually pairs up with gets lost in the other text in my code and doesn't jump out at me as a single curley bracket sitting all alone.

 

[Nigel Goodwin]

I dunno...I mistake which being goes to which end all the time because the one it actually pairs up with gets lost in the other text in my code and doesn't jump out at me as a single curley bracket sitting all alone.

Like I said before, it's all personal preference!.

 

[Marks256]

Can i use Borland C++ 5.02 for C? Or am i going to have to get a new IDE?

 

[Nigel Goodwin]

Can i use Borland C++ 5.02 for C? Or am i going to have to get a new IDE?

Well I don't 'do' C, but as far as I'm aware C++ is basically a 'superset' of C, so it should be OK for normal C programs.

Generally the Borland compilers are very good, and the fastest to compile.

 

[_nox_]

Well I don't 'do' C, but as far as I'm aware C++ is basically a 'superset' of C, so it should be OK for normal C programs.

Generally the Borland compilers are very good, and the fastest to compile.

hah ? The *IDE* itself is not important - But the compiler is!
I'd use Microsoft's C/C++ compiler Express Edition, plus their Express Edition 2005 IDE. That's the best.

 

[ApochPiQ]

Actually, it depends on what kinds of C programs you want to write. Borland will work fine for DOS and 16-bit Windows (i.e. 3.x and earlier). If you want to target modern versions of Windows, I'd recommend the Visual C++ Express Edition from Microsoft. For Unixes, go with the GNU Compiler Collection (gcc); the best Windows port of GCC is MinGW and comes with the (decent) IDE DevC++.

Of course, none of those will do you much good if you're intending to write code for an MCU - you'll need a special compiler for the hardware you're targetting.

 

[Marks256]

hah ? The *IDE* itself is not important - But the compiler is!
I'd use Microsoft's C/C++ compiler Express Edition, plus their Express Edition 2005 IDE. That's the best.

To me it is.

Actually, it depends on what kinds of C programs you want to write. Borland will work fine for DOS and 16-bit Windows (i.e. 3.x and earlier).

Yes, i know that 5.02 is for Dos, and 16bit Windows apps.

If you want to target modern versions of Windows, I'd recommend the Visual C++ Express Edition from Microsoft. For Unixes, go with the GNU Compiler Collection (gcc); the best Windows port of GCC is MinGW and comes with the (decent) IDE DevC++.

Already have a copy of it.

 

[Nigel Goodwin]

hah ? The *IDE* itself is not important - But the compiler is!
I'd use Microsoft's C/C++ compiler Express Edition, plus their Express Edition 2005 IDE. That's the best.

Depends if you like fast compilation?, Borland have always been far faster at compiling than Microsoft compilers!.

 

[_nox_]

Depends if you like fast compilation?, Borland have always been far faster at compiling than Microsoft compilers!.

Regarding the size of µC code ( or Console app code ), compilation time is negligible.

And the MS IDEs are more comfortable to use - don't forget Visual Assist by WholeTomato Software.

 

[kchriste]

Below is a link to my first attempt at porting a DOS Qbasic program to MS Quick C for DOS. If you look at the listings side by side it might help you see some of the differences between C and Basic.
**broken link removed**
Zip file includes source code in both Qbasic and Microsoft Quick C 2.5 showing how to use the FM music chips on the soundblaster and compatable cards. It is by no means ANSI C and won't compile without MODs on a Borland compiler ( _outtext etc will make Borland, and not to mention ANSI purests, barf ), but it will give you the basic idea.
BTW, how's your Z80 project comming along?

 

[Marks256]

Below is a link to my first attempt at porting a DOS Qbasic program to MS Quick C for DOS. If you look at the listings side by side it might help you see some of the differences between C and Basic.
**broken link removed**
Zip file includes source code in both Qbasic and Microsoft Quick C 2.5 showing how to use the FM music chips on the soundblaster and compatable cards. It is by no means ANSI C and won't compile without MODs on a Borland compiler ( _outtext etc will make Borland, and not to mention ANSI purests, barf ), but it will give you the basic idea.

Thanks, i will take a look when i get done with homework.

BTW, how's your Z80 project comming along?

Good! You are back! Well, i haven't done much this past week. Now that school has started, i have been swamped with work, so it has been put off a little. If everything goes well, i plan to try to write a bootstrap for it this weekend. The only thing that is holding me back is that circuit for programming the EEPROM. It isn't that it is complicated, it is just that it takes a lot of work. Too many jumper wires to make it. So, maybe this weekend i will have some time.

I have quite a bit going on right now. I am making a ppt presentation for my church(for confirmation), and i have a speech due tomorrow, so, i promise to have something done by next week. I showed it to some of my teachers, and they want to see it too, so it will get done soon!