122 replies to this topic

[SiCrane]

There are no 'bad' places of C++.

There most certainly are. std::locale is both under and mis-specified. Any non-trivial localization work requires implementation dependent information, defeating the point have having a standard library solution, and certain functions are useless because they assume single character returns when in actuality languages can have multiple character returns. Exception specifications outside of throw() are worse than useless, adding overhead without benefit, and even throw() has sufficient issues that C++11 had to introduce noexcept. Template export is only implemented in one compiler family and even they recommend against its use because the export specification has some consequences that the standards committee missed when they created it. Don't even get me started on the most vexing parse or the places where signed integers have undefined behavior rather than implementation defined behavior.

[SeraphLance]

All good answers guys, it was nice to read every single post confirming my biases that there's nothing unnecessary in the language, next time I read an article that has me challenge my assumptions about c++ I'll ignore it. Also using a subset for clarity seems like a good idea.

The question presented was whether there were any components to C++ that were so complex as to be unecessary. There are definitely unecessary parts to C++ -- Valarrays immediately come to mind -- but I'm not learned enough in the language to identify any language features that are unecessary out of overcomplexity (except the ultimate low-hanging fruit goto).

[larspensjo]

My own experience of C++ is that, for every good pattern to solve a problem, there are 10 bad ways of doing it. I needed a lot of time to learn that, and there are surely ways I don't know yet (and I don't know that I don't know).

[Mike.Popoloski]

C++ most assuredly has features that are too complex and/or arcane for their own good. Sure, they're "valid" features, but if you use one in your code you're going to get slapped upside the head during the code review. For example, overriding the comma operator

[larspensjo]

C++ most assuredly has features that are too complex and/or arcane for their own good. Sure, they're "valid" features, but if you use one in your code you're going to get slapped upside the head during the code review. For example, overriding the comma operator

It can be funny also, making practical jokes (not possible with proper configuration management).

#define struct union // Save memory

#define while if // Speed optimizer

[Bregma]

No, exceptions in C++ are a fundamentally different construct than exceptions in Java, they just happen to share terminology.

No, I kid you not. The Java exception runtime in gcj is the C++ exception runtime in g++. They do not just share terminology. They are the same runtime library. Java and C++ exceptions are conceptually and fundamentally identical.

[MichaelT]

...

Oh lord, another 'goto' topic.

Most production code really isn't very nice to look at. Just look at the source code for Doom 3 (https://github.com/TTimo/doom3.gpl) It's not exactly the most beautiful code out there, but it gets the job done, and in the end that is what matters most. And as a side note, the Doom 3 source code is littered with 'goto', so you can certainly use it. But as with any loaded weapons... handle with care.

[Yrjö P.]

Most individual things in C++ are useful (to someone, sometimes) and the language would be worse off if they weren't there, because they address a real problem with the rest of the language. The real issue is that there are so many of those problems, and a zillion features are needed to fix them, and the language as a whole is so complex and ugly. I figure it's just what you get when you add features piece by piece over decades, insist on near-total backwards compatibility for everything, and your starting point is the C language. So no, you can't avoid the bad stuff by not using certain features; the bad stuff is everywhere, even in C++ code that is valid C.

The very worst thing about the language is how it makes undefined behavior nearly impossible to avoid (Sicrane noted one instance, but there are a lot). Even if that kind of lack of safety was necessary for C++'s goals of best possible optimization and wide platform support, basic operations should be safe by default, and the coder should explicitly ask for the unsafe version in the <0.1% of situations when that is actually beneficial. Likewise, most things in the language should be const by default, and explicitly marked as mutating/mutable when necessary. That ties into how metaprogramming should be a matter of simply writing a bunch of code that has a const result, easy enough for most programmers to do, instead of the template metaprogramming hell of C++. Behavior of value/reference/move semantics should be visible and obvious. Name lookup should be fixed to be way simpler, and to work the same in different situations.

I haven't used D, but based on what I have read about it, it gets most of the things right which C++ gets wrong.

[Grafalgar]

For what its worth, compared to more recent languages, C++ does not strike me as overly complex right out of the box. C# and Java come with many more language features right out of the box, and the accompanying SDKs for both completely eclipse with what is considered "standard" for C++. Compare the SDK for Java against the STL for C++.

