Fog Creek Software
Discussion Board




C++ == Crap

In another thread, Curious points out the following:

"Nobody has problems with pointers in general, Everybody has problems with C/C++ pointers in particular."

Bravo, Curious!!!  I'm glad someone had the balls to say it.  The hipsters who designed C and C++ were utter retards.  They're so proud of their little minds that devised a language with so few keywords!  That because everything in the language is overloaded in fifty different retarded ways.  ("=0" means purely abstract class!?!?  That's *really* intuitive.  But, hey, that hipster didn't have to add a keyword!!!)

You're absolutely right, *nobody* has a problem understanding pointers, it's the idiotic syntax of that ridiculous language that makes it a difficult concept.  When I was learning C++, I can't tell you the number of times I had to look up what things like "char *( *(*var)() )[10];" meant.  Is it because I couldn't grasp the concept of 'pointer'?  NO!  My mind can wrap around things like algebraic topology quite nicely, so I'm gonna say that pointers aren't over my head.  It's because Ritchie and Stroustrup are imbeciles.  What sort of retard would decide to overload the indirection operator to also mean reference?!?  The two concepts are close enough in meaning that it almost seems like Stroustrup did it with the intention of making it difficult for beginners.

Let's face it.  That's exactly what it is.  People with small brains love the fact C++ has an artificially high barrier to entry.  This means that they can have jobs.  If languages were easy to use, only intelligent engineers would have jobs - having a retarded language like C++ means that idiots, too, can have jobs because they memorized the unnecessarily convoluted syntax.

By the way, would someone please tell me what was going through Ritchie's tiny little brain when he decided that making a languge case-sensitive was a really *cool* idea?

Long live Ada!

Anon
Saturday, January 18, 2003

Heh. Venting a little?  Personally I love C++.

Do you hear the four horsemen?
Saturday, January 18, 2003

"By the way, would someone please tell me what was going through Ritchie's tiny little brain when he decided that making a languge case-sensitive was a really *cool* idea?"

What's essentially wrong with that? Isn't this a feature that forces you to be more explicit when coding? The basic syntax of the code will also look approximately the same to someone different who's working on your code. Also, that allows for more identifiers in the appropriate scope, though you could argue whether an API which maps "isSet()" and "isset()" to different methods is a good designed one...

tired of PHP's case-insensitive function names
Saturday, January 18, 2003

Let me guess... you're working on a C++ project for a university class and the deadline is approaching?

WNC
Saturday, January 18, 2003

Just wait until your computer architecture/assembly language class!

sammy
Saturday, January 18, 2003

Correct.

Because those languages are poorly designed also leads to the plethora of buffer overrun bugs we see in both Unix and Windows.

Crusty Admin
Saturday, January 18, 2003

C++ is a "systems" language. It's an OOP artifice overlaid on the lowest possible level of language abstraction, namely C, that allows the programmer to know roughly what the machine level consequences of his/her actions are given most language statements. In other words - you can't predict what your code will compile to (assembly language wise) in most language environments that have late binding, garbage collection, etc. In C and in C++, you can. In my thinking, C++ is basically assembler wrapped up and presented in some VERY deceiving macros...!
I believe that C++ has been grossly misused as a general application development language in industry. Something higher level, be it Delphi or VB, should be used for most applications instead of C++. IE: you 'should' develop the core of a database engine or a language processor or a component in C++. You "shouldn't" develop a billing application in C++.
In short - I share your apprehension re: C++, even though I have developed many commercial projects in it. It's a risky pitfall filled tool.

Oh, yeah. To address your problems with pointer expressions some people use: there are MANY macho d*ckheads running around this industry whose little pet "hazing" exercize with hiring candidates is to give the candidate some stupid assed 5 level deep indirection involving pointer arithmetic. Managers who hire candidates via such tricks should be slapped around and humiliated...

Curmudgeon
Saturday, January 18, 2003

Buffer overruns don’t occur because C++ is poorly designed.  They occur because of programmer error.

Nick B.
Saturday, January 18, 2003

