122 replies to this topic

[SiCrane]

There is no method of stopping junior programmers from doing things wrong other than educating them. Changing languages just changes what things they get wrong. Giving them an interface and a unit test won't stop things like Schlemiel the Painter problems.

[Kyall]

I'm thinking you need a programming application test instead.... A really simple one. That contains a loop requirement...

[snowmanZOMG]

C++ is too complex. Anyone who doesn't (or isn't willing to) admit that probably hasn't worked with the language enough to realize that or is delusional. Try writing your own parser for the language... But that doesn't mean one can't use it in a manageable way. Of course, I'm speaking mostly from a language implementer's point of view, but many language complexity issues come to light to every day programmers through things like syntax and language semantics.

I recently graduated with a BS in computer science and I have a few friends who are lower classmen and they're now looking to get jobs and I have often looked over their resumes to at least do a bullshit check on it. My school teaches Java as the first language (gross...), but eventually forces people to learn C or C++ through data structures classes and a dash of functional programming in a compilers and languages class. Almost everyone LOVES Java and hates C, C++, and OCaml. Anyways, some people become what I would call "Syntactically proficient" in C++, where I would trust them to implement very small pieces of code or features. Nothing more. It amazes me the audacity people have when they claim their proficiencies in particular languages, even though they have absolutely ZERO credibility in making them. My favorite, of course, is the listing of languages they know and they write something like:

Languages Known:

• C++ (Expert)
• Java (Expert)
• Python (Intermediate)

I know of only a handful of names in the world (We're talking like, 5-10 people) which could be on such a resume that could claim EXPERT in a language as complex as C++... Anyways, this turned out to be more of a rant. The reason why we (game developers) stick with such a complex and nasty language is for many different reasons. For me, one of the biggest reasons is simply it's the best we've got for the job we have. When you need to write high performance code, C++ surely can let you do that. If you need very precise control of hardware, C++ can let you do that. But be wary, if you need both of those, you will likely need to know what you're doing, and C++ does not spare those who don't know what they're doing.

My advice for people who want to know C++ more intimately:

• Write more C++ code and READ other people's C++ code. Figure out what you do and what they do. Why are you the same or different?
• IMPLEMENT YOUR OWN COMPILER!
• LEARN ABOUT LANGUAGE DESIGN!
• Learn other languages.
• Read the C++ language standard.

I put 1 up first since I think it's most easily done by the vast majority of people. 2 and 3 though I think really lets you understand some of the fundamental issues that drive the decisions the C++ language committee has to make. You also begin to understand why entire features are designed the way they are in terms of semantics and syntax. It also helps you put into perspective other programming languages (sure helped me). The last point, isn't really going to be helpful if you aren't already pretty proficient in C++ and programming language design issues. In fact, it may be of very little help to anyone unless you're interested in implementing a C++ compiler.

*Edit*
I should clarify my suggestion #2: Implement your own compiler for a simple, object oriented language. COOL perhaps. Implementing your own C++ compiler would be a herculean task. It takes teams of experts to implement one.

Edited by snowmanZOMG, 03 December 2012 - 04:08 AM.

[LorenzoGatti]

C++ is too complex. Anyone who doesn't (or isn't willing to) admit that probably hasn't worked with the language enough to realize that or is delusional. Try writing your own parser for the language...

Your car is too complex. Try disassembling and reassembling it.

[Bacterius]

*Edit*
I should clarify my suggestion #2: Implement your own compiler for a simple, object oriented language. COOL perhaps. Implementing your own C++ compiler would be a herculean task. It takes teams of experts to implement one.

Thank god for that clarification, I was starting to wonder if implementing your own C++ compiler was par for the course

[MichaelT]

The way I see it is that it (C++) is only as complex as you make it. C++ has a lot to offer, but then there is no requirement to use it all. If anything, I see far too many coders who just go crazy with using as many c++ features as they possibly can. I many cases I would guess it is (again) simply because 'they can'. If they 'should' is a whole different story. I mostly code C and use C++ features where it makes my life a little easier. But for the most part it's C, unless there is a good reason not to.

I would suggest you not to waste time on D. It's been around for some 6+ years now, and I am doubtful you'll find much work in that area, if ever.

