It's been a while, but I think one of the "gotchas" that bites a lot of people is that internally copies to objects are somewhat common within the STL containers, even when you don't necessarily intend for it to happen. When a copy gets destroyed, it might invalidate the pointers of all other copies unless an explicit copy constructor is defined to make proper copies of pointers. Meaning, if you define a destructor to clean up heap memory, then you better make sure you also define a copy constructor that reallocates new memory for each copy so that internal copies don't invalidate the object. That's based a bit on ancient threads here, and a drunk's memory. I don't think it has ever bitten me personally, and I'm not sure about the semantics. But yeah, in general, C++ has lots of subtle semantics like that that can bite you in the ass. The saying goes, the more experienced you are with C++ the less you know (because you become aware of the too many gotchas to remember).

Actually, I have looked into assembly language. Many decades ago I used to code in assembly on my old C64 and I absolutely loved it. I looked into Windows assembly and it looks pretty good as well.

The thing is, C is as close as you can get to assembly without coding in assembly. Actually, you can include assembly code within C. I used to do it all the time back in the DOS days and loved it.

As for memory management, I have never had a problem with it in C. I love pointers, I am not afraid of them like most C++ programmers seem to be. When I allocate memory, I immediately write code to free it up again. It's just never been a problem.

When I need something similar to vectors, I wrote my own functions to do it. It's not rocket science, it was fairly easy to code and I enjoyed doing it.

C++ has it's own issues which have caused people to stop using the constructors and destructors and switch to unique pointers which have to be the ugliest things I can imagine. If you can remember to use them and how, than why can't you remember to simply write code to free the memory by hand in C?!

I see C++ to be a solution to a problem that just doesn't come up.

But hey, that's all just my opinion. If you like it and feel more comfortable using it, have at it, but DO NOT act like I am not staying current because I prefer to code in C or I will chew your fucking head off.

C++ is a walking design-by-committee. Don't let it scar you for better languages.

alias this=data; //<--- treat all uses of a superfloat as if it was superfloat.data
//(and if that fails, then try superfloat.whatever() as opposed to superfloat.data.whatever())

Actually, it's the other way around: first, try it with the new super_float struct, and if that fails, try it with the original thing, data.
Makes more sense this way.

Funny enough, my wife (who is studying computer programming at our local college) just had a lab assigned on using typedef.

I don't recall learning anything about using typedef when I took the same course over a decade ago ... but it could just be that I wasn't paying attention at the time because I already knew about it and how it worked.

bamccaig may be able to correct me on this?

I feel like C++ is trying to be two languages and sucks at both.

A "compatible" language going back to the 70's/80's. DON'T. FIX. ANYTHING. BAD.

A "new" language with "new" features (that D has had literally for a decade, ).

Then again, they don't add new features that are actually useful (or take literally 20 years to finally get around to doing it). MODULES?! MODULES?!?!?!? I think in c++17 they FINALLY added number separators (D has it!) so you can do 1_000_000. Meanwhile, Motorola C had it in ... the 90's, I know, I used it.

I actually saw a good video from expert/master-of-C++ Scott Meyers on why C++ is so terrible at the high-level decision making process.