What makes C++ complex is what developers end up doing with it. What makes C++ tricky is memory and pointer management, which (imho) is the main reason most folks are hesitant to get well versed in the language. Exceptions? Meh. Classes? Meh. Templates? Meh. Pretty straightforward stuff.

To use an analogy - it's like saying a spoon is complex when you see someone using nothing but spoons to build a working zeppelin. Maybe that's a bit extreme, but yeah.

[ApochPiQ]

No, exceptions in C++ are a fundamentally different construct than exceptions in Java, they just happen to share terminology.

No, I kid you not. The Java exception runtime in gcj is the C++ exception runtime in g++. They do not just share terminology. They are the same runtime library. Java and C++ exceptions are conceptually and fundamentally identical.

The underlying mechanism is kind of orthogonal to the use cases though.

In C++, exception safety means RAII and a lot of care in order of operations. That means unwinding a stack can be expensive. In Java, you just let the GC deal.

[Kyall]

So for a future of clean c++ code, there doesn't necessarily need to be a complete revision of the language, but a definition of a sub set of the language that is the best practice usage. Is there a good wiki describing this available, or should I learn Dlang and then figure out the c++ equivalents and preference that equivalent subset in my coding?

[Telastyn]

So for a future of clean c++ code, there doesn't necessarily need to be a complete revision of the language, but a definition of a sub set of the language that is the best practice usage. Is there a good wiki describing this available, or should I learn Dlang and then figure out the c++ equivalents and preference that equivalent subset in my coding?

I would argue that the variety of styles and idioms used for the variety of C++ libraries, as well as the disjointed tacking on of syntax makes clean C++ code not just a simple subset of best practices for non-trivial code. I mean sure, you can make it more clean, but not *clean*.

As for D... I wouldn't bother. If it was going to take off, it would've done it by now.

[Trienco]

I am still of the opinion that exceptions are too costly to use for anything but exceptional situations.

To be fair, that's why they are called "exceptions" and not "common stuff happening" or "code flow control construct". As such you could easily argue that someone using exceptions for situations that aren't actually "exceptional" errors is probably using them wrong.

vector::at throwing at an invalid index is fine (it IS kind of a big screw up), std::find throwing if an element isn't found would be silly (as it's a perfectly expected case). Which leads to a nice anti-pattern called "expectation handling".

c++ is not too complex, just you need some dedication and you can easily learn the c++...
first try to learn c it will help you in learning c++ easily and in efficient manner..

dynamicmounting.com

Strangely enough, everytime I hear someone claim "C++ is easy" it is accompanied by "C with classes" and the person in question not even knowing enough about C++ and its countless dark corners to realize just how little he/she actually knows.

Edited by Trienco, 01 December 2012 - 01:18 AM.

[Kyall]