@whtemple1959: Just start easy with some very simple programs. Try to stick to the simple things in the beginning, using as few keywords as possible. Using your analogy, draw stick figures to familiarize yourself with the tools. But keep coding, even if it is the most simple things. Like doodling. In time (depending how much time you spend) you'll pick up the basics soon enough. As far as the tools go, don't worry about them. Install QT.. or MingW. But the only thing you need from them is to make them compile a program. If you get that working, you're good to go. All you need to focus on right now is making small programs. Here are some links for you:

http://www.cplusplus.com/doc/tutorial/
http://www.cppgameprogramming.com

I haven't look at them closely but I am sure you can find others later.
Learning to walk before running is important.

Also, If you want to be inspired, have a look here on what others have done:

http://www.pouet.net


Hope it helps.

[Paradigm Shifter]

You really need to design and plan your code with C++, and preferably document it, it's all too easy to fall into the trap of "write only code" that no-one understands, or can read.

C++ is complex, probably too much so, as someone said (I think about C++11), it's like a commitee designing an octopus by nailing 4 legs on to a dog. Backwards compatibility is the killer though (but obviously that is one of its main strong points).

[MichaelT]

I would not worry about C++11 too much. It'll be years before that version have become widely adopted.

[Paradigm Shifter]

But it sorts out a lot of the performance problems that the old C++ had, at the expense of adding extra layers of things to remember all at once. There's far too many gotchas and undefined behaviour already, without adding more stuff ;)

If only they could get rid of some of the mistakes they made earlier on and make a cleaner lighter language. Not going to happen though.

[Khatharr]

C++ is too complex. Anyone who doesn't (or isn't willing to) admit that probably hasn't worked with the language enough to realize that or is delusional. Try writing your own parser for the language...

Your car is too complex. Try disassembling and reassembling it.

Modern cars are too complex. My mom's car has a big chunk of black-box electronics on top of the goddamn battery.

THE BATTERY.

A 'proper' (read that as 'Khat is a smug, opinionated git') car can be taken apart and re-assembled by a decent mechanic. The new ones try to do way too much and end up not being able to go to from point A to point B because the satellite radio reception isn't good enough to power the flux capacitor or whatever.

C++ is (eeeeeehhhh...) sort of starting to look a little the same. There's a solid core language under it all, but all the stuff that's put on top of that can be a little bizzarre at times.

Even so, if you think about it in relative terms C++ is still good at the jobs that it's good at, so I wouldn't say that it's a huge problem. On the other hand, if a new language comes out right now that does the same job with less BS then I'd say there may be a fight on.

Edited by Khatharr, 03 December 2012 - 06:58 PM.

[Sudi]

If only they could get rid of some of the mistakes they made earlier on and make a cleaner lighter language. Not going to happen though.

The language is light....i really don't see the problem alot of you seem to have with it. Its the same with any programming language. Once you know how to programm you can basicly programm in any language.

[Paradigm Shifter]

You've probably never seen any really bad C++ code. C is a very light language but my, have I seen some terrible code which no-one understands. C++ is about 4 times worse if you write it badly.

[Khatharr]

If only they could get rid of some of the mistakes they made earlier on and make a cleaner lighter language. Not going to happen though.

Wish I could upvote you twice. I don't know if I'd call them 'mistakes' but some of the changes seem a lot more like 'tack on another class' rather than actually incrementing the language itself to add new features.

Edited by Khatharr, 03 December 2012 - 07:04 PM.

[Sudi]

You've probably never seen any really bad C++ code. C is a very light language but my, have I seen some terrible code which no-one understands. C++ is about 4 times worse if you write it badly.

I think i have seen alot of code and c can just be as bad as c++. Same goes for every programming language. You can always write bad code and create structures that no one understands besides yourself. But that really has not so much todo with the language used.

[ApochPiQ]

Take the infamous C++ quiz by Washu and tell me C++ is not problematically bad.

You can write bad code in any language, sure. You can also commit genocide with any weapon, but some weapons make it a hell of a lot easier.

[Cornstalks]

This one just got me the other day:

Which constructors and/or operators will be called in this code:

