c++ love it or hate it?

yall forgot about Rust

Friends don't let friends program in C++.

Fact: No one likes C++ after 10 years of programming in it.

Fact: Those who like C++ know few other languages

Fact: Sussman touched my penis

The only unifying design principle of C++ as a language can be summed up with two words: premature optimization.

the truth about C++:

http://groups.google.com/group/comp.lang.lisp/msg/917737b7cc8510e3

I guess I'm neutral. After reading the FQA, I'm kind of disgusted, but I was pretty good at it. Although, I hate the fact that the standard library has basically nothing good.

>>68

Nine tenths of what this guy wrote is so crippled with prolix, obscure analogies and "deep" meaning ideas ("C++ is philosophically and cognitively unsound as it forces a violation of all known epistemological processes on the programmer"... what?) that the whole text becomes devoid of all sense, if there was any intended. The guy has no point to make; instead, he visibly wants to sound authoritative and deep (while, at the same time, he lazily forgets to proper capitalize words).

Unfortunately, that's what stains the programming communities: the programmer themselves. No language is good enough so that fond programmers won't behave as complete illiterate retards. (Some of them go even further in their ridiculous pretentions and attribute that to Asperger's, as Eric Raymond justifies in his famous "How to Become a Hacker" essay. I most deeply pity that guy.)

Curiously, this guy is from the Lisp realm, a supposedly (or rather claimed to be) distinct, enlightened space where more well selected people gather together. Yet, in my opinion, he behaves as badly as an emotionally impaired teenager writing suicide letters ("for more than a year after first exposed to C++ in a six-month project, I was actively considering another career"... oh wow!). From my experience, that's actually expected from the average cult-follower, which is somewhat why such (indeed good) languages acquire some strange, bad reputation among foreigner programmers.

In other words: again, the community propaganda is what defines better the reputation of a language than the language itself.

On to the topic. C++ has indeed a tough reputation as being an overcomplex, ill-designed language. It does have a number of important defects, a number which is actually much less than what is advertised, but which, in practice, makes the language usage difficult in certain scenarios. Compilation times are extremely long (though heavily ameliorated by using precompiled headers), compiler implementations are hostile to the programmer (confusing diagnostic messages, non-conformancies to the standard), complicated syntax which is difficult to master, and so on.

In my opinion, the most common mistake made by naive programmers, and the most common cause for criticism against the language, is that C++ is extense and difficult to master in its whole. That's a fact: C++11 has a 1300-page standard which encompasses a lot of syntax features and complex semantics. Nonetheless, the point of the language is not to "master" every aspect of it, or even worse, attempt to use every such feature in the same project. The language goal is to offer desired features to desiring programmers, in their particular cases, so that the programmer decides how to write his program in the best way.

Nonetheless, C++ has a number of interesting features. C++ has an interesting type system (which works, despite whiners who tend to always call out reinterpret_casts examples in order to argue it doesn't), some meta-coding features (templates, mixins), some support for object orientation (virtual dispatching, inheritance, polymorphism), error-handling through exceptions and, more recently, some functional programming support. Neither of these features are pristine-perfect; actually, many of them contains caveats and misdesigns, but most of them can be well circumvented with some discipline and practical knowledge. Small to mid-sized projects rarely touches C++ limitations in this aspect. Large projects employ pragmatic solutions (precompiled headers, modularization inside sub-libraries) for reducing the overall development complexity and gaining team productivity. Note that one of the most common denounced problems in C++ -- freestore memory management -- is actually rarely an issue; heap allocation is comparatively less used than stack allocation and, whenever it is used, programmers employ well-known tricks (shared and auto pointers) to handle them safely.

Even the C++ most idiosyncratic features have good practical usages. Templates are adequate for container libraries and type-generic functions. Multiple inheritance is a form of additively changing classes' behaviors, making them "be" several things at once, much similar to Java's "interfaces". References allow for pointer semantics when needed and without syntax issues (one can change from one to other when appropriate). Inner classes and namespaces elegantly wraps concepts inside a name or a class. "Friends" solve the very nasty problem of lack of modularization by roughly providing "package visibility" to (hopefully related) classes. Operator overloading increments semantics when used adequately, and so on. Good sense is imperative when using many of these features: a misused feature does not turn it into a design problem by itself, but the programmer's frustrations tend to aggravate bad feelings towards the language when problems arise.

Not that the decision of making C++ the all-in-one language is good, I particularly find that terrible. Even more, I believe "multiparadigm" languages are a priori ill-designed, since mixing different thinking processes inside the same syntax structure and execution environment is inherently bad. C++ programmers tend to have "idioms", which is a consequence of the forementioned fact: every C++ programmer (and thus every C++ program) has a particular trait, a projection of the programmer's known idioms in the source code, which in practice makes reading C++ a very complex task, and thus heightens the barriers of code integration and reuse.

In summary: C++ is not a (too) bad language, although it surely could be better (and C++11 did not evolve a bit in this sense). The main problem with C++ is that it gives a vast possibility of writing very bad and difficult-to-integrate code, and, what is worse, sometimes the community tend to regard such code as "expert" code (such as Boost, which is one of the most extreme abominations and ill-designed libraries known to me so far), but, again, this is community propaganda. On the other hand, C++ gives an adequate toolset for the programmer to drastically increase his productivity, at least when compared with other groundbase languages, such as C. Also, there are excellent frameworks for C++ (Nokia's Qt comes to my mind) that allows very quick development and deploy of extensively complex projects. Just look around: there are some brilliant (and beautiful) C++-written programs and libraries for use.

>>37

I pretty much end up doing this too. Especially if I want to target a specific platform, writing things in assembly for infinite performance~

>>38
D is gross; I'll keep my C-like C++.

>>71
D should be thought of as a better Java, rather than better C++.

>>72
Honestly, I don't really like it because of its relative obscurity (coming from a 99% C background) and high level-ness.

But I can appreciate it as a 'better java' I guess.

>>70
("C++ is philosophically and cognitively unsound as it forces a violation of all known epistemological processes on the programmer"... what?)

Try a dictionary. "epistemological" means "concerning the means of obtaining knowledge." The idea is that C++ expects you to know how your program works before you write it. His claim is that this, in reality, is never really possible. A C++ programmer must pretend he can anticipate ahead of time (like some kind of magic wizard) what the needs of the project are going to be. This is something like an anti-skill, if you ask me. You shouldn't need it. And yet, most every C++ programmer prides himself on this skill.

After writing C++ intensively for a few years, I agree with his ideas on how it affects your psychology. C++ makes you paranoid and untrusting. In a C++ project, if you drop one little detail from your head, something bad could happen. And it's very very hard to write something elegantly. So you become obsessed with "hiding" your code. Even the idea of someone LOOKING at something other than the nice facade you've put up scares the shit out of you. 

C++ has an interesting type system

It's interesting like a brain tumor is interesting, I guess.

Even the C++ most idiosyncratic features have good practical usages.

Because everything in C++ was designed with something particular in mind and then made to pretend to look like it has generic applications. If you can't see how backward this is, I pity you.

Almost every language feature in C++ is either very situational in utility or only there to plug up the problems in another feature. This isn't bad per se, but it causes bad behavior: people take the situational things and try to apply them to general stuff. You can't blame the people here. They are just victims of bad design. C++ is filled with intellectual traps.

I believe "multiparadigm" languages are a priori ill-designed, since mixing different thinking processes inside the same syntax structure and execution environment is inherently bad.

That's not an argument.

C++11 seems promising.

>>75
but LINQ seems better.

>>76
*grabs penis*

C++ sucks! Don't belive me, let's look at the first compiled line:
void main(void):
you already started and it has already 2 voids, by the end of the program it will be full of voids and will suck.

If you want a true program, pick one without voids.

>>1
Love it

>>75
Yep, like a different language. Very nice stuff.

>>76
Wtf? You should die.

>>78
Fuck you, troll.

>>72
Because "Better C++" is called   C  

hate it.

>>35

is this attitude serious? allocating memory manually is better for simple programs with a team of maybe 2 or 3 people. but once you get up to larger teams with bigger programs, garbage collection is faster than doing by hand. this has been proven over and over again.

managing state in your head is even worse than managing memory. it adds unnecessary complexity that makes the system less stable and less extensible. you should really read the humble programmer. if turing award winners can not effectively manage state in their hand, then i dont think you can. it leads to code that is untenable.

actor based models are the future of computation. we have about 2 generations of cpus before they cap out. we have more information in our hands than ever before, and if we want to make sense of it then we need to be able to run software on 1000+ machines with 100+ cores each.


i have yet to see a great programming mind say that garbage collection and stm are not useful.

C/C++ is a bubonic plague, while jews are the rats, who spread it.

>>82

If the way memory is allocated and deallocated is very well documented, it is possible for multiple people to manage it together. It is an extra complication that can be completely avoided by using garbage collection, but it isn't going to make collaboration impossible. Although if at least one developer makes assumptions about how memory is allocated/deallocated, and doesn't document the assumptions, then things will get confusing.

Another unrelated issue would be using an allocation scheme that ends up not being sufficient later on, IE, maybe some of the items in a container need to persist after the container is destroyed after all. It can be tedious to go back and redesign the container to fit this, after taking advantage of the restriction when writing other code. One could probably establish conventions for avoiding this problem though. Reference counting everything and then converting needless reference counting pointers to regular pointers later when the project is complete could be a good idea.

>>76
Ever seen Boost.Range?