"What's essentially wrong with that? Isn't this a feature that forces you to be more explicit when coding? The basic syntax of the code will also look approximately the same to someone different who's working on your code. Also, that allows for more identifiers in the appropriate scope, though you could argue whether an API which maps "isSet()" and "isset()" to different methods is a good designed one... "

  I am going to have to somewhat agree with the original poster on this.  The mere fact that different identifiers can be spelled the same except for their casing I think can make for quite some confusion.

"Buffer overruns don’t occur because C++ is poorly designed.  They occur because of programmer error. "

  Well if a language allows you to commit more of the same error by mistake then I would count that as a strike against the language when comparing vs a language that in its syntactic grammar and consequential idioms prevents the mistakes in the first place.  Not saying with this if what I said applies to C++ in this particular case.

  In my opinion, I have grown to like C++ becuase of the control it gives you.  And at least for console game development (and I suppose embedded systems) it is quite nice.

  What I I would really like though is that the language is "cleaned up" so that idioms that are known to be harmful are at least not encouraged.  Also common "support code" that many do should be either made into a standard framework or make the language provide more robust support on it.

  I realize that many of the C++ annoyances is because wanting to make it backwards compatible with C.  I would be all for considering breaking such compatability although I realize this solution won't suffice in a lot of environments.

  Before someone says Java or C# let me still say that what I want wouldn't necessarily conclude Java or C# is the solution given C++'s efficiency in memory and degree of control - for the domains I am thinking about.

  (but yeah, if I could help and could be easily done I rather program in Java or C# in my main job)



 

Raist3d
Saturday, January 18, 2003

If you think Delphi (object Pascal) and C++ are all that different, I doubt you have a great deal of experience coding in either one. They are very similar. What goes on under the hood I wont pretend to understand, but the actual use of the language (syntax, etc.) is not all that radically different. So, you are either a) ignorant of one or both languages or b) such a flaming genius with compiler issues and machine language that you ought to write your own compiler.

Halfway Coder
Saturday, January 18, 2003

Halfway Coder, you obviously fit the role of sniveling coward trolling for a fight on the internet with someone that had no quarrel with you.


I find Delphi and C++ extremely similar in terms of the language itself, but vastly different in terms of the support for GUI and 'normal' application development when it comes to writing an application that a user can interact with. The VCL concept isn't found in any way, shape or form in C++ (w/ the exception of C++ Builder which is C++ on Delphi). That, plus Delphi's inherent support for string data types, is what distinguishes Delphi for most application development.


Oh, yeah, I have developed several shrinkwrap applications in Delphi, including the migration of a company's product line to Delphi. As well as similar "feats" in C++.


Now, if you want to continue to debate God knows what point, post code snippets here to discuss. Or stuff it.

See you in your parent's basement, junior...

Curmudgeon
Saturday, January 18, 2003

Curmudgeon,

sniveling? I have no respiratory ailments. 
coward? How am I a coward? Bravery has nothing to do with coding.

trolling for a fight? I picked a fight with what you said and made it personal, that was in error. For making it personal, you have my apologies. But I was not “trolling” for a fight. 

You might have a point about VCL.

Since you say: “I find Delphi and C++ extremely similar in terms of the language itself”
I see no point in posting code snippets. Debate has ceased.

I think you ought to post some more substantial proof of the poverty of C++.

I’m older than you might think.

Halfway Coder
Saturday, January 18, 2003

Halfway,

On the personal issue - apology accepted.