I've been learning D today, and I would like to put forward a request that someone make a D board on these forums. Just because the forums on dlang have so many boards, and so few replies. D for dead as a dodo I guess. I reckon using D for game programming where the D is built on top of c/c++ would be a move worth trialing just because it'll reduce bugs and it suits game programming a little better. I'm trying to say this without insulting myself and other game programmers, but yeah... deadlines vs code quality; getting paid vs writing good code. It has a few interesting features, but the main part will be getting the benefits of all it's scope features & the gc. Normally I would be hating on a gc, eating up cycles when and grrr/rage. But it has the feature that you can use malloc to get around the gcc, and make a custom allocator which also gets around the gc as well as lets you use static memory for short-life objects (or everything if you're not scared of code that should crash, not crashing). Actually come to think of it I wouldn't mind turning off the gc altogether. Could that can't work without GC, shouldn't work, ever.

Anyone have any experience with getting C++ and D to work nicely together?

Edited by Kyall, 01 December 2012 - 02:28 AM.

[ApochPiQ]

There's no point in making a D forum here. Traffic would be abysmal.

D is an interesting but failed experiment in trying to make C++ suck less. Its lack of adoption and toolchain maturity is a serious problem, but not nearly as serious as the fact that moving to D from C++ is a painful process. If you're going to undergo the misery of converting massive legacy codebases to a new language, you may as well pick one that's better than D.

[whtemple1959]

You are going to laugh me right off the site but yes C++ is way too complex.

I thought I would explore the world of C++ programming. I managed to find the NeHE site where they have tutorials written in VC++ then translated into every know flavor.
Since I want my project to be cross platform I decided to take the first tutorial and compare VC++, Linux, and Mac. losw and behold there are like 3 different Linux translations that appear throughout the 48 tutorials, another discussion. So I copied the code into a spreadsheet and low and be hold not a single line of the 3 sources line up. I do not want to consider how the differrence between Intel and ATT syntax will further my confusion.
Now granted I come from a construction and accounting background, but I got to tell you every wall in the in the world since the invention of sheet rock is built with wall studs 16" on center. Every one states that C++ is a tool box well your tool box is cluttered.
On the otherhand I axcept that what you as programmers do is art and for that I am amazed. Andas such, as artists you all have your own style. Monet's little dabs and Picasso's odd balance. But, they all used the same brushes, the same base colors.
So I am more confused as ever after this mornings work. How can Qt and Code::Blocks, whom I thought would be the best tools for my project, can they claim to...code once, code less, deploy everywhere...with such differences in coding rules and styles? So I am starting to believe my 2 programer friends when they said I am in over my head. And, after posting on 5 forums and being "viewed" by over 200 people to have only one respond has given me the insight that I am not welcomed in this particular sandbox.
But I will figure this out and my 3 year old will get his learning game.

[Kyall]

It's not really hostility if you don't get more replies. We have this unfortunate thing of not posting replies when we're not completely confident we know this answer. So yeah... the best way to get help from programmers is asking directly....

[Oberon_Command]

The parts of C++ that should generally be avoided (unless necessary) is misusing C stuff rather than the C++ alternative.
For example fopen, malloc and goto could be replaced with ifstream, new (with smart pointer) and exception respectively.

Whilst the ability to use classic C stuff seems to make the language complex, I actually prefer the way C++ extends rather than reinventing the whole language again from scratch (such as C#).

Kindof like OpenGL is seemingly quite hard to learn for new developers because it still has all the old stuff rather than dropping it all and starting with a brand new graphics API.

how would you replace the goto in this bit with an exception

for (int bar =0; bar < 100; ++bar)
{
	 for(int foo = 0; foo < 100; ++foo)
	 {
	 	 if (foo * bar == 100)
	 	 {
	 	 	 goto loopBreak;
	 	 }
	 }
}

loopBreak:
	 printf("%d", 100);

The code I am presenting is not doing something usefull at all to be honest but imagine a difficult calculation going on over a grid in which if a certain condition is met you need to break out of both loops and continue the rest of the algorithm with the results already calucalted?

for (int bar =0; bar < 100; ++bar)
{
	 for(int foo = 0; foo < 100; ++foo)
	 {
		  if (foo * bar == 100)
		  {
               foo = 100;
               bar = 100;
               continue;
		  }
	 }
}
printf("%d", 100);

[Álvaro]

for (int bar =0; bar < 100; ++bar)
{
	 for(int foo = 0; foo < 100; ++foo)
	 {
		  if (foo * bar == 100)
		  {
			   foo = 100;
			   bar = 100;
			   continue;
		  }
	 }
}
printf("%d", 100);

So instead of a goto whose purpose is immediately obvious (you even get a label in whose name you can document what's going on), now we have code which expresses intent worse and requires changing the ranges in two places if they ever change. What if we now want to do something when the loops end without the condition ever being found? With the goto, you just put that code before the label; with the new code, there is really no obvious way of doing it. What if we are interested in knowing the values of foo and bar whose product is 100 beyond the loop? Again the old code was easier to adapt.

The only "advantage" of the second code is that it doesn't use goto, which as far as I am concerned is a ridiculous metric.

Edited by Álvaro, 01 December 2012 - 03:35 PM.

[Kyall]

I'm getting more and more into this D thing. An experienced programmer can write an interface and a unit test using the tools already embedded in the language, then get a junior to build the interface to pass that unit test. As only a mid level programmer myself I'm not the authority on this; but this gets rid of thick skulled juniors (like I was) doing things wrong right?