(Only a few reasons because he's using them as an example to D devs, "don't be like this."--he says he's got tons more examples.) This is a great video to watch on C++ if you've got an hour to chill out.

I'm trying to remember one point he made though. He was saying that "everything in C++ has a reason." Why is this thing strange? Because of X interferes with Y. Everything has a reason... but... while every committee member has "their thing" and "their reasons" for it. IIRC, he's saying it suffers because there is no cohesive vision between all of them / everyone is afraid of breaking or changing anything. (See 43:00)

He also talks about (37:00) at Essential vs Accidental complexity. Essential is, the program has complexity. Accidental is, the language (or API, or whatever) sucks so you have to remember extra complexity where it's not needed.

"The only thing I have experience with that is more complicated than C++, is the US tax code. And to be fair, it had a couple hundred years to get complex." -- Scott Meyers

That looks like keyboard vomit to me. I mean, I get it, but typing "std::unique_ptr<Type>" is a ridiculous amount of typing to get something so fundamentally essential to using the language. That should be a SINGLE LETTER, or some other kind of small-number-of-symbols quick alias.

I know what you want, you know what you want, so why do you have to type out a string with angle brackets, colons, and underscores just to get there. And a real-world example would be even longer!

I mean look at this:

//(From a random github search)
std::unique_ptr<std::string> s(new std::string("hehe"));
std::vector<std::unique_ptr<std::string> > v;
v.push_back(std::move(s));

Every year... C++ becomes a little more like LISP.

{"name":"lisp_cycles.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/5\/e5b5612aa6ec954a824d349b4f020d45.png","w":640,"h":211,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/5\/e5b5612aa6ec954a824d349b4f020d45"}

Now contrast that with my a made up language:

^string s = "hehe";
^string[] v;
v ~= s.move;

//^ = unique pointer (<-made up)
// string is standard language feature (ala D)
// ^string[] is an array of strings (ala D) with unique ptrs 
// .move is move semantics. Probably could do even smaller with a character if needed often enough. 
// ~= is add element to array (ala D)

But you see how the "core" of what we're talking about doesn't need to be keyboard vomit? And the "what's going on" is fairly clear, even to someone who doesn't know the language? I didn't need to explain to you how, or why I choose language features. With a couple of comments, you knew all you needed to read my code and could read MORE code using the same constructs, without further comments to explain them.

To be clear, I'm not talking to "you" as if you're the owner of C++, or some huge proponent of it.

On a side note, I realize that most C-derived languages use - as a subtraction operator and the lack of any other kind of universal structure makes it impossible to use for other purposes, but note that - is much easier to type than _.

In Lisp, because "functions" / "operators" always come first within a Lisp form (i.e., set of parenthesis) and arguments are separated only by white-space, it doesn't need to worry about operators willy-nilly and so names are free to use hyphens and pretty much any character that isn't a handful of special characters (off the top of my head: white-space, parenthesis, single-quote since that is a special quote operator, double-quote since that starts a string, perhaps semi-colon cause that starts a comment in some dialects, and probably many more I'm forgetting, but generally fewer than most languages).

This can save a bunch of time typing code because it saves your hand the stretch of holding shift while you type the - key (at least on US and many related keyboards). If you haven't explored too far away from C this idea might be very foreign to you, but until you explore it you might not realize how freeing it is.

As another aside, most command shell languages also support a hyphen/dash within a command or argument name, and if you spend any time using one you've probably seen this countless times. Keep that in mind if you are ever developing a command line interface, which I hope you are if you ever develop software that interacts with users because it's the easiest to write and maintain (you can always build a GUI on the command-line or better yet a shared library central to both, but can't do the reverse). When you name your commands or subcommands/options/switches, never use an underscore unless that is somehow meaningful within the context. You can type the dash/hyphen easier, and it reads better too.

One programmer's vomit is the next programmer's elegance. Of course, I generally prize terseness, but the consequence of true terseness is usually complexity and many more magical symbols.

As an example, Perl can be very terse, and people are even more afraid of it than they are of C, despite it being a much higher-level family of languages. To contrast that, Python syntax is generally quite simple, and it has taken the world by storm as a result. Some code snippets are inevitably longer in Python, but there's less "line noise" which makes it an easier read for most. In the last decade, it appears that the world has chosen a winner as Perl is losing its user-base and Python has taken off in popularity.

I have to agree. While I understand the point Chris was trying to make, I think that the chosen syntax wasn't given enough thought to really accomplish the intended goals. Of course, I'm sure it was a contrived example, or maybe based on some language I'm not familiar with, such as D. But it just reenforces that "elegance" is more difficult to dream up in code than you might think. And syntax choices are usually a struggle between several competing goals (e.g., terseness and clarity, simplicity and expressiveness, familiarity and trailblazing).

Lisp is arguably very elegant and pure, and yet, most people cannot wrap their heads around it. It requires an "aha" moment that many people never achieve. It's very ancient history has also lead to several competing tribes which fragments the members that do get it and ultimately sabotages its ability to gain any traction from new members. And yet, many of the best programming concepts originated in a Lisp dialect, and many popular, modern languages still lack most of them.

Nevermind what the machine is doing under the surface. Give the human an elegant way to tell the machine what to do, and let the machine figure out the best way to do it to optimize its resources. In a perfect world, we wouldn't need a "unique_ptr<T>" at all. In a perfect world, the memory is not managed by man, but by machine, and it's done well enough to outperform any optimizations a man could hope to achieve. In a perfect world, the machine can translate a high-level program into a perfectly optimized low-level program. That's the ultimate utopia. Of course, true fantasy land is where the "program" is literally just a human speaking to a machine. Mind you, as dreamy as that concept it, it also leaves us somewhat out of a job (unless we go back to school to learn the extremely complex task of building such machines).

Of course, D has its own problems. I won't pretend to be up-to-date on them, but I think it was something like different forks for a standard library, and other such issues that make it more difficult to use. It's not like "D" is a united concept where everybody is doing the same thing with it. It's more like different, tiny groups are pulling in different directions, and the technology is in pieces unable to come together into a real C or C++ killer. The ideas are sound, but the technology is not production quality from what I've heard. That's a real killer for a programming technology. Until that changes, no matter what theoretical advantages D has over C or C++, it'll remain nonviable for most projects and programmers. Years ago I learned some of the very basics, like how strings are (or were?) just basically array types, but the array types could do all the string-y things for all element types. That's great.. But where is this technology today? Why aren't the big, free software loving companies using it? How can we unite all the groups interested in D to work toward a common goal and common future? How can we make D software compatible with C projects and visa-versa? I remember thinking how cool D would be, but having trouble even getting an environment setup that could compile D. And even if I got one setup, Google was just saying there are competing camps so it's just headache after headache. There are less painful high-level languages. Maybe not as fast, but probably the time you'll save in writing and maintaining software and development environments is the time you'll lose at run-time so it all probably balances out.

Append:

The C++ standard library has been embarrassing for decades and I don't think modern standards have gone far enough to improve upon them. Of course, there are alternatives. While people hate on Boost for template-runtime bloat, it is at least a stable library with very high-quality solutions to many problems. C++ the language supports a common, if "non-standard" solution to common problems, but the community hasn't done a very good job of coming up with a single "wheel" to solve common problems. It's probably fair to blame Microsoft for part of that. With free software hackers on one side and proprietary, IDE loving, broken compiler hugging, materialists on the other, there seems to be no common ground. The only time they come together and compromise for the better is when the materialists are dragged forcefully towards free software with perfectly groomed nails. Fortunately, that has been happening quite a bit for the latter part of the decade, but for C and C++ it's way too late.

I'll stick to C. And I rarely use macros. I do love some of the insane examples people come up with to make a language look bad. Examples most people never use, well, except that C++ vector<> example, I see that all the time. I will see std:: out the ying yang and if it is code I want to try out, I will add "using namespace std;" at the top and POOF, half the code can vanish! Or my personal favourite...

std::cout << "hello world" << std::endl;

Instead of using something like

std::cout << "hello world\n";

Or using namespace std you can remove the std:: and really make life easier and easier to understand.

I really get a kick out of online tutorials I have followed (on 3D programming, not C++) which will often create a string object to store a char* to a simple string that OpenGL wants... and OpenGL will want a char*, so they end up passing myStringObj.c_str() etc... which is really ridiculous.

One guy wrote a game engine in C++ and instead of using the constructor and destructor, created an init() function and another one to deallocate. When I tried out his code I eliminated a lot of wasted space by rewriting it to use the constructor/destructor. And I don't even like C++, but sheesh people, if you're going to use it, use it properly at least! In the guy's main() he created the game object, followed by myGame.init() which made me as that could have been avoided by putting all the init() code into the constructor which is called automatically.

I don't know, I can do what I want in C. I see a lot of far out examples, but my games are written 100% in C, compiled with a C compiler, not a C++ one using the latest version of C (2011, though I rarely use many of the modern features), most of my code can get along with C99, which to me, is the first REAL version of C which corrected some issues and I felt finally polished the language. But that's just my personal opinion.

If you like C++, great, use it, if you like D, awesome, use it. I like C, don't treat me like I am stuck in the past or some stupid shit like that. It's fast, efficient and does what I like. I don't tend to use macros or typedefs for anything except my structs, so my code is straight forward, you know what I am doing.

As for OOP in C, why? I can't stand OOP and I noticed online that even some seasoned C++ developers are moving away from OOP. They still use C++, just not classes so much, which I have thought about doing. Using C++ for certain aspects like vectors that are nice and otherwise coding in much the way I do C now. Though I do enjoy the challenge of recreating C++ features I like in C; which means I will never be challenged to create a C style OOP as I can't stand it! So no problem! If I liked OOP, I would use C++, be stupid to stick to C and create macros and junk to emulate OOP and classes when C++ has it already.

And I have coded in C++, I just prefer C. In my Text Maze 3D project I made up, it was written in C++, and visual studio, two things I rarely use. I just didn't use classes. Strings and vectors mostly for that one. Nothing I couldn't have done in C, but it was a spur of the moment thing so I wasn't worried about it.

If you need a fully dynamic 3D array like that, you should probably rethink your design. Or you're going to need it so rarely, what does it matter if you have to write something like that once in a blue moon? It's a pretty good deterrent, actually. Or if you do actually need to use them so regularly, you're probably better off with a higher level language where performance and memory use aren't a concern.

That small of a change completely changes the underlying behavior of the array? Between being a flat local allocation, vs 3D fragmented heap allocations with triple memory indirection and behind the scenes memory management. Or is it always 3D fragmented heap allocations with triple memory indirection and behind the scenes memory management, and the numbers just prevent it from growing or shrinking?

Besides, empty array brackets on a declaration already means something in C and C++.

Boost exists in its current form because the C++ committee misunderstood the versioning procedure with ISO, and thought they had to wait longer to make a new C++ version. Boost gained as much prominence as it did from that mistake, because it took so long for the C++ standard to update with new features and C++ coders came to rely on Boost for new features. These days Boost is less important for general C++ coders because C++ has been integrating the more useful features and has been updating more rapidly, and it's more useful as a staging ground to hammer out new or complicated ideas, see what can work and what's actually useful, or for things that don't really belong in the C++ standard.

I made a recursive template for Multi Dimensional Arrays in C++ a while back. I programmed iterators for it and everything. So it was as easy as :

typedef MultiDimArray<3 , double> D3D;// don't try this at home kids;

D3D d3d;
d3d.Resize(depth , height , width , 0.0);
d3d[z][y][x] = 1.0;
D3D::iterator it = d3d.begin();
int i = 0;
while (it != d3d.end()) {
   printf("Value #%d is %5.2lf\n" , i , *it);
   ++i;
   ++it;
}

I made reverse and const iterators too. It was fun.

But really, multi dimensional arrays are super easy. The hard part is lookup. When you've only got 2 or 3 dimensions, it's not super bad, but more is hard.

Just for fun I was messing around with this again, and I came up with something horrible with templates, but then I managed to come up with this. This is about as good as it gets with C++ and Multi Dimensional Arrays :

And then it's use is super simple :

And if I really wanted to make it fancy I could make iterators for it. But it supports multi dimensional array syntax NDA[z][y][x] gives you an NDA& and then you just call the PTR() function to get a pointer to the array at that point. Takes care of allocation and deallocation for you as well.