In the future - don't mistake experience and insight for arrogance, which is exactly what you did.  This connection that you inferred caused me to in turn suspect of you (as is generally the case with others, I've found) jealousy caused by personal insecurity on your part. True? I dunno. Work on it. (It just never ceases to amaze me, the truly stupid s*** that some people in this industry use to distinguish friend from foe... such as programming language affinity and opinions on technology. Life's too short.)


Anyway - I do not infer "poverty" in C++ - if you're looking for that, you didn't understand what I wrote.  C++ is a vast, rich language that is immensely more powerful than makes sense for the uses that it is commonly put to in industry. I think what the original post was really complaining about was the overcomplexity of most people's implementations in C++. There are so *many* ways to do things in C++, including overloading, virtual functions, and multiple inheritance, all of which can confuse a code designer, that many (most?) people get lost in the nuts and bolts.


C *is* close to machine language. How? You can use most compiler's 'asm' directive to dump the assembler output, and one can then observe, for instance, how local variable are allocated from registers or on the stack. In general, it's possible to tie C variables to memory locations, somehow. For just one example. And C++ is just C with a *lot* of name mangling added.


On language similarities: I have a few friends that are "stuck" in Delphi. I've unsuccessfully tried to persuade them that learning C++ would not be a huge conceptual barrier and would greatly increase their marketability. However, none of them have taken the bait. Go figure.

Curmudgeon
Sunday, January 19, 2003

"And C++ is just C with a *lot* of name mangling added."

Dead wrong.

There is a book by Stroustrup (I haven't the exact name right now) about the design of C++. All the points raised in the initial post are covered there. No, Stroustrup is not an idiot. No, I don't say you are too dumb to "grasp" it. The pointer example you showed is an example of bad programming. Mighty tools give freedom to bad programmers as well.

It's hard to learn C++ because of the interdependencies. For example lots of things start to make sense only once you get into Generic Programming and templates.

Yeah, C++ is a systems language, it may be a good idea to combine it with some other, safer language, just the way Joel does (C++ for the core, interface and business logic with VB).

Sebastian Wagner
Sunday, January 19, 2003

The book you're talking about is "The Design and Evolution of C++" by Stroustrup.    I used to get very frustrated with the language until I read this and realized the rationale behind some of the design decisions.

anon
Sunday, January 19, 2003


I would like to add something to the original post: Stroustrup (and Ritchie, given the fact that you mentioned him) are smarter than you.

Regards,

Leonardo Herrera
Sunday, January 19, 2003

Sounds like our little Ada programmer is having a bad day with pointers.  Golly.

When was the las time:

1. You saw an operating system written in Ada?
2. You say a device driver written in Ada?
3. Anyone wrote a project in Ada that wasn't a government contract?

Has the entire world gone mad??  What is all this C code crap running amok all over my machine?  What idiot wrote this?  Where is my beautiful wife? Where is my beautiful house?

Nat Ersoz
Sunday, January 19, 2003

Wow, what a great thread.


Everyone is shouting at the top of their lungs about the one true take on C++. Everyone posting here is wiser and more insightful and more wonderful than the next guy. The other guy's opinion is always invalid or incomplete. Any summarizing comments are dismissed as complete ignorance. People's positions on technology are being taken as indication of their worth as human beings.


No wonder most companies cordon off hard core technology people as interpersonally repulsive and put them in their own sandbox to duke it out...

Fly on the wall
Sunday, January 19, 2003

Fly on the wall == Crap

brought to you by the letter m
Sunday, January 19, 2003

Well, the aim wasn't to call the Bell Labs staff names, or to
scare away the non-techie population. There is a point
here about the burdensome nature of C/C++: Using these
languages is in itself a herculean labour, in addition to the
unrelated task of programming.

People use C++ mainly, I think, for backward compatibility
reasons because there is so much of it around, dating to
the 80's. And I think it was adopted then because it was
more-or-less compatible with C, and there was a lot of C
around by that time. There is no discernible good reason
for why that happened, except perhaps C was easy to
write compilers for, especially on smaller machines
("worse is better").

C is actually a very bad language for systems programming
because while it provides the user with a lot of freedom
(by not including sophisticated or restrictive constructs)
it provides the user with very little power. The very absence
of limitations that supposedly make C "powerful" means
that the compiler cannot provide the programmer with any
high level guarantees, such as performance properties,
graceful failure, proved correctness or optimizations. There
aren't even any standard datatypes for things like Bytes or Characters - everything right down to sizes of types and
error handling behaviour are "compiler dependent".

This is why I disagree with ideas like "delphi is like c++" and
"syntax doesn't matter". Pascal is an inherently more
powerful tool than C, and if the same compiler is presented
to a user as a Pascal compiler he will be more productive
than if the very same tool is presented as a C compiler
(By the way, Delphi and C++ Builder are the same compiler
backend).

This weakness matters whether one is doing systems or
applications programming, and I can think of many systems
written in higher-level languages - the Crash Bandicoot playstation game was written in Lisp, the Cornell UNet
networking stack was written in OCaML, and of course
US military projects are written in ADA. I have never heard
of either Crash Bandicoot or the Space Shuttle having a
Blue Screen Of Death, and I think there's a lesson here.

Maybe the previous posters could have been more polite,
but please excuse them: they're venting because they are
being forced to use an inadequate tool by accidents of
history and economics. One may use C or C++ not because
it is good for one's task, but because of legacy code or the
lack of other compilers on one's target platform.

Curious
Sunday, January 19, 2003

So this is the forum where all the VB coders that don't "get it" hang out!  Get out of the industry people, you're dragging the rest of us down. 

brought to you by the letter m
Sunday, January 19, 2003

Dear "brought to you by the letter m",

Quite apart from my functional, database and applications
experience (using things like Miranda, Java, MatLab and
SQL, and NO Visual Basic), I have programmed embedded
controllers in 68HC11, 68000 and MIPS assembler, and
synthesized chips in VHDL.

So while I am pretty sure I get "it" (low-level coding)
better than you, you're right that I have difficulty "getting"
C++, just *possibly* because of the reasons I listed above
and to which you did not respond at all.

Had I made an error you could have pointed it out to me.
Instead, you seem to be posting exclusively ad-hominem
attacks, so I suspect you are trolling to provoke the readers
of this board.

Curious
Sunday, January 19, 2003

It seems like an impossible argument to win or lose. Unless one argues over false statements made by the proponents of one side or the other or unless one attacks the persons of one side or the other. To say that C++ and Delphi are the same is absolutely false. Paste code from one editor (say Builder) to another (Delphi) and it wont work. To say they are similar is a matter of extremely subjective argument. It is also subjective to say that one is better than the other. I have heard this argument (Delphi is better than C++) from the first time I actually was interested in software development about ten years ago or so and it still sounds like a completely impossible argument to solve.

I myself- who have coded in both C++ (which is really object C) and Delphi (which is really object Pascal)- do not know which is better. I know which I prefer, but that’s another matter.

Those who value economic arguments might say C++ is better. This is a very strong argument for any economic conservative. Just think of the wealth Bill Gates & Company has harvested from C/C++.

I imagine that much of the argument comes down to *how* each language is and has been used by a particular debater. And might even be simplified to “What language a particular programmer likes best.”

The question “Which language is better, C++ or Delphi?” can not be quantified. Other than to point out the different syntax for loops, data types, etc. in each language. Therefore, for true scientists, it can never be solved. For the religious, it is merely a matter of deciding what the appropriate book of revelation has to say on the matter. For my religion, I see that it says nothing whatsoever about it, so I remain an agnostic on the question.

WNC
Sunday, January 19, 2003

"I have programmed embedded
controllers in 68HC11, 68000 and MIPS assembler, and
synthesized chips in VHDL."

My god.  Yet you still don't get "it".  Pity the people that have to maintain your "low level" code.

brought to you by the letter m
Sunday, January 19, 2003

"I have never heard
of either Crash Bandicoot or the Space Shuttle having a
Blue Screen Of Death, and I think there's a lesson here."

The lesson:  Dumb people are better served using languages that have been dumbed down for them.

brought to you by the letter m
Sunday, January 19, 2003

I agree that Stroustrup presents convincing support for the complexity of C++ in "Design and Evolution..." But if you then read a book on say LISP or Python, you very quickly start questioning whether all that complexity is really necessary to achieve the same things as C++.

e.g. why does C++ need the STL - which is hard to use and VERY hard to implement well - to do the same things that LISP/Perl/Python etc. do with their simple runtime libraries?

Here's another example - yes it is "cool" that the programmer can define a new value type in C++ (i.e. a class that meaningfully supports copying and operators). But this one feature brings in a TON of complexity (e.g. unwanted copy constructors and assignment operators, and the near-impossibility of fitting a garbage collector to most C++ software). And then you ask yourself, what is this feature used for in the "real world"? Umpteen billion different "string" classes. What else? Not much. (And IMHO C++ would have been a much nicer platform if strings had really been part of the runtime...). I know there are science and graphics users who appreciate having value-type "vector" classes (I'm one of them), but really this is too much of a minority to justify such a monstrous language feature.

In summary, I think the designers of C++ were too focused on the principles of "make and check everything statically - do all the hard work at compile-time - require as little support as possible from the run-time library." e.g. The STL is what you get when you try to implement generic data structures with no runtime library. It works, but it's a monster.

I think the "do everything at compile-time" approach also led to C++'s mismanagement of headers and long compile times, but I won't get into that rant.

One thing I do credit Stroustrup for was introducing execptions (with automatic stack cleanup) into the C language framework. I believe this is a fundamentally superior approach to error-handling, and it's the feature I miss most when using plain C (in fact I can't live without it, so I wrote my own stack-cleanup framework for C...). Kernighan and Ritchie seem to have been feeling around this - I consider "errno" to be a distant echo of some attempt at non-local error handling - why don't UNIX syscalls return the actual error code rather than -1 and setting errno? Yet they stopped short of actual non-local exceptions.