struct MyStruct
{
	MyStruct() {}
	MyStruct(int i) {}
	MyStruct(const MyStruct&) {}

	MyStruct& operator = (int) { return *this; }
};

MyStruct s = 5;

Spoiler

This is an example of copy-initialization (see a GotW about it). First, MyStruct(int) will be called to convert 5 to a MyStruct. Second, MyStruct(const MyStruct&) will be called with the created temporary. The other two functions (MyStruct() and operator =()) are not called. The code is effectively MyStruct s(MyStruct(5)) (fingers crossed that isn't accidentally a function declaration...).

It gets a little more complicated though, because of copy elision, so the compiler is allowed to optimize away the temporary and effectively just call MyStruct(5). But it doesn't have to.

C++ is way too complex. I don't mean too complex for beginners. I mean it's way more complex than it needs to be.

Beginners can start with whatever they want. They just need to realize that it'll probably take them longer to get something shiny on the screen with C++. Like SiCrane said, no matter what language someone chooses, they'll make plenty of mistakes. It's not the end of the world if someone chooses C++. But it's not exactly a walk in the park, either. It's never a walk in the park.

Edited by Cornstalks, 03 December 2012 - 07:56 PM.

[Sudi]

Ok when i saw that code i thought hmm pretty clear it should be the int constructor since the object doesn'exist yet....then i saw your explanation and i shrug...really? then i tried it just to be sure....first instinct was right your "spoiler" is wrong

[Grafalgar]

Ok, reading through the comments, and the general "it's too complex, not a walk in the park, long time for something shiny on the screen, etc" hand-wavy consensus - I'm really curious: What, specifically, from the folks that consider the language overly complex, are the overly complex pieces of the language?

And I'm not talking about relatively obscure tricks/"abuses" of the languages. I'm talking about stuff you'll learn in your first years of Comp Sci, or an intro-to-C++ book.

I mean, I've seen my fair share of heinous code. In all manner of languages: C, C++, Java, C#, Python, LUA .. you name it. But what makes it complex has never been the language as much as the complexity of the code. In other words, I rarely ask myself: "Damn, what does this language feature do?" but rather ask "why in the world has the developer done this?"

I do believe, though, that pointers and the usage thereof continually trip folks up with regard to C *and* C++, and with good reason. Pointer management takes a while to get a good grasp of, but even Pascal had pointers and I can count on my left foot the number of times someone has said "Pascal is too complex" Even though Java and C# have *many* more language features than C and C++ combined, the fact that they (mostly) completely hide pointers and memory management makes it easier for most programmers to write code and not worry about memory consequences, right off the bat.

So, again, what *exactly* makes C++ so complex over, say, Java? Pointers aside, and considering only what you may learn in your first year as a CS student? (I make that distinction because as you spend more time in any language you'll eventually learn all sorts of 'interesting' things that'll make most folks' heads spin)

[ApochPiQ]

That question makes no sense to me.

The problem is that no first-year CS course will cover all the things you have to know to use C++ proficiently. It's like asking "what's so hard about being a chef? Limit your answers to the subject of boiling water."

Well, yeah, boiling water isn't hard. There's a lot more to being a chef than boiling water.

[Yrjö P.]

Ok when i saw that code i thought hmm pretty clear it should be the int constructor since the object doesn'exist yet....then i saw your explanation and i shrug...really? then i tried it just to be sure....first instinct was right your "spoiler" is wrong

This is a good demonstration of how confusing C++ is. Cornstalks told you exactly what happens, you went and tested it, and you are still wrong.

He said that the int constructor gets called, then the copy constructor gets called, but the compiler is allowed to optimize the copy constructor away. In the case of your particular compiler, your particular compiler version, your particular computer architecture, your particular compiler settings it so happens that the compiler does that optimization and only calls the int constructor. But with some other configuration of those things, the same code would result in both constructors being called, and in both cases the compiler could be a completely valid C++ compiler. This repeats over and over again in the language: valid C++ compilers are allowed to do a wide range of things, and if you want your code to be valid C++, it has to withstand all of those things. Therefore you have to know what the language says. If you don't know the copy constructor may get called there and you assume it won't, that can blow up in your face at some point in the future.