Dan Maas
Sunday, January 19, 2003

Didn't read the whole thread, maybe someone already linked this but ...
here is a funny and relevant article:

http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm

Daniel Shchyokin
Monday, January 20, 2003

I think that one of the biggest problems with C++ is that it tries to cover too many different applications in one single language and ends up doing none of them particularly well.

For example raw pointers and memory access and full control over memory allocation is very important for a certain class of application, or if you need absolute control over it to be able to optimize. But for an average desktop application you want garbage collection and higher level containers that are "safe". The fact that C++ has to support the first makes it hard to do the second as it's too easy to subvert the garbage collection or safety using the low level factilites.

Strings are another example of high and low level stuff being too mixed. std::string at first sight looks great. But it doesn't work as a string! You can't pass one to the constructor for "ifopen" for example as a filename. You'd expect that as a file needs a name and a name is a string that you'd be able to pass a string to the function... But no. It needs a char*. Ok so it's easy enough to call c_str() but why do you need to?

And why doesn't string have simple things like the ability to make a string uppercase. Or functions to encode a unicode string into utf8 etc.

And don't get me started on templates... When templates were invented they looked like a really nice facility. But now the code written with them is almost incomprehensible in my opinion. Although I understand and use the "stl" parts of the standard library, I think they are a complete disaster. I know of few people who actually use more than a small part of the library.

A few years ago I liked C++ and enjoyed reading some of the well respected books. Like "effective c++" and one I forget the name of that's all about template idioms. Both extremely well wrtitten book that I used to like. Now I look at the with a sick feeling thinking that there is something fundementally wrong with a langauge which requires books like this. "Exceptional c++" is a great book in many ways but to me now it almost seems to be a catalogue of what's wrong with c++.

Basically I think the code langauge is 90% ok but the standard libraries are horrible. I'm always tempted to just ignore the standard libraries and build my own code for these thigns. I know better than to do that, but it's damn tempting.


Anyway, rant over. I use c++ daily for building applications so it's not all bad - but I'd rather use something more comprehensible for higher level applications (like C# - In my opinin java is even less useful than C++), and something like C if I ever have to do any low level stuff. Perhaps simple C++ as a better C with use of classes and virtual functions would be ok for that too.

John Burton
Monday, January 20, 2003

Interesting thoughts... I should point out that if you follow all the guidelines in "Exceptional C++" your software will be much more robust than a similar program developed without regard to exception safety. ("robust" meaning that your software will continue to behave predictably even if say a malloc()/new fails somewhere - just try failing a call to malloc() in most C code and see what happens :). The exception-safety one can achieve with careful C++ code is very significant, almost on par with the "atomic transaction" abilities of databases (as Sutter discusses).

However, despite the availability of these tools, you'd have to look very hard for a C++ programmer who can apply them correctly in his own work (I certainly don't qualify).

I'm sure the LISP/ML/Ocaml programmers out there are laughing hysterically at this point, since pure-functional programs are exception-safe by their very nature :). On the other hand, doing I/O and interacting with hardware in a purely-functional language gets to be "interesting;" perhaps as complicated as doing exception safety in C++...

Dan Maas
Monday, January 20, 2003

Fly on the wall said...

"Wow, what a great thread.


Everyone is shouting at the top of their lungs about the one true take on C++. Everyone posting here is wiser and more insightful and more wonderful than the next guy. The other guy's opinion is always invalid or incomplete. Any summarizing comments are dismissed as complete ignorance. People's positions on technology are being taken as indication of their worth as human beings.


No wonder most companies cordon off hard core technology people as interpersonally repulsive and put them in their own sandbox to duke it out... "


  Wow.  I have not seen a more accurate description of a thread in a long long time.  I sincerely hope my post did not add to that.

  Curious:

    Crash Bandicoot was not made in LISP, but it did use LISP for the AI of the entities in the game.  The rest was done in a mix of either C/C++ (can't remember which of the two ) and assembly.

      This does not undermine your point- just wanted to comment on that.  LISP would not have been fast enough to pull off the graphics that Crash Bandicoot is doing running on the PS1.

      I know there are some developers out there using LUA for AI/other tasks too, because they are easier also.  Witness also Unreal's Scripting language- which they actually use to code the AI and mods of the game.


   

Raist3d
Monday, January 20, 2003

> yes it is "cool" that the programmer can define a new value
> type in C++ [...]And then you ask yourself, what is this
> feature used for in the "real world"? Umpteen billion
> different "string" classes. What else? Not much.

It's used a lot. This improves proper designs a lot, if used properly. The complexity arising may turn out to be heavy, sure, but it's worth it when you're working on larger software.

> And IMHO C++ would have been a much nicer platform if
> strings had really been part of the runtime...

Not at all. It's good to be able to write superior versions (Unicode, faster, special cases, ...), give them the same interface and use them like you'd use std::string.

> And why doesn't string have simple things like the 
> [...] functions to encode a
> unicode string into utf8 etc.

I wouldn't call that a simple function, not if it is supposed to be platform-independent! The idea of having as much as possible in libraries instead of the core runtime environment is a good one IMHO.

> And don't get me started on templates...

Then use them and don't write them yourself. This is a feature that no other major language supports, it's mighty hard and it *does* give you possibilities way beyond "simpler" languages. All people who have few experience with Templates are allowed to cry out in anger now and call me names ;)

I think it boils down to C++ having lots of flaws and defects and most programmers using it should either learn more about it or start using other languages (C++ is used way too often IMHO). Even better: start interfacing C++ with other languages and use it where needed.

Also C++ provides facilities that are mighty strong and mighty hard to use right. They may change in future and not have their final form right now, but it's already impressive and usable. Just look at boost and Loki.

Sebastian Wagner
Monday, January 20, 2003

"Wow, what a great thread.
(snip)
No wonder most companies cordon off hard core technology people as interpersonally repulsive and put them in their own sandbox to duke it out..."

ROFL! My sandbox is more like a litter tray.


Monday, January 20, 2003

You see a plethora of buffer overruns because of programmers who don't care much. That has nothing to do with the language.

Passater
Monday, January 20, 2003

Another OO overlay of c is objective-c.  It minimizes pointer syntax though doesn't eliminate it.  It is 'less ugly' then c++ though not particularly intuitive.  I do find that it's narrower scope makes it easier to get forward motion.

If you want all your pointers under the hood, use java or c#

or better yet....python.

fool for python
Monday, January 20, 2003

C++ has a monetary cost and a cost in stability.  It does have benefits for large projects, but that's precisely where the stability issue comes in.  One or two good C++ developers won't get themselves into trouble, but it's hard to write a robust application in C++ with 100 developers.  Someone isn't going to get it or there will inevitably be a miscommunication between layers.

As far as speed, we're at a bit of a crossroads.  Most execution time is spent within APIs, SQL queries, etc.  The choice of language doesn't impact much relative to the underlying layers.

One of the delimmas with very high level languages is that they're often hindered by bad API support.  It will be interesting to see what .NET does to this.  One could introduce a brand new "ultra high level" language based on the CLR that could be used to actually do something.

Personally, writing C# code brings a smile to my face, knowing everything I don't have to do or worry about that I would've needed in C++.  For the small fraction of time you need raw power, there's COM interop, unmanaged code, unsafe code, etc.

No one really needs heat in their cars, or automatic starters, or power steering, or airbags, or a radio.  After all, race cars don't have there.  See the analogy?  We're not wusses, we're just lazy and lazyness is an important programmer trait.

Bill Carlson
Monday, January 20, 2003

"We're not wusses, we're just lazy and lazyness is an important programmer trait. "

Nevertheless, being pro-wuss does not support the notion that C++ == crap.  Correct?

Nat Ersoz
Monday, January 20, 2003

Nat, C++ == crap for some cases.  Yes, it can do most everything, but for many (most?) instances it's boated, unsafe overkill.  I've made a career out of C++, but I won't miss it, except when doing systems stuff.

Historically, C++ was a brilliant extension to C.  Nice abstraction of objects with minimal execution overhead (as long as you knew what was going on under the hood).

I think much rejection of C++ decendants (C#, Java) comes from people who enjoy the act of programming more than the results achieved.

Bill Carlson
Monday, January 20, 2003

Yeah - to follow up on my earlier post and agree with some of the comments.

C++ is a great language in many ways but over the years it's become far to complicated for most people to be productive in. C# for example is very nearly as powerful for most application type programs and it's far easier to write code in. And the library is much better.

boost and loki might well be great achievements but again they seems so complicated that it's hardly worth learning them. (And I do understand and use them so I can say this - but that doens't mean I like them)

John Burton
Tuesday, January 21, 2003

I dunno, John; destructors are awfully useful, and I don't see a lot of appeal in using a strongly, statically typed language which doesn't support templates.

Personally, I mean.  I do recognize that those languages have bits that others consider to offset those tradeoffs.

Danil
Tuesday, January 21, 2003

"If you want all your pointers under the hood, use java or c#"
or write a smart pointer. or just pick one off any decent website that caters to c++ developers


Tuesday, January 21, 2003

I used to have a fascination with programming languages.

Somewhere was the perfect language with a perfect library and completely orthogonal syntax.

Then I realized that I was bellyaching over nothing.  I came to the realization that I would probably hate coding with any programing language a certain percentage of the time, I would hate the OS and its associated APIs.  Every time that my environment would do nice things for me, it would, at the same time, drive me stark raving mad very likely using the exact same facet of the language.

And, really, there is no real difference between Pascal's pointer syntax and C++'s pointer syntax except that C++ makes no real difference between a pointer to a value and an array.  And that ceases to matter when you consider that boundschecking in Pascal is usually turned off for performance reasons, most memory bugs are a lot more subtle than going off the edge of an array, and you should be using STL vectors and iterators anyway in C++.  All that GC'd languages like Java and C# do is take away some of the power and give you other issues.  Memory can still stick around without you realizing this, and since you can't be sure that your destructor will be called, you can't be sure that resources reserved in an object will be unreserved when the object goes away.

All coders notice things that suck about their programming environments.  Wise coders know that even if they switched things around, all you do is exchange one list of gripes for another.  The best tool for the job is something that doesn't make your life difficult all of the time and is well supported. 

Oh, and C++ is getting better as new paradigms are discovered that use templates and operator overloading and other such things in new and innovative ways.  Only in C++ can you build a parser by simply typing the EBNF and letting templates and overloading do the work.  Only in c++ can you pick between functional programming, procedural programming, generic programming, OOP, and more.

This is why I love C++, even though it has driven me stark raving mad on numerous occasions.  This is why woodworkers use a table saw that can easily cut off your fingers or impail you on a flying piece of wood if you aren't paying attention.  Sometimes you need to be dangerous in order to get the job done right.  I used to *hate* C and C++ with a passion.

w.h.
Tuesday, January 21, 2003

Oh, and also the CLR isn't going to truly enable cool new languages to have API support.  You only can use the CLR if the exposed objects fit within the CLR object model, which is somewhere between Java's and C++'s object model.  You have to cut down C++, CLOS, and Python's objects to fit within the CLR and the GC'd language nicely.

One day I have the dream of writing a GC that provides more gurantees than the one with Java and CLR and at least enough gurantees to do exception handling and RAI (Resource Allocation is Initialization) correctly.  Of course, I'm not even sure if such a thing is possible given my decided lack of GC knowlege, but I can still dream, can't I?

w.h.
Tuesday, January 21, 2003

I agree with you about GC, wh. C# and Java have focused on collecting persistent objects with unpredictable lifetimes. But it is also important to have stack/LIFO/nested scopes with predictable destruction. I remember reading a looong Usenet thread lamenting C#'s inability to allocate an object "on the stack" (i.e. with deterministic cleanup as the scope is exited). Some possible solutions were discussed, and I hope future developments prove that persistent and stack-based memory management can co-exist.

From my own experience it seems that stack-based resource management is more important in non-interactive "batch" software, whereas persistent/unpredictable resource management is more important in interactive or GUI software. (probably because batch programs tend to have a linear or tree-like sequence of actions, whereas an interactive program dispatches from an event loop). Given that the initial focus of Java and C# was interactive software, their choice of persistent GC over deterministic stack GC makes sense.

Dan Maas
Wednesday, January 22, 2003

I am a learning (read struggling) programmer and I'd just like to thank everyone on this thread for pointing out the evident problems in each language. As sarcastic as this sounds, I actually am sincere.

But I'm STILL choosing to learn C++ :)

Anon
Friday, February 06, 2004

to anyone who thinks c++ is crap, I only have one ting to say to them:

Duff's device

send(to, from, count)
register short *to, *from;
  register count;
  {
        register n=(count+7)/8;
        switch(count%8){
        case 0:        do{      *to = *from++;
        case 7:                    *to = *from++;
        case 6:                    *to = *from++;
        case 5:                    *to = *from++;
        case 4:                    *to = *from++;
        case 3:                    *to = *from++;
        case 2:                    *to = *from++;
        case 1:                    *to = *from++;
                              }while(--n>0);
        }
  }

There's method to madness. Otherwise, just use Java or Visual Basic. Same thing...

H.C. Andersen
Saturday, April 17, 2004

A little history on how we got here.

C++ was commonly used because it was more-or-less completely compatible with the oceans of C code already in use in industry.  Now it's used because there's already alot of C++ code around, and C++ programmers to deal with it.

C started out as a portable assembly language - it let you develop something useful on machines with little memory and/or disk space and have some hope of getting it to run on another machine.  This was incredibly useful in the bad old days of minicomputers and 8088 PCs.  (yeah, I'm that old).  The C Runtime library wasn't much, but it was basically the same on all platforms and so most code could be moved without herculean efforts.

C++'s great weakness today is that it's added features until it's virtually unusable.  As a systems programming language it has merit, but the feature list is completely insane.  It's easily possible to find expert C++ programmers who can't read each other's code.  Operator overloading, templates, and the varying quality of STL support between compilers or even between releases of the same compiler make code increasingly hard to read and/or maintain.  For the basics of application development - screen handling and database access - virtually any language you can think of is better (even fortran is more readable for this, believe it or not).  For low-level control, assembly is still fastest, and C tends to be the most portable, though C++ can be used effectively here.  But if your goal is write-only code that even the developer who wrote it can't figure out a few months later, just use C++.  Be sure to design a complicated, multiple-inheritance tree, use plenty of operator overloading, and be sure to include lots of templates.  You can go for partial template specialization if you're really feeling masochistic. 

Hugh Jassole
Friday, April 30, 2004

*  Recent Topics

*  Fog Creek Home