How Much C++ Should You Know For an Entry-Level C++ Job?

Nerval's Lobster writes: How much C++ do you need to know to land an entry-level job that's heavy in C++? That's a question Dice posed to several developers. While the exact topic was C++, the broader question of "How much X do you actually need to know to make money off it?" could also apply to any number of programming languages. In the case of C++, basics to know include virtual methods, virtual destructors, operator overloading, how templates work, correct syntax, the standard library, and more. Anything less, and a senior developer will likely get furious; they have a job to do, and that job isn't teaching the ins and outs of programming. With all that in mind, what's a minimum level of knowledge for a programming language for entry-level developers?

Comments

Answer

[s.petry]

NONE! Find a real language! *ducks*

Re:Answer

[lgw]

NONE! Find a real language! *ducks*

For non-ducks, the most important things to know about C++ aren't list in the summery: RAII and shared_ptr<T>

C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java: throwing exception when errors are encountered, writing exception-safe code all the time, returning from functions in the middle, and never, ever, worrying about cleaning up at the bottom of a function what you allocate at the top.

If all of that sounds wrong to you, congrats, you're a C coder, and there's nothing wrong with that. Good C code is good code. But C++ is designed to be used with "scoped objects", that is, every object cleans itself up when you exit scope, so you really have to internalize the tools for that, and that mindset.

Re:Answer

[rwa2]

NONE! Find a real language! *ducks*

Ooh, another Dice discussion!

echo "import random\nprint random.randint(1,6)" | python -

Re:Answer

[BarbaraHudson]

The right answer is "If you have to ask, you don't know enough." :-)

Re:Answer

[arielCo]

1. Would you complain if this was an "Ask Slashdot", or taken from a respected programmer's blog? Does the name behind the thing matter that much?
2. Slashdot is now owned by Dice. The Golden Rule says the one with the gold makes the rules. You're free to seek greener pastures or linger on.

Re:Answer

[Spazmania]

C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java

That's a bit of a problem, because when you program in C++ the same way you'd program in Java, you lose the efficiency and simplicity of C without gaining the clean design of Java. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C but with, you know, a little bit plus.

If all of that sounds wrong to you, congrats, you're a C coder

I resemble that remark.

Re:Answer

[rjh]

unique_ptr is normally preferred over shared_ptr -- the former is zero-overhead compared to a pointer, while the latter has a reference count associated with it which has to be incremented and decremented. If you know two or more things will be using the pointer and you don't want to have to worry about ownership semantics, shared_ptr makes a lot of sense. If you know only one will be using it, unique_ptr makes more sense.

Re:Answer

[TheRealMindChild]

I don't know how to respond because this whole post is bullshit.

If you are using C++ as such a high level language as Java/C#, you may as well use them because you threw away some of the most useful/valuable parts. Also, Exceptions are EXCEPTIONAL and should be treated as such... only expected to be thrown when something exceptional happens, not as a means of flow control.

Re:Answer

[lgw]

. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C

That's just, like, your opinion man!

Seriously, though, C++ was never intended to be "C with a little extra", but instead a Java-like (but native code) language with backwards compatibility with existing C code. You can see that throughout Stroustrup's writings, including how he says C++ should be taught (start with std::vector and std::string - don't even teach arrays and char* until people have the basics internalized).

IMO, C++ properly written is a better Java - no worries about resource cleanup (Well, now Java has try-with-resources, so it's not so bad), vastly less boilerplate, a great standard algorithms library, and so on. Java's advantage is in its easy learning curve, and standard cross-platform libraries, which led to a vast selection of open-source tools. If the C++ standard had included more cross-platform system libraries earlier, Java might not have the library advantage. While C++ finally has threading in the STL, it's missing so much other systems-level stuff. But at least I can have a freaking unsigned int in C++ if I want to!

Re:Answer

[Ichijo]

And don't even think about touching production code until you understand const-correctness.

Re:Answer

[rwa2]

But... but... but without Dice, my python bash one-liner would make NO SENSE )-;

Re:Answer

[Gibgezr]

In the field I work in, we aren't allowed to use RAII; we compile with it turned off. Same for exceptions (this is not exactly unique; Google coding practices require this as well, as do many other companies). Performance-critical real-time code shuns that stuff. We haven't used C for 20 years, because C++ offers the stuff mentioned in summary, and what we need is all that power PLUS the ability to manipulate memory directly, and all as fast as possible. There are huge swaths of industry that need more than "C with classes", but less than Java/C#.

Of course, what it boils down to is the old joke about C++: get 5 experts on the language in one room, and you discover that each of them only is comfortable with 40% of the language...and it is a DIFFERENT 40% for each of them!

Re:Answer

[lgw]

Oh fuck yes. But that's easy to explain to a new-hire - it's just a tedious convention, not really a mindset thing. IMO, the single most annoying flaw in C++ was not making all members and parameters "const&" by default. (Passing an int by value instead of by const reference is just the optimizers business, not a semantic change). I'd much rather declare the non-const exceptions!

And while I'm wishing, C++ really needs C#-style properties - a way to optionally intercept "foo.bar = 4" to add a non-trivial setter, without cluttering code with getBar() and setBar() functions "just in case".

Re:Answer

[multimediavt]

But... but... but without Dice, my python bash one-liner would make NO SENSE )-;

[rim shot]

Re:Answer

[multimediavt]

But... but... but without Dice, my python bash one-liner would make NO SENSE )-;

Err, sting...

Re:Answer

[Anonymous Coward]

You cannot turn off RAII (Resource Acquisition Is Initialization) in C++, since it is an idiom and not exactly a language feature. What you are talking about is problably RTTI (Run-Time Type Information). Both of these features have zero performance overhead if not used, so there is really no point in turning them off. Just don't use them in performance critical places.

Re:Answer

[lgw]

(You can't "compile with RAII turned off", as RAII is a coding style: you're probably thinking of RTTI. But the RAII style might not be good for a realtime system, as it can hide expensive work to release resources.)

The abomination that is Google's C++ coding conventions is why I hang up on their recruiters. (Though I hear an internal war has been raging for a couple years within Google over their 80s-night coding conventions). Actually, I'm not sure what's you'd use from C++ beyond "C with classes" if you're writing C-style code. If you're not comfortable with exceptions, and are following an "allocate at the top, clean up at the bottom, never return from the middle" mindset, C++ is damned awkward - you won't be using the standard libraries much, you won't have non-trivial constructors, and so on.

Re:Answer

[s.petry]

Funny to watch the Slashdot ignorant get offended at my comment.. or defensive of their language for that matter. The history of C vs. C++ threads on this site can only be rivaled by MS vs. UNIX, and KDE vs. Gnome threads. It has been a while since I have seen this one...

Re:Answer

[Anonymous Coward]

Nah, if someone's got this class:

class ConstantClassDONOTEDITANYTHING
{
public:

ConstantClassDONOTEDITANYTHING(const ObjectType* object) : _constPointerCONST(object) {}

const ObjectType* const GetConstantPointerTHISISCONSTFOFUCKSSAKE const { return _constPointerCONST; }

private:

const ObjectType* const _constPointerCONST;
};

I can always just do this:

void SomeMethodOrOther(const ConstantClassDONOTEDITANYTHING& thisIsConstantFFS)
{
ObjectType* weeee = const_cast(thisIsConstantFFS.GetConstantPointerTHISISCONSTFORFUCKSSAKE());
weeee.DeleteEverything();
}

I don't see a problem with that.

(Also, I can have a const return of an object that returns by pointer or reference a non-const object... and I can modify that. That's in the standard, but it's one of the things in C++ that I think is seriously fucking stupid, and I'm actually quite a fan of C++. Just make const mean const. If someone wants to yank out a member field and modify it when it's in a const context, let them fucking const cast it and get that horrible feeling that they're doing something wrong, because at the least they're doing something very misleading.)

Re:Answer

[Grishnakh]

C++ is not C. C++ written like C tends to be crap code

You might want to avoid flying on commercial airliners then, because they have lots of avionics systems running C++ code exactly like that, with exceptions explicitly banned. Countless other embedded systems are the same way.

never, ever, worrying about cleaning up at the bottom of a function what you allocate at the top.

In these embedded systems, the "delete" keyword is also banned. You're never allowed to free memory once it's allocated.

Re:Answer

[Anonymous Coward]

Oh FFS

ObjectType* weeee = const_cast(thisIsConstantFFS.GetConstantPointerTHISISCONSTFORFUCKSSAKE());

Re:Answer

[angel'o'sphere]

For non-ducks, the most important things to know about C++ aren't list in the summery: RAII and shared_ptr<T>

That is not really correct. As soon as you know about ctors and dtors you know about RAII, no special "point in the list" needed.

Re:Answer

[angel'o'sphere]

Nothing beats C++ in multiple inheritance (which Java does not have and Groovy/Scala only mimic half arsed) and in templates, which Java/Groovy does not have either. Not sure about Scala, originally they wanted real templates, but no idea if they scaled down to generics, too.

Re:Answer

[angel'o'sphere]

Properties are easy achieved in C++ by using so called "property templates" where you wrap attributes into such a template and overwrite operator = for assignment and the cast operator for reading ...

Perhaps you should catch up and buy one of the 20 year old C++ books :D

Re:Answer

[lgw]

Not any more than owning a chisel makes you a sculptor. If I had a dime for every init() method I've seen ...

Re:Answer

[angel'o'sphere]

In the field I work in, we aren't allowed to use RAII; we compile with it turned off.
You are mistaken.
You can not turn of RAII. It is only a constructor call and a destructor call.

Re:Answer

[lgw]

Is it really C++, or "C with classes", though?

Re:Answer

[ron_ivi]

unique_ptr ... shared_ptr

LOL at how C++ gets new smart pointers every couple years.

It's like they're trolling their own users with their:

• classes are kinda like structs, so you can use 'typedef struct ... *' for classes and 'void *' for generic functions (Everything from CFront in 83 through ARM in 99)
• no! 'void *' pointers are broken! use 'auto_ptr' instead (C++03)
• no! 'auto_ptr' is broken! use 'shared_ptr' instead (C++07/TR1)
• no! 'shared_ptr' is broken!(for most use cases) use
• 'boost::scoped_ptr' instead (non-standard, but more useful than the standard's shared_ptr)
• no! 'boost::scoped_ptr' is broken! use 'std::unique_ptr const' instead (C++11)
• no! 'std::unique_ptr const' is fugly! use "auto" and hope C++14's "return type deduction" will guess a safe type and hope C++17's "new rules for auto deduction" won't break stuff (C++14)

crap.

How the heck can people take an "object oriented" language seriously when it takes literally 30 years (1983 to 2014) for them to come up with a non broken way of making a reference to an object....

... and in the end they give it a syntax like "std::unique_ptr const".

W.T.F.

Re:Answer

[rjh]

I don't know who told you C++ was an object-oriented language. It's not -- ask Bjarne. It supports many different styles of programming, object-oriented being just one of many, but it is in no way object-oriented. You can write large code bases without using a single object.

Re: Answer

[CockMonster]

Ugh, are you one of these C++ gurus who don't realise std::unique_ptr exists? You probably pass them instead of references too? Ugh

Re:Answer

[Tanuki64]

It really is unbelievable how many wannabes bad-mouth C++ here and at the same time show that they don't have the slightest idea what they are talking about. 'Disable RAII' suuuure... I compile my programs always with the -no-crash option so my programs never crash... Never heard of it? Not surprising... it is in pre-standard C++21 and only supported in GCC 7.2 ;-)

Re:Answer

[angel'o'sphere]

So you never tried the -auto-fix option?
Shame on you! ;-)

Re:Answer

[lgw]

Yeah, I've done that trick before: it's not quite the same. It's been a while since I tried, but I remember it not working for some operators and implicit conversion the way it would with a simple public data member - complexities of type inference.

There was actually a provision for this originally, sort of: by overloading the -> operator you can change what foo->bar returns, but you can't change what foo.bar returns, and since I almost never pass pointers around I rarely use the -> operator

Re: Answer

[lgw]

I remember when it was spelled auto_ptr (OK, OK, they're not quite the same). But unique_ptr's just part of using RAII - you need to know shared_ptr as well, was my point.

Re:Answer

[brausch]

Huh!? According to Stroustrup in "Design and Evolution of C++", C was certainly intended to be "C with a little extra". It was also designed to be C with a lot extra. He intentionally created the language so that C style code would still run just as fast as before. You could just take advantage of the nice things like function prototypes (remember when C++ first came into being was before ANSI C) and declaring for loop variables inside the loop, etc. You could begin to use the new features as you wanted.

Or, you could go full bore with objects, etc.

Thirty years of development later, we have today's C++.

Re:Answer

[brausch]

Exceptions are EXCEPTIONAL and should be treated as such... only expected to be thrown when something exceptional happens, not as a means of flow control.

Yes, absolutely agree with this!

Re:Answer

[UnknownSoldier]

As someone who briefly worked on a PS3 C++ compiler my colleagues would love to joke:

There are 2 problems with C++:

1. It's design, and
2. It's implementation.

On a more serious note when you even have committee members acknowledging they only use a sub-set of the language, then maybe, just maybe the language is too freaking complex.

Other committee members admit there are many problems with iostreams

C++ has become over-engineered.

If the C++ would deprecate crap such as

long long

and other verbosity then maybe the language would become simpler.

Re:Answer

[Grishnakh]

These embedded systems use C++, but according to an FAA standard that is very similar to the MISRA standard. Anything which is non-deterministic is forbidden. These even includes CPU caches, which are turned off on these systems.

Re:Answer

[Anonymous Coward]

This is modded funny, but I think it should be informative.
I was hired somewhere to do some coding. They asked me if I knew Perl.
I said "no, but I can learn it."
They said that's exactly the attitude we need.
Unless you expect a person to be 100% productive from day one there is no reason to require more than simply having used a programming language.
And especially for an entry level job. If the senior developer doesn't have time for that, maybe he shouldn't be hiring an entry level developer.

Also that list in the summary is kind of pointless. Should I just know that virtual methods exist? How they are implemented? What they are for?
Should I know the entire STL? How about iosfwd and ios?
And virtual destruction? Is it fine if I stick them everywhere, or just some places, and when?
Should I know about sequence points, or maybe the sequencing system that replaces them in c++11?
I think most of these things can be learned on the job and in combination with a good style guide.

Re:Answer

[Anonymous Coward]

And you never run out or memory since you've got an infinite amount of it?

Seriously, I've programmed some real-time systems, and not even critical ones. Minimizing memory allocation/deallocation is a must, sicne these are functions with unknown and unbounded latency (especially in multithreaded code where you can always hit a mutex) and C++ is very poor for it, since some methods may allocate memory behind your back. At least with C you have fewer problems (strdup() is a memory allocation function, so even it should be banned, or at least used sparingly).

Re:Answer

[Anonymous Coward]

Only thing you need to know:

C --> Functional programming
C++ --> object oriented programming

If you know the difference, then you'll be a fine C or C++ programmer. Syntax is just that--there's not talent for it and features, like RAII, shared ptrs and such are features you learn if you need them (i.e. experience)--and that's pretty specialized.

Re:Answer

[Fnord666]

Funny to watch the Slashdot ignorant get offended at my comment.. or defensive of their language for that matter. The history of C vs. C++ threads on this site can only be rivaled by MS vs. UNIX, and KDE vs. Gnome threads. It has been a while since I have seen this one...

Let's not forget the vi vs. emacs ones...

Re:Answer

[Grishnakh]

And you never run out or memory since you've got an infinite amount of it?

If you did things right, you never run out of memory because you've planned every allocation and you have enough for them all.

Minimizing memory allocation/deallocation is a must, sicne these are functions with unknown and unbounded latency

Right, that's why they allocate all the memory up front and never deallocate it.

Re:Answer

[Anonymous Coward]

Huh!? According to Stroustrup in "Design and Evolution of C++", C was certainly intended to be "C with a little extra".

At some point of time it becomes ridiculous to call the quest for piling up the tallest heap of crap "design".

Re:Answer

[UnknownSoldier]

> C++ written like C tends to be crap code

Total nonsense as you completely ignored context.

You've obviously never had to write high performance C++ code; guess what, we don't use OOP instead we use DOD (Data-Orientated-Design) which is far more a simpler C style then over-complicated C++ style. It also has the benefit of being simpler to read, easier to write, and performs far faster. Go figure!

* Pitfalls of Object Oriented Programming -- http://www.slideshare.net/royc...
* Data-Oriented Design and C++ -- https://www.youtube.com/watch?...
* Typical C++ Bullshit -- http://macton.smugmug.com/gall...

Next, it appears you don't understand what Casey calls "Semantic Compression". There is nothing wrong with using C++ as a better C.

    * http://mollyrocket.com/casey/s...

Gee, why do other professional game devs not bother with using STL, Exceptions, or RTTI ? Because TANSTAAFL / TINSTAAFL !

* https://www.youtube.com/watch?...

Lastly, I can tell you've never shipped any games where C++ obfuscates readability and performance.

> But C++ is designed to be used with "scoped objects"

Maybe in your mythical world, but rarely does C++ classes map perfectly to the real world.

I've been shipping games since 1995. Modern C++ is over-engineered.

Re:Answer

[Christian Smith]

C++ is not C. C++ written like C tends to be crap code

You might want to avoid flying on commercial airliners then, because they have lots of avionics systems running C++ code exactly like that, with exceptions explicitly banned. Countless other embedded systems are the same way.

*shudder* Are avionics really written in C++?

never, ever, worrying about cleaning up at the bottom of a function what you allocate at the top.

In these embedded systems, the "delete" keyword is also banned. You're never allowed to free memory once it's allocated.

Is memory deterministically pre-allocated in such systems? That would certainly make it safer, but less flexible.

Re:Answer

[andyhhp]

Nothing beats C++ in multiple inheritance (which Java does not have and Groovy/Scala only mimic half arsed)

I have yet to encounter a non-contrived example where multiple interitance is a plausible solution to a problem. The simplified single inheritance and interface model caters for all practical examples, and *vastly* simplifies the internal workings.
How large is a pointer to a member variable?

Re:Answer

[Grishnakh]

*shudder* Are avionics really written in C++?

Yes, but only a subset of it. Things like exceptions aren't allowed.

Is memory deterministically pre-allocated in such systems? That would certainly make it safer, but less flexible.

Yes, that's the whole idea. They aren't meant to be flexible, they're meant to do exactly what they're designed to do and no more, in a completely deterministic fashion. These systems aren't all things with UIs, they include all kinds of systems on an aircraft, which frequently don't have any UI at all except maybe some switches. On a car, an ABS computer would be a good example of one of these systems. There's no display or UI or anything of the sort; you just plug it into the car, and it sits there monitoring wheelspeed and brake pressure and when it sees a wheel locking up it releases brake fluid pressure to that wheel (it's a bit more complex than that, esp. on cars with dynamic stability control and traction control where these are all tied into the ABS, but this is the general idea). A system like that doesn't need to free memory, it just needs to allocate what it needs when it powers up, and then run its program continuously, monitoring inputs and controlling outputs (implementing transfer functions etc). All the tasks it'll ever have to do are well-defined, and all start up when the system powers up, and all get a timeslice.

Re:Answer

[ebyrob]

The problem with C++ exceptions is they tend to be "throw only" from a safety standpoint... For example catch(...) {} is a disaster waiting to happen.

RAII doesn't require exceptions, but exceptions require use of RAII.

Re:Answer

[ebyrob]

I think you mean C --> Procedural programming.

Functional programming would be done in Haskell or perhaps Lua...

Re:Answer

[BlackHawk-666]

I don't throw exceptions because I write games you insensitive clod!

Re:Answer

[BlackHawk-666]

Multiple inheritance is a two edged sword. Used badly you will definitely cut yourself and others around you. Used right, it can be just the right tool.

There's *very few* times I'd consider using multiple inheritance instead of interface inheritance + 1 concrete inheritance. The only time in recent memory was for BOIDS. The existing code had chickens, turtles, eagles, fish and a few others. Turns out turtles inherited from chickens...yeh...anyway, the idea was that we'd go with standard classifications instead - terrestrial, aquatic and amphibian.

Obviously the chicken-turtles needed some rework to become amphibians instead.

Terrestrials should 'walk', avians should 'fly', 'aquatics should 'swim' and amphibians should 'walk+swim'...and really birds need to both walk and fly.

I left it up to a junior to sort it out, so hopefully it doesn't totally suck.

That is literally one of the only times I've ever though maybe multiple inheritance is a great idea. Yeh, I've wanted to use it to be lazy, but given all other factors....it's best left infrequently used.

Re:Answer

[UnknownSoldier]

Agreed.

"I made up the term object-oriented, and I can tell you I did not have C++ in mind!" -- Alan Kay

* https://www.youtube.com/watch?...

Re:Answer

[BlackHawk-666]

init() should only ever be a thing where you need to perform some kind of init after construction. There's good cases for this in complex software e.g. where you need to run code after everything has been allocated / inited but not prior to some other thing.

CRYENGINE is full of classes that need an init call to complete, and even PostInit ().

The world is more complex than you think.

Re:Answer

[BlackHawk-666]

Thank you, watching these links now.

Re:Answer

[cheesybagel]

Java supports multiple-inheritance of interfaces, which is your actual problem.

Re:Answer

[Anonymous Coward]

Yes, exceptions should be the exception, but it's so much harder to write and understand code that way. You'll almost never see someone checking if a file exists, checking that it's a file and not a directory, checking for read permissions, opening the file, actually reading the file, then exception handling for file not found, exception handling for security permissions, and finally a general exception handler for a stream error or something. Proper code means you check all those things before you open a file (so you can display informative error messages and recovery options), but the file system can change from when the checks finish and when the file is opened, so you still have to have all the exception handling. With the exception handling, the original checks become redundant so you'll leave them out as they take time to write and are potential sources of bugs. Now your exception handling is part of your standard logic and is no longer exceptional.

I wrote all those checks when in college. It was crazy and impossible for me to test. Most of the error handling logic gets duplicated (or you have to split it off into separate functions and deal with that additional complexity) and complete code coverage testing is impossible unless you're using an advanced (expensive) framework that can trigger IO errors at specific lines in your code from your unit tests (and now your tests are very complex). It is far, far easier to grab any exception from open(file) and be done with it. Though I've come across plenty of (open source) software that doesn't even do that and instead corrupts your data and crashes if anything isn't perfect.

Developers are lazy and/or under time pressures, More languages should take that into account.

Re:Answer

[UnknownSoldier]

/me hats off to another game dev :-)

If you don't already read this sub-reddit: /r/gamedev ... you should :-) You'll find me hanging out there too.

Re:Answer

[Anonymous Coward]

Hey, fellow professional game developer here, also shipping games since 1995. I agree with your take on C++. We mostly use it as "C with classes" and it has served us well with AAA and our 'indie' output. I guess I'm a yokel because when I see some twelve-consts-on-a-line gibberish my eyes glaze over.

Re:Answer

[slimjim8094]

(I work at Google and use C++ there, but what follows is my opinion)

What precisely don't you like about the C++ style guide? (This is almost identical to the internal guide)

- It is true that exceptions are verboten, but honestly it's not particularly limiting. Java gets exceptions right - something is truly "impossible" (in a crash-the-program you-have-a-logic-error sense) and thus you don't need to handle it, or else it's "expected" like an I/O issue and the language forces you to do something with it - either try/catch, or declaring that you're potentially passing it along. C++ doesn't have any such enforcement, which makes it very hard to reason about what a function may throw at you. You rely on everybody in the entire call hierarchy doing the right thing. Reminiscing about my Java days, the lack of exceptions does make some things somewhat more cumbersome to deal with - having to explicitly return a status object, for instance, to deal with plausible-but-atypical cases. But the Google guide is fairly apologetic in this area and basically says "sure, we'd use it if we had a brand-new codebase, but we don't..." and the reasons that follow for why exceptions are hard to integrate into a truly enormous codebase seem sound to me. What do you disagree with about this reasoning?

- There is certainly no rule about "allocate at the top, clean up at the bottom, never return from the middle". In fact, with unique_ptr and the like, there's even less reason to do those kind of things than there's ever been. The local variable part of the style guide actually explicitly encourages as-close-as-possible declaration, and the rest of the style guide is quite gung-ho about unique_ptr (we actually had an internal class for a long time that was sufficiently identical to unique_ptr that they were able to replace all uses and remove the custom type in just a few months). I can find no reference to any sort of prescription about the location of return statements.

- The standard libraries have actually been moving away from exceptions, haven't they? C++11 introduced 'noexcept' and added it to a bunch of methods, and the specs for a lot of other ones guarantee that the only exceptions are from the allocator (e.g. std::bad_alloc). To be clear there is no prohibition against *using* code (especially the standard library) that may throw exceptions.

In a nutshell the style guide is, in order, "be readable" followed by "be consistent". It is hilariously easy to write unreadable, bug-prone C++ code. Nobody cares if your code is perfect and correct, they care if the next guy along can modify or use it correctly and it is useful to have a style guide to make some of the more hard to reason about things impossible. How many different bits of code could the statement 'a = b;' potentially execute? (It's a lot - copy constructor, operator=, operator Foo(), etc.) The style guide limits it to just a few things you might have to consider, so that when you use some code someone wrote 6 years ago there's not so much to look at. C++ has references and pointers, which is great, but at least with pointers there's a hint that you might have "spooky action at a distance" so the guide mandates their use for out-params which seems perfectly reasonable since it's basically arbitrary which to use - and in practice, it's a really handy hint to have when you're reading. Unless you're passing an address, you know your copy can't be modified. IMO, way more readable.

If you've really been hanging up on recruiters because you object to the style guide, it is probably worthwhile to actually ensure that your understanding of it is correct and up to date. It has changed in recent years as C++11 has become better understood and it is fair to say that it is far more liberal to things like lambdas, template metaprogramming, operator overloading, copyable classes, etc - than it was a few years ago.

Re:Answer

[nazsco]

exactly this!!!

C++ != C

so, if you are going to break away from C, and use a high level language, use a high level language.

Do not use something crippled and ill designed. C++ was good when the alternative was cobol or fortan. And the only reason it is where it is today was because it got a ride on C reputation. But as you pointed out, it is not C.

Re:Answer

[BlackHawk-666]

But so does c++, that wasn't the actual problem.

Re:Answer

[Anonymous Coward]

True that. It seems like C++ multiple inheritance gets a bad rap, but every other language I've seen is less flexible than C++ multiple inheritance. Sometimes I wonder if the real problem with C++ inheritance is it's too powerful for people to use correctly.

Re:Answer

[BlackHawk-666]

I'll go have a peek at it now, see what's up.

Re:Answer

[Anonymous Coward]

Doesn't every library pretty much evolve like this? It's very hard to design perfect libraries upfront. Once stuff is in the wild for a year or two, people reach consensus on the benefits vs drawbacks, and then a better library is designed.

One of C++'s strengths is that the language (since C++98 at least) is actually powerful enough to express all these smart pointer libraries. The language didn't have to change even as people found better ways of doing things.

Re:Answer

[The Evil Atheist]

But everything is a double edged sword. Even a single edged sword is a double edged sword. Yes, you're safer with one edge. But on the other hand, you only have one edge to attack with.

Re:Answer

[The Evil Atheist]

The whole point of exceptions is that some control flows are exceptional.

Re:Answer

[Anonymous Coward]

it's more like C++ where C is a macro that expands to (*(int *)NULL)

Re: Answer

[Anonymous Coward]

I have monitored 200 developers and the issue seems to be that only about 3 of them are not misusing the inheritance. Usually you should have the inherited code in a separate class. Second issue us that you inherit when you could have just one class containing code for both. 3rd issue is inheriting from class that is not abstract. You need inheritance about once for 100 000 lines of code. It is rare.

Re:Answer

[Jeremi]

I have yet to encounter a non-contrived example where multiple interitance is a plausible solution to a problem.

Okay, I'll give it a shot, then... here's where I find multiple inheritance not just plausible, but preferable.

I have a publish/subscribe model including an abstract-base-class/interface (call it IDataSubscriber) that can be subclassed by any object that wishes to be notified about e.g. data updates coming in from the network.

There are a number of common-case standard responses (implemented as concrete IDataSubscriber methods) to those data updates that are useful for many situations, and I don't want to have to have to rewrite them separately for every subclass, so I make a concrete or almost-concrete subclass (e.g. StandardDataSubscriber) that contains this common logic.

Finally, in my client code (based on Qt) I have a number of GUI widgets based on QWidget or QPushButton or whatever. I want these widgets to react to published data in the standard way, so I often end up with this:

class MyButton : public QPushButton, public StandardDataSubscriber {...}

... and it handles my needs nicely. It's also possible to do the same thing with "just" single inheritance and interfaces as well, or with Qt's signals-and-slots, but AFAICT do to it that way you end up having to do lots of manual method-call-forwarding through proxy objects (or, alternatively, lots of manual signal/slot connecting), which is less efficient, harder to read/understand, and more error-prone.

Re:Answer

[lgw]

Well, true enough, I haven't looked at anything Google in about 5 years. I exaggerate about caring that much about the style guide - the truth it, Google is a despicable, evil company, and while I might work there to avoid starving, that's only because I'm weak.

But fuck using * for out params with a cactus soaked in Tobasco sauce. The return value of the function is for returning values, which you can do if you do waste it because you're scared of the terrible exception-monster in the closet (and for multiple return values, a non-const reference is non-const). And fuck only having trivial constructors, because, you can't throw exceptions, so you can't do RAII. The 80s had fun music, but the coding style of the 80s needs to go away.

Re:Answer

[lgw]

init() should only ever be a thing where you need to perform some kind of init after construction.

Indeed. Should. No argument there. But half the C++ code I've ever worked on was terrified of the scary exceptions, and so wouldn't do anything useful in constructors, since that might throw, and would instead do all the work in init() so that a #defined error code could be returned (which then this caller would forget to check every so often, leading to fun bugs at some spot quite distant in code from the error).

Re:Answer

[Anonymous Coward]

Nah, Java beats C++ in multiple inheritance by not having it. Definite win there.

Templates are crap, try Lisp and feel the power of a real macro language.

Re:Answer

[Anonymous Coward]

I think you meant RTTI, not RAII.

Re:Answer

[Anonymous Coward]

The standard answer to all C++ criticism:

It's really a pretty good language once you've spent 20 years learning its ins and outs.

Re:Answer

[Anonymous Coward]

[quote]If you are using C++ as such a high level language as Java/C#, you may as well use them because you threw away some of the most useful/valuable parts.[/quote]
On the contrary - with Java/C# I feel like a cripple. No multiple inheritance and most importantly no explicit lifetime control. C++ has many design flows but it's much more powerful than Java.

Re:Answer

[Anonymous Coward]

LOL at how C++ gets new smart pointers every couple years.

unique_ptr replaces auto_ptr after over a decade. Which is quite a bit more than "every couple years".

The only other smart pointers in c++ would be part of third party libraries. The closest you get to smart pointers in C++ were the boost smart pointers, which a) acted as prototypes for the standard smart pointers and b) only covered a subset that could be implemented with C++98 ( the lack of move semantics is what led to the ill advised auto_ptr in the first place).

Re:Answer

[Anonymous Coward]

If you are using C++ as such a high level language as Java/C#, you may as well use them because you threw away some of the most useful/valuable parts.

And say goodbye to my cpu cache? To predictable frame rates when the GC kicks in? To clean and readable matrix/vector math?

Also, Exceptions are EXCEPTIONAL and should be treated as such

One core concept of c++ disagrees. RAII requires a ctor to fail if it is unable to construct an object with valid state, the only way to fail a ctor is with an exception, otherwise you have to deal with zombie objects, half way constructed member objects, incompletely initialized parent variables, etc. . The Google style for c++ avoids this by using C style init, destroy methods, which breaks RAII and automatic initialization and cleanup can no longer happen in ctor/dtor.

Exceptions are flow control, specifically they are flow control to deal with error cases in clean separation from the successful execution, all modern languages ( even Go with its internally used panic/recover ) accept this as a fact and are build around exceptions.

Re:Answer

[Anonymous Coward]

You might want to avoid flying on commercial airliners then, because they have lots of avionics systems running C++ code exactly like that

Currently we have air planes that have to be re-booted every month to avoid integer overflows. We also have stories of software reuse gone wrong ( missile control software that would do a 180 turn over the equator re used for planes), badly secured control networks, auto pilots going haywire when external sensors are frozen, etc. .

If it wasn't for endless testing and pilots there to oversee things we may have a lot more crashes each year. So yeah C style C++ can be real crap.

Re:Answer

[justaguy516]

Most wireless protocol stack implementations are the same; allocate deterministically once and never de-allocate.

As a friend of mine used say, de-allocation in a virtual memory system is strange; sbrk() will . All you do is possibly to release a page in vmem which was never going to get swapped in anyway. There is a chance of additional TLB cache flushing being avoided, but I am not sure that the difference is worth it.

Re:Answer

[Alioth]

Long ago, after writing C++ like Java, I decided it would be much easier and I would be much more productive if I just actually used Java. Many headaches of trying to write C++ like Java go away if you just use Java (or C# instead) and you get easier to understand and easier to maintain software systems.

Re:Answer

[Alioth]

Do you even allocate memory in the sense that most people think about it (in other words, calling malloc or something similar to do dynamic allocation), or just have a region defined for data in your linker scripts and have constant addresses for regions of memory hard coded for certain purposes?

Re:Answer

[Anonymous Coward]

> Java is superior to C++ in almost every reasonable use of C++

Except the ones where you just want to execute a program, instead of a virtual machine + a program.

Re:Answer

[Grishnakh]

So yeah C style C++ can be real crap.

It's better than C++ style C++, which wouldn't even work in a hard real-time system.

But I would prefer to see straight C used in these systems instead. I worked briefly on a project to compare an existing C++ system with one done with straight C and the SLOC was vastly smaller, and even the memory footprint was significantly lower. I don't think it's even that C++ itself can't be written tightly, it's that the C++ stuff has gotten really bloated by the way they define requirements and architect the systems; automatic code generation with DOORS doesn't help at all.

Re:Answer

[Gibgezr]

You are correct: the flags only turn off off exception handling. I really did think there was a flag for RAII; I learned something :)

For more on why we don't use shared_ptr and it's ilk, see http://seanmiddleditch.com/dan...

Re:Answer

[Ihlosi]

And you never run out or memory since you've got an infinite amount of it?

If you allocate everything statically or on the stack, your code won't link if you run out of memory (if your linker correctly performs stack usage analysis, otherwise you can still run into a stack overflow).

Re:Answer

[david_thornley]

Check out Interactive Fiction (what used to be called text adventures). The good IF languages I know all have multiple inheritance. The ability of a safe to inherit Lockable and Container saves a lot of work.

Re:Answer

[david_thornley]

Some C++ constructs will throw under some circumstances. If you are not prepared to catch these exceptions, they will crash the program. The standard hasn't moved away from exceptions. In fact, "noexcept" is a simplification of "throws", so now all you can specify is that a function can or cannot throw, not what sort of exceptions it can throw.

Exactly what can "a=b;" mean? "Foo a = b;" means to use the copy constructor, which is confusing, but simple "a = b;" either uses the standard assignment operator or is "a.operator=(b);" (there's actually some overlap here, since the compiler will attempt to provide a class with an assignment operator if it doesn't have one, and if it does it will completely non-surprising in what it does).

Re:Answer

[lsatenstein]

NONE! Find a real language! *ducks*

For non-ducks, the most important things to know about C++ aren't list in the summery: RAII and shared_ptr<T>

C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java: throwing exception when errors are encountered, writing exception-safe code all the time, returning from functions in the middle, and never, ever, worrying about cleaning up at the bottom of a function what you allocate at the top.

If all of that sounds wrong to you, congrats, you're a C coder, and there's nothing wrong with that. Good C code is good code. But C++ is designed to be used with "scoped objects", that is, every object cleans itself up when you exit scope, so you really have to internalize the tools for that, and that mindset.

Good C++ code is code that reads well, and is easily maintained. How much C++ code is needed for a beginner?

Syntax/grammar, classes, templates, inheritance and polymorphism and ability to debug. Anything else is a plus

Re:Answer

[lgw]

A new hire from college is not a "beginner", at least not anywhere I've worked recently. If you choose to interview in C++, you had better know the basic STL classes (string, vector, map) as well. Sure, it's rare to see an interview question that would probe RAII/resource management for entry-level, but knowing that stuff coming in would really help. (We don't care what language someone is good in for an entry level job, but they have to demonstrate some depth in one language of their choice.)

Re:Answer

[lgw]

If you don't really need to make systems calls, that's absolutely the right answer IMO. I only favor C++ if I need to do platform-specific messing around with filesystem behavior, or low-level netcode. As soon as you need to do any sort of bit-twiddling, or you care at all about asymptotically-constant-time performance improvements, Java stops being useful (and I always prefer C# to Java where practical - same functionality with half as many lines of code).

I really don't see the point of using C (or C-style coding in C++) outside of kernel-mode stuff, however.

Re:Answer

[lgw]

Only catch exceptions that you can fix is the rule. If you can't actually do something useful about an exception, why would you catch it? There's nothing worse than Pokemon code!

catch(...) make perfect sense in one place - in main(), followed by logging the exception and terminating the process.

The whole point of this entire mindset is to stop checking for errors individually after each call. This lets you eliminate about 2/3s of your lines of code, all boilerplate, and reveal the actual business logic of each function by sweeping away the clutter. But there's a whole crowd of devs who like the clutter. They're not actually very good at coding, but mindless repetition they can do. This mindset is anathema to those guys. RAII without exceptions leaves half the clutter, and so doesn't achieve the goal.

Re:Answer

[lgw]

That's not C++. That's "C with classes". (No true Scotsman uses C++ that way!) There should really be a new C standard that adds classes, C++-- or something. (BTW, a sure sign that people don't understand C++ is when they argue that the STL is slow.)

It's funny to hear game devs argue that C++ is too abstract, and then in the next breath wonder how they're ever going to get their code to use more than one core. I hope you're not that guy!

I'm in a different world. To me, performance means infinite horizontal scalability. Clarity and performance of work distribution across N machines (for arbitrary N) is where the fun is. Counting cycles and optimizing bytes got boring when machines got fast (a Raspberry Pi blows away the mainframes I started on).

Re:Answer

[Spazmania]

That's what C is for -- situations where low overhead is important. You retain that feature when you use C++ as if it was C but lose it when you employ Java-like abstractions instead.

Re:Answer

[Anonymous Coward]

You retain that feature when you use C++ as if it was C but lose it when you employ Java-like abstractions instead.

Huh? You "lose" native code when you use Java-like abstractions in C++? That's news to me!

Re:Answer

[angel'o'sphere]

I did not argue about "shared_ptr", that was someone else.

The article you linked is bogus. I stopped reading after this: Ownership of resources is a central part of software engineering.

That is plain wrong. The idea of "ownership" was introduced with C++ ... it is a completely flawed idea to approach resource handling especially memory management.

Example:
class Person {
Person *spouse;
}

Who owns whom, when to delete the spouse? Obviously the idea that one person owns the other one makes no sense in terms of C++ ...

Re:Answer

[angel'o'sphere]

Perhaps read a book about the Taligent Frameworks?

When do you use (single) inheritance? When you "extend" a class or when you "specialize" a class? Whenever you want to extend a class in C++ (lets name it B) you should not inherit from it but craft a new class (lets name it N), worst case via a mixin template construct, and compose the desired class by multiple inheritance so that D is specializing B and N.

That way you can reuse N without being dependent or messing up D or B.

The simplified single inheritance and interface model caters for all practical examples, and *vastly* simplifies the internal workings. (X)

No, it does not. As you have to program the implementation of everything you "inherit interface wise" multiple times everywhere where you "implement" that interface.

If you want to use simple delegation (via IDE code generation etc.) the delegatee loses the original this pointer ... (X) above No simplification but a complication.

How large is a pointer to a member variable?
That is a stupid question. Yes, I know there are no stupid questions, only stupid answers. However asking questions that don't belong to the context: is stupid.
Answer to your question: implementation dependent. What exactly do you mean with a pointer to a member anyway? A true C++ member pointer? Like &classname::member? Usually as big as any pointer on the given platform. But can be optimized as small as a byte, however I'm not aware of any compiler that does that.
If you mean &object.member, a safe bet is: the size equals the typical pointer size on the given platform.

Re:Answer

[angel'o'sphere]

Do you remember a language name? I'm looking for an interpreted MI capable language to port to iOS and use as scripting language for an App.
Any idea?

Re:Answer

[Spazmania]

No, you lose efficient code. For a simple example, the string abstractions in C++ and Java are much, much less computationally efficient than manipulating a C character array.

Once you're willing to take that hit for the sake of the things the abstractions gain you, Java's bytecode machine is a tiny additional hit versus the far superior design of the language itself.

And anyway, in case you didn't know it there are tools (like gcj) for compiling java straight to native code if that's what you really want. Only that usually isn't what you want because object code portability is damn useful.

Re:Answer

[Anonymous Coward]

So, with C++ I get slower performance using such abstractions, and with Java I get the slower performance, PLUS have to wait for the JVM to launch or the JIT compiler to do its job...

I have nothing against Java as a language. It makes some things easier for the developer. But saying it's superior in almost every use case doesn't take performance into account.

Re:Answer

[Anonymous Coward]

>The standard libraries have actually been moving away from exceptions, haven't they? C++11 introduced 'noexcept'

No, that was to enable certain optimisations, not "moving away" from exceptions. Rest of your blurb about exceptions is just so google-indoctrinated I can't even type a serious response to it without raging at my current level of drunkenness.

>In a nutshell the style guide is, in order, "be readable" followed by "be consistent". It is hilariously easy to write unreadable, bug-prone C++ code. Nobody cares if your code is perfect and correct, they care if the next guy along can modify or use it correctly and it is useful to have a style guide

Obviously having a consistent style is better than not, but it doesn't change the fact that the style that the guide dictates is, in short, crap, clearly written by Java programmers (read: bad programmers) who don't really "get" C++ to help an organisation filled with other Java programmers (read: bad programmers) to cope with C++.

>to make some of the more hard to reason about things impossible. How many different bits of code could the statement 'a = b;' potentially execute? (It's a lot - copy constructor, operator=, operator Foo(), etc.)

If you really know C++ in a codebase written by people who really know C++ this is not an issue as everything will just do the right thing - again an artefact of letting a bunch of Java programmers (read: bad programmers) loose with C++ for years.

Re:Answer

[Anonymous Coward]

You can think of it this way, it's perfectly acceptable to throw an exception in an avionics system when it's appropriate to crash the plane - exceptions are for exceptional situations.

Re:Answer

[david_thornley]

I've drifted away from the community, but Inform was the most popular choice. It ran on recreations of Infocom's zcode runtimes. I have an iOS app called Frotz (interpreters are frequently named after spells in Infocom's Enchanter series) that plays such games. I'd use it more if typing was easier on my phone.

Re:Answer

[Spazmania]

C is a good choice where performance is critical for small or large programs. C++ used like C is comparable.

Perl or Python are good choices for short programs where ease of development and programming practices resilient to buffer-overflow style bugs are more important than performance.

Java is a good choice for large, complex programs where safe and secure programming practices are more important than micro-optimized performance.

See what's missing from that picture? Any role where C++ used with the low-performance safe practices abstractions is a better choice than something else.

Re:Answer

[Anonymous Coward]

and it's ilk

"its".

Re:Answer

[Anonymous Coward]

It's design

"Its".

It's implementation

"Its".

Re:Answer

[Anonymous Coward]

Java interfaces are a form of multiple inheritance. I would not call C++ multiple inheritance a great thing when the C++ language left out providing an equivalent for the lighter weight mechanism that Java interfaces are.

But I think .NET/CLR does a better job a dealing with some of the issues Java does not (methods with same signatures, being specific about which interface you mean't to implement or use, etc...)

Nerval

[Anonymous Coward]

+5 interesting post!

All of it.

[Anonymous Coward]

All of it.

None. Go meta.

[Anonymous Coward]

Knowing C++ shouldn't matter. Demonstrating that you can quickly master and use any language should.

Re:None. Go meta.

[Anonymous Coward]

There's certainly a grain of truth there. As the classic saying goes: "programming is easy, making applications is hard".

Re:None. Go meta.

[Anonymous Coward]

This is surprisingly accurate. No amount of programming language knowledge will help you write a good program if you can't design the software from a practical level, upwards. What do you want the computer to do? What exact steps do you want it to take? Good, now translate that into $programming_language. That last part is actually the easiest part of software engineering.

Re:None. Go meta.

[sexconker]

Yup. The language / environment is largely irrelevant. That's what references, manuals, APIs, and all other forms of documentation are for.
Knowing how to program is what matters.

Re:None. Go meta.

[TWX]

How does one demonstrate knowing how to program during an interview process if one doesn't know at least a fair amount about the language and its basic methodology?

Someone might have twenty years with RPG, COBOL, FORTRAN, and DB2, but that doesn't they'll be effective in C++.

Re:None. Go meta.

[war4peace]

Pseudocode.
http://en.wikipedia.org/wiki/P...

Also Drakon charts.
http://en.wikipedia.org/wiki/D...

I actually was taught DRAKON charts (a variation of it) in high school back in '96. It tremendously helped me in more ways than strictly programming (which I never embraced). My teacher used to call it pseudocode back then, although Pseudocode is different.
At the time, generating a high level overview of the processes in DRAKON before building any code was mandatory, and it sped up code generation because you always knew what the next steps would be.

Re:None. Go meta.

[dejanc]

How does one demonstrate knowing how to program during an interview process if one doesn't know at least a fair amount about the language and its basic methodology?

Candidate should be able to answer any questions in pseudo code. You are right that each language has its own intricacies, and e.g. perfect code in C is terrible code in C++, but C++ is not specific enough that general programming principles don't apply.

Reading a book about the language over the weekend before the interview won't make an experienced programmer out of you, but you will know what the language is about and you will have a good overview of most features of the language.

Besides, in my experience at least, candidates who have a lot of experience in the language that's used don't gain as many points as the ones who know ins and outs and best practices for libraries and frameworks which are used in the organization.

Re:None. Go meta.

[shadowrat]

i've been working with c++ for the past 4 years. prior to that i had 15 years experience using all kinds of other languages. In my interview, I said, "hey, I don't know the c++ for solving this problem, but it would be easy in c#." they said have at it. i was hired.

Re:None. Go meta.

[Anonymous Coward]

OP is saying "If you know Spanish that should be good enough for France since you can just pick up French along the way. They're all Romance languages so it'll work out soon enough".

Soon enough... Except when the company wants you to know C++ tomorrow rather than 2 months later when you've mastered the API.

He has a point but it's not something I would bank my resume on...

Re:None. Go meta.

[arielCo]

Unless they need you to be productive shortly, not in 2-3 months while you learn generic programming and STL/Boost.

Re:None. Go meta.

[Anonymous Coward]

I put that on my resume, basically the indication that I was proficient at rapidly learning and employing new languages with a high degree of fluency. . . I get the feeling recruiters can't actually read though - they just recognize the shapes of various acronyms that are trendy.

Re:None. Go meta.

[Anonymous Coward]

I have two years of RPG and it's two years too many. Learning dead languages is dumb.

Re:None. Go meta.

[Anonymous Coward]

Unless someone is completely useless, they can learn the basic STL in a day or two plus a quick reference sheet. For anything more detailed, even a C++ expert is going to occasionally have to refer back to the list of algorithms, etc... Any entry level programmer is only going to be using generic programming not designing generic C++ libraries. I expect any of my new hires to be able to code effectively in C++ in a couple of weeks (with ongoing code reviews for probably a year or 2). Despite our local university primarily teaching Java alongside brief introductions to other languages, I've never had a new grad struggle with C++ from a productivity standpoint.

Re:None. Go meta.

[Anonymous Coward]

Have fun getting that through hiring managers.

Re:None. Go meta.

[angel'o'sphere]

Yes, it should.
But actually C++ is a beast of a language which no one so far quickly mastered.
All we have now in C++, like STL, boost etc. is stuff that was envisioned by people who minimum had 10 years language experience before they even came to the idea to (ab)use language features like that.
When I read the first time about the concepts of the STL (that was round 1993, and it was not even called STL then) I was shocked about its simplicity and that I was so dumb that I never came to that idea myself. Basically the only "genious" I had at that time was that I had invented "traits" myself ... because I needed them. (Had about 5 years C++ experience then)

Re:None. Go meta.

[Anonymous Coward]

In general I agree with this. C++ is the one exception to that rule though, as it is more complex and less forgiving than virtually any other language out there. It takes a week to learn most languages, and takes a year to learn C++.

Re:None. Go meta.

[Anonymous Coward]

I did the same except substitute (non-compiling) F95 for C#. They didn't give a flying fuck about the C++ code; they wanted to see whether I could structure an algorithm the way they wanted. So I wrote something that almost, but not quite, would compile under F95, with the errors coming from pushing F95 closer to C++ in the areas where I *knew* what C++ would be doing. The only challenge was making sure that the code was clean enough that differences in syntax were unimportant. Evidently I did that, since they gave me the job...

Re:None. Go meta.

[IamTheRealMike]

That sort of logic holds true when moving between languages that are very similar. The transition between Python and Ruby or Java and C# spring to mind.

However if I need a C++ programmer and need one pronto, I'm not gonna hire a guy who has only JavaScript on his CV no matter what. Learning C++ is not merely learning a different way to create an array or slightly different syntax. To be effective in C++ you need to know how to do manual memory management and do it reliably, which takes not only domain knowledge but more importantly: practice and experience. You need to understand what inlining is. You very likely need to understand multi-threading and do it reliably, which takes practice and experience a pure JS guy is unlikely to have. You need to be comfortable with native toolchains and build systems: when the rtld craps its pants and prints a screenful of mangled symbols you need to be able to understand that you have an ABI mismatch, what that means and how to deal with it. Unfortunately that is mostly a matter of practice and experience. You might need to understand direct manipulation of binary data. There's just a ton of stuff beyond the minor details of the language.

Could the pure JS guy learn all this stuff? Of course! Will they do it quickly? No.

Re:None. Go meta.

[itsenrique]

If you don't have two months to get someone up to speed, maybe you should have started looking two months earlier.

Re:None. Go meta.

[MouseTheLuckyDog]

Except that there are two "mainstream" languages which I would say are the equivalent of Chinese or Japanese. These are scala and C++.
  To use these effectively you are going to have learn to think in a whole different way.

Re:None. Go meta.

[Dog-Cow]

Right. Because it was obvious the health-nut who jogged to work every day was going to suffer a heart attack on the way to the grocery store and leave his team in the lurch.

Not everything can be planned.

Re:None. Go meta.

[dentin]

The big problem with C++ is that you literally can't master it quickly. You can learn the basics quickly; you can become decently good at it in a couple of years if you have prior programming experience. But I know a lot of professional programmers, and I can point to precisely zero of them (myself included) that have 'mastered' the language. We each know pieces of the language, and some of us cover rather wide areas, but all of us have to occasionally research how exactly various constructs work.

Re:None. Go meta.

[david_thornley]

However, if they've had five years with reasonably modern languages they'll probably learn C++ just fine. There will be things to get used to in C++, but there shouldn't be too many unfamiliar concepts.

Re:None. Go meta.

[Anonymous Coward]

Except when that doesn't work. Typically only 1:20 applicants are "good enough programmers" to pull this off in my experience.

Just a recent case: we hired people to write a Win32 DLL and despite being told the delivery had to be a Win32 DLL, two separate programmers apparently couldn't be bother to follow instructions (or know how to get paid - a contract is a contract) and delivered the a .Net DLL instead. We have to have Win32 for cross platform reasons - it's not an option. No amount of insistent could get them to delivery what was contracted. So we didn't pay either.

Now if "going meta" actually worked, this simply wouldn't have happened. But most programmers are simply not that good, even when they aren't brogrammers!

Re:None. Go meta.

[Anonymous Coward]

To be effective in C++ you need to know how to do manual memory management

Speaking as a C guy with that knows C++ up to and including these newfangled one line comments, I thought the whole idea of C++ was to automate the memory management?

Being able to write a multiserver microkernel

[new_01]

Should just about do it.

How to read f*ucked up code

[mveloso]

The biggest skill in C++ is how to read code that's got templates, generics, overloaded operators, and custom keywords.

"What do you mean they overloaded '+' to merge objects?"

"This doesn't look like C++, it looks like some foreign language."

"Oh, we reversed the meaning of + and - because the senior guy thought that the original semantics were incorrect. But only for some objects."

Re:How to read f*ucked up code

[Em Adespoton]

THIS. The things to look for in entry-level C++ are:
1a) a grasp of ANSI C
1b) a grasp of OOP
2) a demonstrated ability to figure out how to understand all the legacy C++ code
3) a demonstrated ability to write new C++ code in the style of the legacy code such that the next person who comes along has a clue as to what they were meaning to do
4) appropriate documentation (via comments AND proper code structuring)

But what counts even more is that the person is a good working fit with the senior programmer in general, and appears to be someone who can learn as they go (because no matter how good their C++ skills are, they're going to be DOING IT WRONG according to the senior programmer).

Re:How to read f*ucked up code

[ljw1004]

The biggest skill in C++ is how to read code that's got templates, generics, overloaded operators, and custom keywords. "What do you mean they overloaded '+' to merge objects?"

Irony: a C programmer who doesn't like languages that let you shoot yourself in the foot :)

Re:How to read f*ucked up code

[Anonymous Coward]

Lets all stop with the overloading, mmkay?
Sure its a cool trick to do in a class, but not worth hunting down when maintaining crapcode (which is 80% of the time)

Re:How to read f*ucked up code

[Cro Magnon]

But what counts even more is that the person is a good working fit with the senior programmer in general, and appears to be someone who can learn as they go (because no matter how good their C++ skills are, they're going to be DOING IT WRONG according to the senior programmer).

Very very true! I'm not a C++ guy, but everytime I got put on a different COBOL project, I had to adjust to a different way of doing it.

Re:How to read f*ucked up code

[SuperKendall]

That's entry level C++? That list sounds like at least a mid-level C++ programmer... how are they supposed to be entry level but have had the experience to understand a wide range of legacy code?

Re:How to read f*ucked up code

[Anonymous Coward]

The biggest skill in C++ is how to read code that's got templates, generics, overloaded operators, and custom keywords.

The biggest skill in C++ is how to not write code that's got templates, generics, overloaded operators, and custom keywords.

Like the biggest skill in free will is how to not kill and fuck everybody in sight.

Re:How to read f*ucked up code

[goose-incarnated]

The biggest skill in C++ is how to read code that's got templates, generics, overloaded operators, and custom keywords.

"What do you mean they overloaded '+' to merge objects?"

"This doesn't look like C++, it looks like some foreign language."

"Oh, we reversed the meaning of + and - because the senior guy thought that the original semantics were incorrect. But only for some objects."

This. Outside of academia I've never encountered C++ written in a sane manner. Hell, even inside of academia things get a bit iffy. Things you can expect to see if you ever maintain C++ code:

* Objects passed by value which don't have a deep assignment copy constructor.

* File scope objects using other file-scope objects - "Because VS2010 ensures instantiation order."

* Dependencies with no real reason; this is especially bad on Qt projects. Why use std::vector when you can use a QVector?

* const char *use_this_later = MyQstringObject.toStdString().c_str(); // Bang! There goes another foot... maybe if we had GC...

* You used copy semantics? You *meant* move semantics (This should never had made it into the standard).

* Overloaded functions - "myfunc (foo);" does something different to "myfunc (bar);", because hilariously foo and bar are different types

* Ditto for operators - "foo + bar" does something quite different to "bar + foo".

* Other than "type var[size];" there is no primitive array type. Arrays are implemented in the library, not in the language like every other sane language.

* No GC. In other languages you can get away with it, but in C++ you stand no chance - someone, somewhere back in the mists of the past, would have created a critically dependent-upon class that *will* return a temporary object that gets deleted automatically while you still have references. QString, for example.

All of the above, in addition to all of the gotcha's in C as well. In this day and age there is very little reason to use C++. If you need objects, UI, etc use Java or C#. If you don't need objects use C; at least you can trivially expose every single piece of C code you've written to other languages via a library. This lets you reuse your code. The only C++ code you'll ever expose to other languages are C-compatible functions.

I'm looking, right now, at a mountain of code, some 20+ classes, many with file-scope instantiations, every single fucking object a Qt object. The original developer noticed that the code for Qt-derived classes won't compile without a copy constructor so he very cleverly made empty copy constructors for all the classes so that even a shallow copy won't be performed. As expected, he also stores instances in containers - which means every now and then the program would give incorrect results with seemingly no predictable occurrences. It doesn't crash, mind, just gives incorrect answers.

Good luck; you'll need it.

Stay away from C++ - stick to languages that implement context-free grammars only.

Re:How to read f*ucked up code

[Anonymous Coward]

Parent has nothing to do with shooting yourself in the foot, it has way more to do with readability of code. Yes you can create an awfull mess in C if you really work it but it's far more easier and usual in C++.

Re:How to read f*ucked up code

[arielCo]

Degrees of damage. Hell, it's the oldest joke in the programmer's book:

C: You shoot yourself in the foot.

C++: You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying "That's me, over there."

Re:How to read f*ucked up code

[Anonymous Coward]

Stay away from C++ - stick to languages that implement context-free grammars only.

for example...?

Re:How to read f*ucked up code

[Anonymous Coward]

If you have someone writing code like that, then you fire them. If C++ starts looking like perl, then your doing it wrong. Operator overloads should only ever behave like the operators they are overloading. Write for people to be able to read your code, not to obscure it.

Re:How to read f*ucked up code

[Dareth]

You think that is bad,,, see what they are paying for someone with that skill set.

Re:How to read f*ucked up code

[Anonymous Coward]

* Objects passed by value which don't have a deep assignment copy constructor.
* File scope objects using other file-scope objects - "Because VS2010 ensures instantiation order."
* Dependencies with no real reason; this is especially bad on Qt projects. Why use std::vector when you can use a QVector?
* const char *use_this_later = MyQstringObject.toStdString().c_str(); // Bang! There goes another foot... maybe if we had GC...

If someone is doing any of these, then they should be fixed at the code review stage. There's no reason to let any of these live. If someone insists on continuing, then let them find a new place of employment.

* You used copy semantics? You *meant* move semantics (This should never had made it into the standard).
* Overloaded functions - "myfunc (foo);" does something different to "myfunc (bar);", because hilariously foo and bar are different types
* Ditto for operators - "foo + bar" does something quite different to "bar + foo".

If there are differences in these behaviours, then, again, you're doing it wrong. "Foo + Bar" should always behave analagously to "bar + foo". There's barely a language around that gets away without overloaded functions, so failure to grasp that is a failing indeed. Move and copy semantics really only need to be understood by library writers. For everyone else, they basically just need to understand that it's ok to to return vectors by value.

* Other than "type var[size];" there is no primitive array type. Arrays are implemented in the library, not in the language like every other sane language.

So, other than an array type, there's no array type? What does that even mean? The whole strength of C++ is that things can be built into libraries rather than baked into the language. My container with feature Y is just as integrated into the language as the STL's vector, or a "type var[size].

Re:How to read f*ucked up code

[Anonymous Coward]

I've been a C++ programmer for 15 years and have no idea what most of those things are, OK, I know, but have never used them. I'm sure it depends on the problem domain and what you are trying to accomplish. Se MISRA/High Integrity C++ for example. Yeah, you use things like class interfaces (and classes) and all the C, but not a lot of the other fluff of the language.

Re:How to read f*ucked up code

[pla]

Other than "type var[size];" there is no primitive array type

I agree with most of what you said, but this one stumps me. You've just defined a primitive array - An array named var of type type and size size. Other than its... well, primitiveness (no fancy default conversions, no memory management, no overloads to deal with it as a whole), what about that syntax do you object to?

Re:How to read f*ucked up code

[Anonymous Coward]

I've always heard it as:

C: you can shoot yourself in the foot.

C++: If you're not careful, you'll blow your leg off.

Re:How to read f*ucked up code

[NoOneInParticular]

Ditto for operators - "foo + bar" does something quite different to "bar + foo".

This holds for practically all languages that overload '+' for string concatenation. Luckily in C this doesn't hold: there "foo+bar" always equals "bar+foo", even for strings.

Re:How to read f*ucked up code

[Anonymous Coward]

You maintain 20+ classes ?
I maintain 1000 classes and it's not at all confusing, cause the whole project is soundly set up with namespaces well thought out inheritance patterns.
In the end, a good programmer will do wunderful things with C++.
The big difference against C# and java is that a mediocre programmer will not do a mediocre job, but an aweful job.

Re:How to read f*ucked up code

[Grishnakh]

I'm looking, right now, at a mountain of code, some 20+ classes, many with file-scope instantiations, every single fucking object a Qt object. The original developer noticed that the code for Qt-derived classes won't compile without a copy constructor so he very cleverly made empty copy constructors for all the classes so that even a shallow copy won't be performed. As expected, he also stores instances in containers - which means every now and then the program would give incorrect results with seemingly no predictable occurrences. It doesn't crash, mind, just gives incorrect answers.

Qt is an excellent library. I'm using it now on a personal project, and a lot of embedded systems use it. It sounds like the code you're looking at was written by someone completely incompetent. Qt does not need a copy constructor to compile a Qt-derived class. However, when you're doing a Qt project, usually most of your objects will be Qt objects. That's the whole idea: Qt is basically an extension to the language, and it's easier when you jump in and do everything the Qt way, including using Qt's containers and other base classes.

Re:How to read f*ucked up code

[angel'o'sphere]

Actually it goes like this:

C: You shoot yourself into the foot.
C++: You shoot yourself into the foot, and have blown of your whole leg.

Re:How to read f*ucked up code

[Tanuki64]

Another one ranting about something he understands nothing about. Not only that, but he comes with unbelievable 'facts' to back his story. So, all classes are QObjects? Making copy constructors for them? If what you said is true and you had the slightest amount of knowledge about what you write, you certainly would not have ranted about not performed shallow copies. Shallow copies... deep copies... irrelevant. Even beginners of Qt learn very fast that QObjects are non-copyable by design. Both copy and assignment constructors are disabled in QObjects. Under those circumstances:

As expected, he also stores instances in containers - which means every now and then the program would give incorrect results with seemingly no predictable occurrences. It doesn't crash, mind, just gives incorrect answers.

Ridiculous to assume that the program only now an then give incorrect results. Since QObjects cannot be copied into a container by value, it can never give correct results.

So I can only give the advice: Don't listen to the parent. He is a liar and has no idea what he is talking about. The usual C++ hater. Probably it's just sour grapes on his part.

Re:How to read f*ucked up code

[Anonymous Coward]

Ditto for operators - "foo + bar" does something quite different to "bar + foo".

This holds for practically all languages that overload '+' for string concatenation. Luckily in C this doesn't hold: there "foo+bar" always equals "bar+foo", even for strings.

Huh?!? First of all, C doesn't have "strings", it only has "char *" or "char []". Adding two "char *" will give you a pointer to some random byte of memory; it certainly won't concatenate strings. And adding two "char []" is illegal.

Re:How to read f*ucked up code

[Anonymous Coward]

Problem: We couldn't get anyone with 10-15 years coding experience with this exact skill set to do the job at $40k/yr.
Solution1: We need more H1-B visas to fill this technical skills/wage gap!
Solution2: We need to push coding for everyone to push down wages.

Re:How to read f*ucked up code

[itsenrique]

During their unpaid internships and a few boot camps after college, welcome to the new economy.

Re:How to read f*ucked up code

[Anonymous Coward]

That's entry level C++? That list sounds like at least a mid-level C++ programmer...

You got it backwards. The entry level programmer does not yet know what to stay the hell away from in C++.

Re:How to read f*ucked up code

[Anonymous Coward]

So full of awe, amazing, it'll blow your mind? No wonder they want them!

Re:How to read f*ucked up code

[UnknownSoldier]

Great post!

It is too bad C++ doesn't have a standardized way to do inner, outer, and wedge products. :-/

Re:How to read f*ucked up code

[Anonymous Coward]

I'm not going to say you can't write pretty fucked up C++ code. Control flow can be hard to grasp with templated functions and operator overloading. especially with cowboy programmers making domain specific languages from overloaded operators. Coding styles were so bad, Java chose to not implement these features originally. Nowadays people should know better and a lot of C++ code reads reasonably well.

But really C++ programmers are spoiled compared to what Scala programmers have to decipher, and yet it seems to be a popular enough language.

Re:How to read f*ucked up code

[Dog-Cow]

WHOO + OOSH

Re:How to read f*ucked up code

[Anonymous Coward]

I'm looking, right now, at a mountain of code, some 20+ classes, many with file-scope instantiations, every single fucking object a Qt object. The original developer noticed that the code for Qt-derived classes won't compile without a copy constructor so he very cleverly made empty copy constructors for all the classes so that even a shallow copy won't be performed. As expected, he also stores instances in containers - which means every now and then the program would give incorrect results with seemingly no predictable occurrences. It doesn't crash, mind, just gives incorrect answers.

Sounds almost like the code I am trying to make seens of, but instead of Qt it uses a old version of rouge wave's libraries instead with RWCollectable classes everywhere(that needs a copy constructor) and every copy-constructor is empty!. I would love if it it used Qt instead or RW. Funny thing is that the code is written in Trondheim, the same place where Qt started. and every constructor calls a init method instead of just setting the variables.

Re:How to read f*ucked up code

[Anonymous Coward]

"Oh, we reversed the meaning of + and - because the senior guy thought that the original semantics were incorrect. But only for some objects."

Do you know who wrote this? I've got some of his code here and I need to forward my expenses for therapy.

Re:How to read f*ucked up code

[Anonymous Coward]

THIS. The things to look for in entry-level C++ are: 1a) a grasp of ANSI C

Yep.

1b) a grasp of OOP

Yep.

2) a demonstrated ability to figure out how to understand all the legacy C++ code

I have tequila - will I need to upgrade to LSD?

3) a demonstrated ability to write new C++ code in the style of the legacy code such that the next person who comes along has a clue as to what they were meaning to do

I can do that, but I'd prefer not to get a lobotomy.

4) appropriate documentation (via comments AND proper code structuring)

Very funny!

Re:How to read f*ucked up code

[Anonymous Coward]

Like the biggest skill in free will is how to not kill and fuck everybody in sight.

That's a funny thing about that flash app we outsource to Uganda...

Re:How to read f*ucked up code

[Em Adespoton]

You, sir, sound like an excellent candidate for an "experienced C++ programmer" position.

8 Hours

[Anonymous Coward]

Perhaps 12 or 24, depending on which book you buy.

Which C++?

[Anonymous Coward]

Is it abort maintaining some old code which tends to be more like C with use of class instead of strict,
Or is it C++14 which is a much more modern language?

Re:Which C++?

[GerardAtJob]

That's the real question! Too bad I'm all out of points!

Not much

[sls1j]

If you have *real* programming experience your don't need much. Learning a language doesn't take too long if your willing to put in the time. Case in point. I got a job programming in Java, even though my Java experience was all from college 10 years previous. Eventually converted that job from a Java job to a c# contract with no experience, and then with the 6 months experience in c# landed a full time job programming in c#.

Re:Not much

[BlackPignouf]

I wouldn't like to clean up after you.
There's a difference between "learning a language" and "knowing how to write clean and maintanable code while avoiding subtle caveats".

Re:Not much

[Anonymous Coward]

Exactly! If you can handle a few language paradigms (say C, Java, Lisp and Prolog) you can handle pretty much anything thrown at you. It may take a bit to really get the feel for a new language, but that's what code reviews are for.

Re: Not much

[Anonymous Coward]

There's also looking a difference between actual programming and cobbling together trendy frameworks.

Re:Not much

[Zero__Kelvin]

" Learning a language doesn't take too long if your willing to put in the time."

That is possibly the most stupid claim I have ever seen asserted. (and I've been a Slashdot community member for more than 15 years.).

Re:Not much

[Dog-Cow]

It's not just stupid, it's nonsense. "If you put in 15 hours, it will take 15 hours." That's either a big duh, or the most stupid assumption yet.

I'd go with...

[jones_supa]

Classes, class inheritance, smart pointer, vector, operator overloading.

That should suffice as the starter pack. You can learn the rest in your job when the need comes.

Subjective questions deserve subjective answers

[Dunbal]

Some individuals can sell themselves very well. That's why you find a lot of poorly qualified people with jobs they clearly don't deserve to have. Other people aren't too good at the whole job application process and convincing people they are the right one for the job. So they get passed over even if they have better actual skills. Seriously do you plan on hiring a candidate based on coding skill alone?

Simple Answer

[Dishwasha]

Enough C++ to get the job.

Re:Simple Answer

[Anonymous Coward]

I would change that to: "get and do the job".

But yeah, pretty much that.

Re:Simple Answer

[Dishwasha]

The poster did not specify that they wanted to keep the job, only to land it.

As much as possible... or none at all

[Thornburg]

Any really good company/department is going to find it more important to find the right person than skills in a particular language.

Obviously, a person who is a good fit in other ways and has experience in the exact skill/language is the best, but you're better off hiring someone good who doesn't know the language (and then helping them learn it) than you are hiring someone who's not a good fit but does know the language.

When I'm involved, I want to see at least 2 different similar skills (in this case, programming languages), to prove that the person can learn and has a core understanding of the common principals.

So, learn a few languages (preferably at least one of which is popular), and be prepared to learn a new one for a job.

Do you really want to work at a place that isn't willing to take the time and money to train the right person? Odds are you'll be looking for a new job before long (either by your choice or theirs).

Re:As much as possible... or none at all

[JustNiz]

>> Any really good company/department is going to find it more important to find the right person than skills in a particular language.

Not at all. Companies used to be more like that but now its all about whether you can hit the ground running.

Re:As much as possible... or none at all

[Rob Riggs]

An entry-level programmer still needs to know enough about the language to get in the door: how to construct a class, class visibility, exceptions, a bit of the STL. But to me it is far more important that they know data structures, algorithms and their complexity, parallelism, OO-programming principles, functional programming principles, and show a passion for their profession. I don't expect an entry-level developer to know much about software life-cycle management, source control, unit testing, package management, C++ meta-programming, or anything of that nature. I expect them to maintain other people's code and learn from what has already been written, and from that learn all the things about software engineering that most universities completely ignore.

Re:As much as possible... or none at all

[war4peace]

Rather... never hit the ground. Keep flying. And be fed insignificant amounts of $$fuel.

Re: As much as possible... or none at all

[Anonymous Coward]

Well, what they do now isn't working, which is a total shift from skills at interview time to blind obedience on the job.

*shrug*

[Anonymous Coward]

Do C++ developers get paid more than .net developers? Or Java developers?

Re:*shrug*

[Anonymous Coward]

C++ programmers do get paid more, but there's much, much more .NET and Java work around.

Re:*shrug*

[Anonymous Coward]

No!

Re:*shrug*

[jeremyp]

Danger money

rephrasing the question

[Anonymous Coward]

How much C++ do you need to pass an interview?

"How do you monetize Slashdot?"

[93 Escort Wagon]

That's a question Dice posed to several middle managers recently. "We paid a lot of money for this tech property, but we have absolutely no idea how to use it", said one Dice higher up who requested anonymity. "Seriously - help us out here! There are over three million Slashdot subscribers, but none of them will click on an ad!", he lamented. "And they won't come over to dice.com and discuss these stories we keep cross-posting! We don't want to just be a second-rate job board forever..."

Re:"How do you monetize Slashdot?"

[Anonymous Coward]

ahahahah

Re:"How do you monetize Slashdot?"

[NoNonAlphaCharsHere]

How much Salshdot culture should you know before you buy Slashdot.org and start posting stories like this and fucking with the UI?

Re:"How do you monetize Slashdot?"

[Anonymous Coward]

Dice = MySpace
indeed = Facebook

I hope that doesn't get me permabanned?

Re:"How do you monetize Slashdot?"

[dave562]

Well played sir.

Re:"How do you monetize Slashdot?"

[Anonymous Coward]

but none of them will click on an ad!", he lamented.

I'm not registered, but DID click on two ads recently. One was for the laser-projects, which sounded like an interesting technology, but I'm still fighting myself whether or not the 17k$ are justified just to have one in the living room to watch TV once in a while. The other one was for some electrical motors, quite nice, and I'm sure I would consider them should I'd need one, but already forgot the name of the manufacturer.

Top-notch ads here. Much more useful than what I see elsewhere (I don't keep cookies, so advertisers have trouble targetting by brosing habits. Also, as soon as I've already decided what I might want, adds following-up on that are meaningless.).

Re:"How do you monetize Slashdot?"

[Anonymous Coward]

Nerval's Lobster must be a DICE shill

Re:"How do you monetize Slashdot?"

[Anonymous Coward]

But don't those Like buttons track you?

oooh really?

[Anonymous Coward]

and that job isn't teaching the ins and outs of programming

That is called mentoring. It usually one of the jobs of a 'sr developer'. Learn on your own time is a crap way of putting the cost of learning your system onto the developer.

No such thing

[Anonymous Coward]

Companies looking for C++ coders doesn't generally look for entry-level programmers.

Learn C++14 including the new stuff (move semantics in particular) and learn it really really well.

Every language has its gotchas

[Rei]

And it's important for new programmers to learn them - more important than learning syntax.

  For C++ for example I'd warn about classes containing pointer member variables with implicitly-defined assignment operators / copy constructors. You have Foo a and Foo b, where Foobar has a member variable "int* bar". So the newbie does "a.bar = new int[100];" then later "b = a;" then later b goes out of scope, then they try to use a.bar and the program crashes. Seems to be a very common C++ newbie mistake. Eventually they learn to see pointers in class definitions as having big "DANGER" signs over them calling their attention, and/or rely on smart pointers.

Any others that people can think of that are common?

Oh, here's one more: iterator invalidation. A newbie who's not warned about this in advance will likely get bitten by it several times before the point gets driven into their head: "if you're using a class to manage memory for you, it's going to manage memory for you, including moving things around as needed."

Re:Every language has its gotchas

[david_thornley]

How about not returning values that are going to go away when the function ends?

While shallow vs. deep copies are important, I'd much rather a beginner never write a C-style array. std::vector is safer and easier to use.

C++14

[Anonymous Coward]

Most of C++11/C++14.
  range for-loops, auto, you may not need value semantics so much but at least be familiar with them, lambdas, smart pointers.
You also need to know pointers in general.

"a senior developer will likely get furious"

[gatfirls]

....and water will likely get wet.

Re:"a senior developer will likely get furious"

[delt0r]

QFT. It is a trick statement. When is a senior developer not furious? Oh yea i was one once....

In general or for a specific job?

[davidwr]

For a specific job, the answer is "as much as possible about that specific job."

If you are going to be maintaining existing software, and that software doesn't use templates or certain less-commonly-used parts of the standard libraries, then you don't need to know them for that job. That's not to say you shouldn't recognize a template definition when you see it, just that you don't need to "know" them.

If you are going to be writing new software and your team-mates aren't well-versed in templates and there's no compelling need to use them in future work, you probably don't need to know how to use them.

Sometimes you can get an idea of what is needed based on the job, the company/division/department, and the company/division/department's recent projects, but not always.

As for the general question:

If you are a recent college grad or competing with them, find out what's been taught in major CS programs the last 5 years and make sure you know what other recent grads are expected to know then make sure you know all of that and then some. "All of that" so you can pass the initial interview and "then some" so you can stand out. If you can tailor the "then some" to match the job you are interested in, then you already have a leg up on the competition.

If you are looking for non-entry-level positions, make sure you understand the basic requirements of the jobs you are interested in and make sure you have the skills needed so that you would "hire yourself" if pitted against average and above-average applicants. Make sure you've got all the technical and non-technical basics and make sure you have something that makes you "stand out from the crowd." Yes, a small percentage of your fellow applicants will also have something that makes them "stand out from the crowd" but at least you'll make the initial cut and probably the final cut. If you aren't hired, lather-rinse-repeat for the next job which you are interested in.

For C++, there is no standard answer

[swillden]

For C++ there is no standard answer, because every C++ shop uses a different subset of the language. There are probably a few things that all of them have in common, but it's unreasonable to expect that any entry level C++ programmer can be productive without support from senior programmers while they learn the local ropes. Even experienced C++ programmers will need a little time to get up to speed on the local style guidelines.

C++ doesn't have an extensive set of standard libraries, either, which means that every shop has its own set. So senior programmers have to expect that new people are going to spend a lot of time getting up to speed on those.

Finally, I think the question is fundamentally bad, because it implies a misguided expectation of immediate productivity. That's a common expectation (hope?) throughout much of the industry, but unless you're hiring contractors for six-month jobs, its stupid. What matters in the longer run isn't what your new hires know coming in the door, it's how well they learn, and think. Because whatever they know coming in is invariably inadequate in both short and long term. One of the things I found very refreshing when I joined Google is that they don't much care what you know in terms of languages, libraries and tool sets. It's assumed that capable people will learn what they need to when they need to learn it, and that any new project involves some ramp-up time before people are productive. On the other hand, given a little time to get up to speed capable people will become very productive. Much more so than the less capable person who happened to know the right set of things when hired.

Re:For C++, there is no standard answer

[Anonymous Coward]

hey, i'm capable, but i've barely touched c++ (or any programming langauge). hire me?

so, between now and when start (tomorrow), i should "brush up" on __________, __________, and __________, so that i don't drive my mentor (you) completely crazy!

p.s. my captcha is "untried".

Re:For C++, there is no standard answer

[swillden]

Without any programming experience it's not likely you'd get hired. While specific language doesn't matter, you have to have sufficient knowledge and ability to be able to have a detailed discussion about solving problems in software design and implementation, and prove that you can write clean, accurate code, and do it quickly.

My recommendation is that you first spend some time working through many of the problems provided by Project Euler, or the Top Coder challenges, or similar. Or maybe one of the coding interview books, like this one.

When you're comfortable that you can take on a not-completely-trivial software problem, design an algorithm to solve it, accurately characterize the big O time and space complexity of your solution (not prove it... though you should be able to prove it, given more time), explain why there aren't any more efficient solutions, code it up on a whiteboard, and explain how you'd go about testing it, all in the course of a 45-minute interview, then you're probably ready.

My opinion

[Java Pimp]

I would say everything you listed with the exception of the standard library. (Read on before flaming)

You don't need to have full knowledge of the standard library but you should have an understanding of containers and iterators. You don't need to memorize all the APIs but have access to the documentation AKA Google to be able to look up what you are unfamiliar with and to understand the full capabilities of what you are using.

There are other things in the standard library that are useful to know like algorithms and such though in my experience I don't encounter them as frequently.

It is a rich library so I wouldn't expect an entry level programmer to have a full working knowledge of everything in it.

The other things you mentioned, yes you better know your shit.

Code reviews

[JustNiz]

Your best bet is to find out if the place you intend to work for does regular peer reviews of code as a part of their process, and if not either stay clear or get an agreement that they will code review your stuff at least for a few months until you know the ropes.
Code reviews of your efforts, if done properly, are the best way I know of becoming effective quickly.

You cannot generalize this

[Opportunist]

The question "How much C++ do you have to know for an entry level job" can be answered. The question "how much X do you..." not.

How much you have to know for an $X level job depends on the job. The more people can do X, the higher the level will have to be. Chances are that you need to know a LOT more C++ for an entry level C++ developer job than you need to know about some obscure assembler or industry machine language for an entry level job in that area, simply because there will be far fewer people with the relevant skill set and hence far fewer applicants.

Supply and demand, people.

Re:You cannot generalize this

[Anonymous Coward]

Yep.

A couple of years ago we advertised for a new developer with experience in any multivalue system and the HR department couldn't understand when we were happy to receive over 10 CVs. If there's less available people then you're going to lower your expectations.

Betteridge Says

[Anonymous Coward]

No.

(It had to be done.)

As a hiring manager

[Anonymous Coward]

As a C++ hiring manager I like you to have a relevant degree; know C++-98 pitfalls to the level of Meyers, "Exceptional C++", "More Exceptional C++"; be aware of or know the Gang of Four Patterns. Familiarity with Sutter and Alexandrescu's writings are nice. Knowledge of Lakos and physical design (rate) is a big bonus. In a big project, even with good programmers, they usually make a mess out of the physical design. Some understanding of unit test and coverage is good too.

Re:As a hiring manager

[Anonymous Coward]

As another C++ hiring manager, I like the cut of your jib.

You hit most of the high points.

The thing about C++, is that it is a deceptively dangerous programming language.

You can learn to code in C++ fairly quickly, but it can take years to learn to write decent programs.

C++ gives you lots of rope.

If you hire someone new, it's your responsibility, as a manager, to ensure they get good training.

Re:As a hiring manager

[janoc]

And I do hope that you offer a senior developer wages as well for these sort of requirements. The OP was talking entry level job.

People requiring these sort of skills for an entry level job are the true reason for the perceived "lack of IT talent" - unreasonable expectations and entry level pay.

Re:As a hiring manager

[Anonymous Coward]

Outstanding. I came here knowing that Slashdot folks would want senior-level characteristics for an ENTRY LEVEL JOB and knew I wouldn't be disappointed.

Some of you literally cannot refrain from waving your dicks around, to the point where you make yourselves look like punchlines. Never change. I love you all.

Re:As a hiring manager

[Anonymous Coward]

YGBSM

That's not senior at all. That's basic stuff. Not a word there about experience. Talked about well-known industry-standard publications that anyone that is actually interested in C++ would immediately recognize.

You're talking C++ here, not "nerf-world" Java. You can do serious, serious damage with badly-written C++. That's one of the reasons it's so controversial.

I'm happy that you like playing with fuzzy toys in nice, safe cribs, but if you want to use power tools, you need to learn some basic safety measures and read the instructions.

Again, AS HIRING MANAGERS. Doesn't that mean ANYTHING? We're the ones that need to put our butts on the line, and stand up for our employees. We need to make sure that the projects get done on time, on budget, and to spec.

This is not something that they teach you in school. It's something that you learn the hard way, by being pushed out of the nest, and into a snake pit.

Since so much of the "commentary" on this site seems to be from folks that live in fantasy worlds where everything gets solved in 100 lines of Java, I really can only shake my head in stunned, stupefied wonder.

Yeah, you really are a comedy show. You got that right, Laddie.

Sheesh.

Re:As a hiring manager

[Anonymous Coward]

Ahh - a "buzzword"/"rockstars only" manager. The latter is a sign of ineptitude. RockStar programmers behave just like ill-behaved rockstars. Children, with minimal common sense, colossal egos. They make a huge mess, and then run off, leaving more practical folk to clean up the mess and take the blame for being "not smart enough to understand the code".

More productively, It is useful to have read meyers. The rest are not necessary. I've seen factory methods used because they are 'object oriented' but then the consumer code has all sorts of nasty dynamic_cast or reinterpret_cast bits. Which can have horrible performance consequences.

And, if you have the opportunity to hire someone who has with intent and forethought, written their own string class, show them the door immediately.
Because unless they are a long time contributor to boost:: or the stl::, they don't know what they are doing, but have the ego to think they do.

The truth is that you have to know C++ to the level of the corpus of code you are working on. If it compiles cleanly with clang++, then it is pretty clean code, and likely not full of correctness pitfalls. I'm not sure about how MCVS++ behaves with respect to C++11.

Re: As a hiring manager

[Anonymous Coward]

What an idiot. Yeah you know we had complex object oriented programs long before the GoF came along and started putting post it notes on everything. You used to just design object structures based on solving the problem in the best way rather than regurgitating whatever latest object structure is the next structure to rule them all. In fact most 'new' stuff in CS is just old stuff with a fancy name. It gets tiring after a while watching acronym bots try to shoe horn the new idea they've just discovered into every situation because it makes them sound brainy.

I suspect you are just one of those hiring managers that forms part of the dysfunctional recruiter-HR death nexus.

Re:As a hiring manager

[Anonymous Coward]

Given there's no such binary as MCVS++, probably extremely fucking badly.

On the other hand, and being a lot less irritatingly pedantic, I work with it every day and for VS2013 MSVC has pretty much full support for C++11, and some (though not exceptional) support for C++11/14. We do have a proper make_unique and variadic templates and range-based for, which is better than the situation under VS2010 and 2012 which mocked out variadic templates through template overloading, and the ridiculous memory consumption limited you to either 4 or 9 or 12 arguments or whatever. We had a horrible class with 20 constructors that mocked out a variadic constructor. One of the happiest moments of my recent career has been trashing that piece of junk...

Re:As a hiring manager

[Anonymous Coward]

Well since Meyers never wrote "Exceptional C++" [1] you are going to be looking for a long long time.

[1] Meyers wrote the Effectgive C++ series, herb Sutter wrote the Exceptional C++ series.

Re:As a hiring manager

[MichaelMacDonald]

Entry level C++ developer is kind of like an entry level bull fighter.

Re:As a hiring manager

[Walter White]

Perhaps you meant Meyer's "Effective C++". Or is it Sutter's "Exceptional C++?"

I hope you are not the hiring manager who throws around buzz words to see if they dazzle the prospective hire.

It's been over a decade since I read them but I still remember the title and author.

Re:As a hiring manager

[Anonymous Coward]

The Lakos book is one of the best C++ books I've read. It goes beyond syntax and design patterns, covering real-world ways to structure a large C++ project. Sadly. I think the book is dated and I haven't seen an update published.

Re:As a hiring manager

[Anonymous Coward]

And I do hope that you offer a senior developer wages as well for these sort of requirements. The OP was talking entry level job.

People requiring these sort of skills for an entry level job are the true reason for the perceived "lack of IT talent" - unreasonable expectations and entry level pay.

But of course! $10/hr should be appropriate for these skills in this economy.

Re:As a hiring manager

[Anonymous Coward]

EXACTLY.

I've been looking to switch from my part time (around 10 hours/week) programming, most time (the other 35ish) other stuff job to a full time programming position for months now. Almost every job that I see advertised on job boards as a junior or entry level position states requirements as having multiple years of experience with a specific language (if not multiple languages) and framework(s) in addition to a degree.

The jobs advertised are usually junior/entry level only in the sense of the amount of money the company is prepare to pay. Not in the sense that they are actually prepared to hire a candidate with junior/entry level experience.

Re:As a hiring manager

[david_thornley]

I'm going to suggest the Meyers books for the entry-level person. Sutter's books are good, but demand more expertise to appreciate.

Re:As a hiring manager

[Brulath]

So you hire them for their predicted future ability, train them to acquire that ability, then let them loose on the bull (or production code). The analogy sort of makes sense, when you think about it too much.

Re:As a hiring manager

[Anonymous Coward]

I'm a senior C++ programmer with 20 years of C++ under my belt and I've never read "gang of four" and can't name anything other than "singleton". I wouldn't want to work in a place where you manage hiring, nor would any good C++ programmer I know.

Competent programmers can learn any language

[Anonymous Coward]

I've learned over thirty different programming languages, and programmed extensively in at least ten (Lisp, Pascal, Assembly, C, C++, Algol, Basic, Fortran, Java, JavaScript, and several others). Any manager who looks for expertise in a specific language should be fired. A good computer scientist understands data structures, algorithms, performance, object-oriented design, design patterns, etc., etc., etc. Arguing about which language to use is the sign of an amateur. A real programmer can learn any language in a few days, become competent in a month, and be expert in a few months. THAT is what I look for when interviewing.

Easy answer

[whoami-ky]

More than the other applicants.

Re:Easy answer

[Anonymous Coward]

You don't need to outrun the bear. Just outrun the other guy.

How long are you legs?

[franblets]

Long enough to reach the ground. You can draw the inference from there..

5 years and work with OSX / Windows / Linux

[Anonymous Coward]

5 years and work with OSX / Windows / Linux.

Also for the places that need an H1B OS2 / beos / Amiga workbench

How much?

[Anonymous Coward]

Enough to get the job done. It's kind of a weasel answer, but it really is the only answer. It's less about "what do you know" and more about "how good are you at finding out. If you can get the job done using a mixture of knowledge, using the existing code as reference, and the internet, you know enough.

C++ is so broad as to render this question useless

[EmperorOfCanada]

This would be like how much English do you need to get a job at an English speaking company?

If the domain of the programming is really specific such as financial machine learning, or embedded systems then a tiny handful of fizzbuzz tests would be enough as the core questions would all be about the domain knowledge. But if the job involves pushing C++ right out to its limits where the company has occasionally made contributions to LLVM or GCC then maybe the minimum knowledge would be that of a C++ god.

But the simple reality is that the surface area of C++ and its applications is so large that as long as the programmer had demonstrated that they can deliver in one area of C++ and are capable of learning whatever SDKs or specifics that you use I would not be too torn up to hire a programmer who knew little of the local company's subset of C++ used.

I personally have delivered C++ applications for embedded systems, mobile, and desktop. Yet it would take me very little time to write a (apparently) simple test that I would fail. Then I could point to myself and say, "Ha ha you don't even know these basics, you fool!"

For instance what is the keyword "compl" used for? Answer: it is a replacement for the ~
Why would you want to use compl other than having a broken tilde key? Answer: Because some systems don't have a ~ but do need to compile C++.

Plus if you were to quiz me on after I had been maintaining some other systems in Objective-C/Javascript/Python/PHP/SQL you could probably catch me up on all kinds of little stupid things where I would muddle the languages together. So just asking me the string function for reversing a string, upper/lower case, or other trivial things. I could end up looking like a real boob even though I could point to the hundreds or many thousands of times that I had used that construct/function/keyword in C++.

So, I am a huge fan of talking over some code that was created by the person and then seeing a quick fizzbuzz test or two to make sure they aren't full of crap. After that it would be to talk about projects that are at least similar to the project in question.

That all said; I wouldn't even be terribly offended if someone didn't even have much C++ experience as long as they could show that not only did they have mastery of one of the languages similar to C++ such as Java, javascript, or even even PHP; but that they had a proven ability to have quickly mastered a new language in the past. On this last note I would find it odd that an aspiring hard core programmer hadn't solidly encountered C or C++ in the past.

You need to know...

[bobbied]

At least as much as I do and I've been coding in C++ for about 20 years...

Now get off my lawn!

Seriously, Know enough to satisfy the intervener, how much is that? Who knows.... So go for as much as you can...

Why C++?

[Anonymous Coward]

Why restrict the question to one language? Or is there something special that an entry level programmer in it would need to know which doesn't have an equally important concept in any other languages?

Standard Library

[darkain]

Standard Library as in stdlib/stdio or iostream? BECAUSE FUCK IOSTREAM!

First, define what you mean by "C++"

[Miamicanes]

Define what you mean by "C++".

C++ firmware for an Atmel AVR microcontroller?

C++ native Android loadable kernel module?

C++ MFC Windows app?

C++ hardware driver for Windows?

C++ Linux app built for GTK+?

The borderline-useless artificial construct college textbooks pretend is C++ for the sake of having something consistent and coherent to teach students for a few years at a time?

My point is that knowing "C++" (as an abstract, academic construct) barely equips you to do anything commercially useful with it. Probably 60% of what you need to know to do anything useful in C++ is platform-dependent, and another 20-30% is IDE-dependent (at least, in the Windows & Android realms, where trying to do anything independently of Visual Studio or Android Studio is an exercise in masochistic frustration (because both platforms are so tightly-coupled to their respective IDEs).

Re:First, define what you mean by "C++"

[OrangeTide]

C++ native Android loadable kernel module?

I'm an Android BSP developer, and I don't know what the hell you're talking about.

Re:First, define what you mean by "C++"

[MichaelMacDonald]

LOL, it's always been classified as a mid level language. I came from an assembler background, so this is something that just went without saying for me. But with all these coders coming from high level scripting language backgrounds, it has to be useful to point this out. C/C++ are designed to be able to allow the programmer to get closer to the hardware level while still maintaining it's status as a programming language, as opposed to assembler. Because of this it's more portable. But, it was always a mid level trade off.

Re:First, define what you mean by "C++"

[Miamicanes]

That's probably because you've never done anything that's unsupported and unblessed by the chipset vendor.

Use case: rooted American Android phone. Gimped Broadcom radio driver that has FM reception disabled at carrier request, even though the hardware capability is present. Alternate .ko ripped from the European or International model's ROM dump and hacked to support American frequencies. Copy the .ko file to the phone, remount system as read/write, insmod.

Use case #2: rooted Sony Android phone. Camera crippled because Sony put the drivers for the advanced low-light and image-enhancement features in ARM TrustZone & throws away the encryption key if you unlock the bootloader via the Sony-blessed method. Acquire leaked files documenting what the code that was hidden away does, and build your own kernel module for the camera that implements everything in normal kernelspace (instead of TrustZone). Post to XDA, then go to bed happy, knowing that you're doing your part to fight The Man and bring Power to the People. ;-)

Re:First, define what you mean by "C++"

[OrangeTide]

I don't agree that you can build .ko's with g++

And yes, I'm a chip vendor. Anything I do is automatically blessed by myself.

Re:First, define what you mean by "C++"

[delt0r]

you know i just can't get use to using anything but asm for my AVRs....

Re:First, define what you mean by "C++"

[Miamicanes]

I personally threw in the towel on C++ for AVRs when I found out that the only way to create instances of an object was an abomination like:

DesiredObjectType* ptrObjectType = (DesiredObjectType*) malloc(sizeof(DesiredObjectType));

or something to that effect. I don't remember whether it was just a temporary work-around to a bug in the current version of GCC, or something more fundamental... but it totally turned me off. I went back to assembly. It was easier, and made more sense.

Senior programmers

[Anonymous Coward]

Gotta love allowing programmers into an interview that are easily annoyed. At one interview a programmer announced proudly that he was the only programmer in our dept. To that, four us looked at him and said "so are we".

There is going to be ramp up time regardless and yes, having a solid background in target language helps placate the annoyed programmer on the hiring committee. As a programmer, I become annoyed because the team wants to pick someone with no experience over someone with a decade because the team lead is younger than the applicant and is concerned about managing the "old guy".

Also must add, that I've walked into interviews with a lot of IT experience but little in the target position, language, etc and walked out with an offer. Again ramp up time but overall ability to reason through a problem and come up with a solution to a desired problem is more important. An interview should be structured to bring out these abilities. Not point out some deep obscure class function that 99% of programmers don't use. That is what Google is for, so don't waste my time.

Wait till the shop in question takes on a project requiring a new function, say LDAP access, and no one on the team has the skill. Is the shop going to hire someone with LDAP experience or assign to one of the existing programmers to learn? More ramp up time and part of the job of being a programmer.

Re:My reply: next resume

[Anonymous Coward]

And a solid programmer will still know how to pick those up in a few months. More to the point, a person who has already achieved that state of being able to learn new languages trivially already knows C++, in all likelihood.

I sure do, and I agree with the GP. The important things aren't the details of languages of libraries, but if you even know what a solution should look like and how to get to it.

understanding of OO, not just the syntax of C++

[schleprock63]

when i interview for developers (we are a C++ shop, mostly), i certainly expect people to understand the syntax of the language, but more importantly to me, to understand what the language is providing. what is OO, what does OO provide over functional... in addition what is class hierarchy? what does it provide to the developer? what are templates? when are templates useful, and when should templates not be used, for example they should not be used to provide hierarchy (which i have seen done). what is overloading (other than syntactic sugar!), these questions can be answered for any OO type language. another huge concept that most interviewees do NOT understand is exceptions. even the basic "throw and get out of the way" concept is lost on them. and they truly don't understand that exceptions decouple normal program flow from error recovery. i'll have them write a method that generates an error and they'll start by returning an error code!! that will pretty much end the interview at that point. another area is order of construction of objects that contain members that also have constructors, as well as order of destruction of objects and what happens when a base class's destructor is not virtual. and lastly, how do they hold up when trying to design an algorithm for a difficult problem. i don't even expect the interviewee to complete the algorithm, what i'm looking for is how they attack the problem, do they ask me questions to help themselves out, do they use the whiteboard to get an understanding of the problem... the individuals in our group do not work in a bubble and if you're not willing to ask for help when you're stuck, then i have no use for you...

Re:understanding of OO, not just the syntax of C++

[david_thornley]

If you're writing code that has complicated order-of-construction or order-of-destruction order dependencies, rewrite it. Same with base classes with non-virtual destructors. There's no point in laying traps for yourself.

The Correct Answer

[Anonymous Coward]

If Bjarne Stroustrup doesn't come to you for advice, you aren't qualified for an entry level C++ position.

How else can we prove that there are not enough qualified applicants and need more H1-Bs?

"The Fundamentals"

[gabebear]

I think categorizing this by language is too broad. It needs to be per-platform. (e.g. writing servlets for 10 years doesn't qualify you to write Android code).

To be hired to develop on a platform you should know the fundamentals, which mainly means intimately knowing the major patterns for the platform (e.g. delegation, factory, prototype, facade, etc).

C+

[Melbourne Pete]

Should be enough for an entry level job,

Don't learn C++

[Murdoch5]

C++ seems great on the surface but it's a mess underneath. No language should ever be designed with the "Do everything" mentality in mind. Learn some languages that are more targeted to areas you're interested in and run with those. Personally I recommend PHP / Ruby for the Web. C for anything embedded / ASM when need. Gtk, QT, C# and X for graphics, JS, HTML,CSS for front end web and then pick up some solid mathematical languages in between. If you set yourself up with about 12 languages, you'll always have a tool to pull out, and each one of those tools will be better then C++;

Re:Don't learn C++

[Mirar]

X is a mess of a protocol though. Too many extensions error.

Re:Don't learn C++

[Murdoch5]

It's a messy protocol, but it will give you a great tool for low level graphics on Unix / Linux systems, something I've been able to pull out several times and save the day.

Re:Don't learn C++

[Anonymous Coward]

Qt? That's C++. oops!

And please don't list all the bindings for python or ruby or other half-assed attempts at having power of C++ in some managed space. All you end up is a giant mess, like all those bindings show.

Re:Don't learn C++

[Anonymous Coward]

That's stupid. PHP, Ruby, and JavaScript are completely orthogonal to C++. HTML, CSS, Qt, Gtk, and X aren't programming languages. C and Matlab/Octave/IDL/Whatever aren't replacements for C++ on a resume. C#... I hate to say it, but it's probably the best suggestion you've made, though you've shoehorned it into one small use case.

Re:Don't learn C++

[Murdoch5]

Got to love when people with no programming experience and no programming ability comment.

Simple Answer

[Doitroygsbre]

Enough to get past HR

I've landed more than one job with a generous helping of confidence and BS

Encounter

[SuperKendall]

Don't think he was a duck. From the fact that he was about to give us a list of real languages but then failed to do so, I can only assume the last "ducks" was him exclaiming at being overwhelmed by a wave of ducks, that subsequently ate him.

Yes, I am quite sure the real problem is he was a victim of.... fowl play.

Re:Encounter

[plover]

Is that duck-typing or duck-stereotyping? /ducks.

Re: Encounter

[Anonymous Coward]

Doesn't matter if s/he was a duck. If he walks like a duck, and talks like a duck . . .

Re:Encounter

[Anonymous Coward]

Must have been that undefined behavior.

slashdot and languages

[Mirar]

Now slashdot is doing it again.

If you understand programming, you can pick up most of that within a few weeks. If a senior dev gets mad at you during those weeks, look for another job.

If you don't understand programming and know all that stuff, there's no way you will learn the libraries and software that specific company uses within a few weeks and a senior developer will get furious.

C++ is just another language. It's in no way harder than C, interlisp or Python.
Standard libraries are just some libraries. All languages have those.

Re:slashdot and languages

[OrangeTide]

C++ is just another language. It's in no way harder than C, interlisp or Python.
Standard libraries are just some libraries. All languages have those.

Easy for you to say, but tough for you to prove or defend.

Re:slashdot and languages

[angel'o'sphere]

C++ is harder than other languages.

E.g. "a constructor for a class is auto generated by the compiler when needed"

Under what circumstances does this rule apply?

Oh, and what are the pitfalls?

E.g.

class B {
int i;
float f;
}

class D : public B {
int s;
public:
      D() {
          s = 5;
      }
}

B b;
D d;

What value has b.i?
What value has d.i?

Hint: consider B and D to be in different compilation units.

My bet: your answer is wrong.

Wow: that above was a super simple example about problems in C++ that make C++ a very hard language

Re:slashdot and languages

[Tanuki64]

Who cares what b.i and d.i are? They are private and in your example inaccessible anyways. If you ignore that than b.i and d.i are both 0. Thats the default initialisation for build-in types when no user defined constructor is available...as in your example. Furthermore class B has no virtual destructor -> You don't inherit from it. It is irrelevant whether B and D are in different compile units or not.

"a constructor for a class is auto generated by the compiler when needed"

What constructor? I know four.

Re:slashdot and languages

[Tanuki64]

Little correction... the i are not initialized at all... This happens only if i is static.... thought this changed with C++11.

Re:slashdot and languages

[Anonymous Coward]

Is the answer 0?
Since they both get declared in the static data section and i is never initialized?

Re:slashdot and languages

[Anonymous Coward]

It is not that hard, don't use single letter variable/class names. Keep your variables straight and your documentation current.

Re:slashdot and languages

[cfalcon]

Holy shit, are you for real?

The answer is, if you use an uninitialized variable, the results are undefined.

This isn't a C++ problem. You got some addresses, never stuck some data in them, and are asking about them. If the language didn't let you do that, it would have some serious issues. In practice, you will generally find that this RAM is zeroed.

Your complaint is "I want a language that doesn't let me create uninitialized variables". But that's a shitty language, and it means that declaring a variable will implicitly instruct actions on the part of the code at run time. Fuck that.

Re:slashdot and languages

[angel'o'sphere]

The answer is, if you use an uninitialized variable, the results are undefined.

Your answer is wrong.

I suggest to read a book about C++ and the mess about constructors.

If you ask politely I explain you what is going to happen depending on where you use either B or D ;D

Re:slashdot and languages

[angel'o'sphere]

All points you made are wrong :D

So, you had failed a simple job interview about C++ based on wrong answers regarding constructors, wow ... and you still think the language is easy, when you are not even aware that the member variables are not initialized at all when there is no constructor?

I did not define a virtual destructor as it is irrelevant for this example.

Good, now you know the member variables of B are not initialized at all, dare to try a new answer ... considering that I already pointed out "there might be a difference depending on compilation units" ???

My bet: your answer will be wrong again ... but no problem. C++ is such an easy language you pick this particular problem up quite quickly :D

Re:slashdot and languages

[Tanuki64]

You did see, that I corrected my answer? Yes, I answered a bit too quickly. But for me the whole problem is irrelevant. From my earliest contacts with computer languages, it was BASIC in the early 80th, I have been taught: You initialize your variables. And this is exactly what I am doing. I have yet to see a problem where the few cycles for a possibly unneeded initialization make a difference. So this initialization problem is nothing I have constantly in my mind, And constructors wrong? You neither defined any of the four possible constructors, nor the destructor... and this means you get the defaults. And this has nothing to do with 'when needed', only with 'did I provide one myself, so the others are compiler generated or not?'.

And initialization of non-static member variables depend on compilation unit? Again, IMHO irrelevant, but please, show me the paragraf in the C++ standard. Please do, I am really interested. AFAIK only static or global variable build-in types get a default initialization. And I don't care for globals. Not only that I don't use them, I have not even seen them used in other ppls code in years.
I still have the nagging feeling, that somehow you mean the 'static initialization order fiasco', which can also happen with globals, and where the translation unit matters... only that this has nothing to do with the code you posted.

But yes, there can be initialization problems in C++, which are relevant and which really can be important.. and I admit, I also don't have constantly in my mind, because it is a rare problem: When deeper hierarchies of multi inheritance (virtual and not virtual) are used. But so what? I know the problem and if needed I look into the specs for a fresh up.

Do you really want to tell me that no other language has less used features, or pitfalls, which are simply irrelevant when good coding styles are used?

Re:slashdot and languages

[cfalcon]

So, I'll give you this: There's a lot of bullshit that can go on that I wasn't aware of, so this has been educational.

However, my answer doesn't change.

Class B will end up with a trivial constructor. The built in types "int" and "float" will be mapped without initialization.

Class D will first call the constructor for Class B, which will do the same thing (nothing). Then its named constructor will run, which has no effect on the inherited member variables.

I *think* you are trying to show a case where D leaves them uninitialized and B gives them the value initializer, but I'm not sure.

And while this has cost me like an hour and a half I meant to be typing bullshit to buddies about shooting down video game spaceships with purple lasers instead of this, it's been interesting.

Still- the case is rather contrived. In practice, if you want behavior like a struct, where stuff gets no values so you don't waste your time memsetting, C++ gives you that with a struct that looks like C, and in the case where you want to have useful values ready to go, an initializer list or set of assigns gives you that.

But holy SHIT the internet has a lot of words on this, and they've changed betwixt versions. As a programmer, the only safe thing is mostly what I see done: use the exact C notation when you want that, and initialize everything carefully when you are trying to create an object sensibly. Mostly, you would want to do this because if you DID make your class all tuned to work exactly right, the precise behavior has changed from 98 to 03 to 11, so it definitely shouldn't be relied on.

So while I disagree with your precise point, and I still claim that C++ constructors are, in practice, not confusing (because people don't normally leave anything uninitialized unless they are very deliberate about that), I wholeheartedly agree with your overall point that this is a wildly complex topic that is not only preposterous to grasp in full, but subject to change by committee at any time.

Re:slashdot and languages

[angel'o'sphere]

You neither defined any of the four possible constructors, nor the destructor... and this means you get the defaults. And this has nothing to do with 'when needed', only with 'did I provide one myself, so the others are compiler generated or not?

You are mistaken. If I don't define a ctor, the class has no ctor, hence its members are never initialized. They get the values the memory has at the point where they get allocated. For statically allocated variables that might be a zero initialized area. That means if I new B() somewhere it gets what ever data is on the heap or if I do B b; in a function, the object holds what ever random data is on the stack.
Because: it has no ctor!!

However as D is inheriting from B and has a ctor the compiler is auto generating the "missing ctor" of B, because D::D() {} wants to call that ctor B::B(). That auto generated ctor for B is usually only accessed where ever D is used. But I already had cases where (IMHO a bug) where the construction process of B suddenly changed (I mean declaring a variable like this: B b;) just because D was "known" or instantiated.

In other words: objects of type B are instantiated differently depending on the fact if they are a part of a D object or if they are solitair.

I suggest you read the C++ definition about when ctors are "generated when needed".

Of course I fully agree with you that variables should be initialized :D But it is easy to forget a field in a ctor, no idea if modern compilers give warnings about that (and to lazy to try that now on my Mac).

Do you really want to tell me that no other language has less used features, or pitfalls, which are simply irrelevant when good coding styles are used?
I did not say that. But people claimed C++ would be an easy to learn language, and I like to point out: the contrary is true.

Re:slashdot and languages

[Tanuki64]

You should read this:

http://en.cppreference.com/w/c...

If no user-defined constructors of any kind are provided for a class type (struct, class, or union), the compiler will always declare a default constructor as an inline public member of its class.

So your Because: it has no ctor!! is definitely wrong. There are no structs, classes, or unions without a constructor. Never. Right is that i in B is not initialized because:

If the implicitly-declared default constructor is not deleted or trivial, it is defined (that is, a function body is generated and compiled) by the compiler, and it has exactly the same effect as a user-defined constructor with empty body and empty initializer list. That is, it calls the default constructors of the bases and of the non-static members of this class.

i is non-static, but a POD type -> no constructor, no default initialization. D has a constructor, which initializes s and calls the implicitly-declared default constructor in B, but this still does nothing for i, since B's default constructor is trivial:

Trivial default constructor

The default constructor for class T is trivial (i.e. performs no action) if all of the following is true:

• 
       
• The constructor is not user-provided (i.e., is implicitly-defined or defaulted)

•      

• T has no virtual member functions

•    

• T has no virtual base classes

•    

  T has no non-static members with brace-or-equal initializers. (since C++11)

         

• Every direct base of T has a trivial default constructor

•      

• Every non-static member of class type has a trivial default constructor

A trivial default constructor is a constructor that performs no action. Objects with trivial default constructors can be created by using reinterpret_cast on any suitably aligned storage, e.g. on memory allocated with std::malloc. All data types compatible with the C language (POD types) are trivially default-constructible.

i is in B as uninitalized as it is in D. No difference.

Debugging

[Anonymous Coward]

You need to know how to debug C++. By default it doesn't give you handy stack traces like most other popular languages, but instead just a single word: "segfault".

Overloading Operator Hell

[Anonymous Coward]

Yeah, that's readable code!

How much C++? All of it, if possible

[OrangeTide]

Unless you've mastered C++, all you will accomplish is writing lots of difficult bugs. Really only gurus should be working on C++ projects. If I can't find enough gurus, then I would pick a different language for the project. (I worked on C projects most of my career because I'm not a C++ guru)

Re:How much C++? All of it, if possible

[delt0r]

That is really stupid. You must be from HR.

Re:How much C++? All of it, if possible

[OrangeTide]

No, kernel developer.

42

[PPH]

What were the units again?

All of it!

[Anonymous Coward]

C++ is relatively compact, when you consider that 'C# 4.0 in a nutshell' is over 1000 pages without any pictures and covers almost nothing of .NET. OK, you may skip the standard template library and Boost.

That still makes C++ 2014 one of the most hideously difficult languages to learn.

Read Yossef Kreinin's C++ FQA and its rebuttals

[Kergan]

You'll get a lot of insights on C++ after doing do.

- http://yosefk.com/c++fqa/

- http://stackoverflow.com/quest...

- https://gist.github.com/klmr/5...

- http://c2.com/cgi/wiki?CppBash...

C++ is not C

[Anonymous Coward]

C++ is a superset of C, so you have to know C and things like macros and pointers (free/malloc/new/delete) and now also C++ with references and templates and exceptions. Would you actually want to throw exceptions in your code?? And not to forget that the 'auto' keyword now has a new meaning. And you still have goto and setjmp/longjmp. Real nice, a language that allows you to write a small program whose compilation never terminates.

All of it.

[aralin]

The answer is the same as the answer to a question: "How much of the driver's handbook do you need to know for entry level driver job?" ... All of it.

Wait, there ARE entry level jobs somewhere?

[Anonymous Coward]

Everyone knows you need 3 to 5 years experience for the "entry level" job, including a master's degree, along with no less than four software patents.....

Oh, and none of that matters if you have an H1B visa, all you need is a pulse.

Re:Wait, there ARE entry level jobs somewhere?

[Anonymous Coward]

Oh, and none of that matters if you have an H1B visa, all you need is a pulse.

An H1-B visa guarantees a higher knowledge/wage ratio, which is what companies are looking for when hiring headcount.

Re:Wait, there ARE entry level jobs somewhere?

[Anonymous Coward]

>An H1-B visa guarantees a higher knowledge/wage ratio, which is what companies are looking for when hiring headcount.

How about we separate the company owners heads from their bodies?

We outnumber them. That is our only advantage.
Better use it.

Basic understanding would be nice

[Endlisnis]

As part of my day job, I interview both junior and senior designers for jobs in C++. I get excited when people know about references. You might be amazed at how often someone applies for a SENIOR position and can't answer this question: Can you explain what a [C++] reference is, when you should use them, and describe their memory/time complexity. For a entry level position, if you SAY that you know C++, you better be able to answer that question. If you SAY that you are an expert, you better be able to explain virtual inheritance, vtables, templates, partial template specilization, etc...

If you say that you don't know C++, but you know SOME language which you can discuss in a meaningful manner, that's fine too.

Regardless of the job you are applying for, I expect you to be a quick thinker and demonstrate good problem solving skills. Beyond that, if you are applying for a senior position, you better know SOME language very well.

And anyone who says that C#, Java, Python or some other toy language is "better" must never have written software where performance actually mattered. If you are writing GUIs for a phone, then use whatever language gets the job done best, but when you are writing software that has to get massive amounts of work done, on limited resources, and needs uptimes that are measured in years, then you use a language with less run-time overhead and more predictable results.

Entry Level?

[in10se]

Based on most job postings I've read, I'd recommend about 10+ years of experience for an entry level position.

A knowledge of cache behaviour

[abucior]

As a game developer, I use a lot of C++, and performance is important. That's really a big part of the draw of C++ for game development. So when interviewing new grads I often ask them a bit about cache behaviour. Most really don't have a clue, but those who do show an understanding get high marks because it shows they've dug a little deeper than the rest:
Questions like:
- "Tell me what cache memory is and why it's important."
- "Let's say I have a list of objects with various bits of data like position, color, velocity, etc.. I can organize the list as an array of structures or a structure of arrays. Why might I choose one over the other and?" The best answer: "It depends on your usage patterns." and then they explain why.
Not understanding cache behaviour is the first step to making even the prettiest code run slowly.

Re:A knowledge of cache behaviour

[MichaelMacDonald]

Nice :D. It's more than that, but that's a clear and clean method using terms most programmers understand. If they can think their way through that one a bit, they have a chance :D.

Able to code with Qt

[LostMyBeaver]

Honestly, an entry level C++ developer should be able to write a useful and clean application with C++ and Qt.

An entry level programmer is someone who should know how to code but generally lacks experience with large scale projects. I'd be less focussed on whether they can define the word polymorphism but instead know the difference between delete and delete []

An entry level programmer should be focussed on gaining experience with developing professionally. A senior level developer should be able to plan from experience to develop a large scale application with complex logic.

I would make it a requirement that they know data structures and design patterns and scrum.

Job Requirements

[Anonymous Coward]

You need as much experience as the job requires..

Required understanding

[rl117]

I was, by coincidence, on an interview panel for a developer position earlier this week. We were looking for someone with Java and C++ skills, but didn't fail them for specific gaps in their knowledge--general attitude, aptitude and competence were what we were really evaluating. Once they are on the team you can easily fill the gaps in with training, books, code review and team working. It's better to have someone competent you can work well with, but you need to be sure they are competent and capable of picking up new things effectively.

That said, if I was in a position to be specifically hiring a C++ developer I'd not really consider you if you didn't have a good grasp of the basic language and common idioms. That includes correct use of RAII and exceptions, and the understanding of when to pass by value, [const] reference or with shared_ptr or unique_ptr. These are essential to writing decent, robust code today. Under what circumstances would you consider it safe to use new and delete? If you haven't heard of smartpointers, I'd be very worried--have you been living under a rock? Likewise I'd also like to see that you are aware of C++11 and 14, and know a bit about them even if you haven't used them much yet--it shows you care about keeping up to date with the language and libraries. For my current work projects, we use C++11 library features where we can remain compatible with C++98 using Boost to provide missing types; i.e. we have an eye to selectively use features where we can remain backward compatible and move up to language features proper once our minimum compiler versions get bumped over time. I've been playing with writing examples to test each C++11/14 feature as GCC/clang has enabled them, to keep up to date and evaluate what would be useful for our projects; keeping up to date with this stuff is a fairly basic requirement if you want to do this professionally, IMO, and if you're not enthused by the language enough to care about doing this, why would we want to employ you? In the same vein, I'd expect you to know about Boost or an equivalent such as poco even if you've not used it in anger.

It's not realistic to expect someone to be experienced with all your pet library features, or even language features--their previous employers may have banned using RTTI, exceptions, etc. in their coding standards. But it's not unreasonable to expect that you have an understanding of them and could use them if you needed to. Specific recall of library features isn't something I would require--I do have a copy of Josuttis for the STL and a collection of Meyer's books on my desk at all times since I can't remember a lot of it off the top of my head, so it would be unreasonable to expect it of another. But I would expect that you could explain the principles behind them e.g. containers, iterators, half-open ranges, algorithms etc.

On rare occasions, I'm amazed that some developers are still living in the '90s and are completely unaware of the last 20 years of language and library improvements. 'C++, I use "version 6.0"'. Sob. RAII, exception safety, RTTI, what are they?! These people would be actively hazardous to your code!

Re:Required understanding

[Yosho]

Is all of that for an entry-level job, though? Most college CompSci degrees that I've seen don't even touch things like smart pointers, newer language standards, or boost. I've seen several fresh college graduates who have never used exceptions because one of their professors told them that exceptions are evil and you should never use them, and I've even seen a few who thought that Notepad was an acceptable IDE because their lab computers still had Visual Studio 6 installed on them, and they were at least smart enough to realize that VS6 was terrible, but didn't know there were other options available.

To be fair, pure CS isn't really about programming, but "entry-level" is still a very low bar.

Re:Required understanding

[rl117]

That's a good question, and I'm not sure I have seen enough different employers to know what's typical here. I don't think we've specifically advertised a position as "entry level" or more advanced; that may be because we do expect some level of expertise, but that could have come from open source participation/contributions, and if the specific job criteria were met then you'd likely make the shortlist.

I may have inflated expectations. I taught myself C++ while also being a full time undergraduate molecular biologist, and then joined ACCU and became familiar with RAII, smartpointers etc. from following their mailing lists, monthly publications and comp.lang.c++, while in my first programming job after graduating. I was also busy being a Debian developer by this point as well, and made use of C++ writing tools for that which greatly expanded my understanding and appreciation of modern C++ programming techniques outside what's in the books. I guess what I'm trying to say is that anyone who is sufficiently motivated and enthralled by programming can pick this up outside of a formal degree programme without great effort, and I do have an expectation that people can proactively explore and stretch their abilities outside the confines of their course curriculum, particularly at university level. I don't know how reasonable that expectation is for the general case. As a scientist I was strongly encouraged to extensively read around the subject to broaden my knowledge and understanding at a theoretical level and also to spend time in labs e.g. over the summer holidays working on small research projects to expand my practical skills; is this not typical for CompSci also?

On my current team several of the team have CompSci degrees, but several of us have PhDs in completely different areas; one of the most senior people doesn't have any degree. While a CompSci degree is certainly useful to have, it's by no means required if you can demonstrate your competence--being a great computer scientist doesn't necessarily mean you're a great programmer as you say--and in many positions specific knowledge of the domain is just as important. For example, in my current position having expertise with many different forms of microscopy from my PhD is almost as desirable as 16 years of programming experience; and having a diverse mixture of backgrounds and skillsets on the team balances this out so that pure compsci people aren't disadvantaged by lack of domain knowledge, and others who are experts in other areas but weaker on the pure compsci theory can be supported by them, etc.

For all our job applications, it is very encouraging to see applicants who provide examples of what they have done in practice, e.g. links to git repos, github/bitbucket, open source project participation, etc.. For an entry level position where they might have trouble demonstrating experience in previous roles, this is a clear demonstration of what they can do and if they also had the right attitude and aptitude it could have a significant influence when comparing with otherwise similar applicants.

None

[Anonymous Coward]

None whatsoever. In an entry level job there is ample time to pick up C++ along the way.

If want ads are any indication

[Anonymous Coward]

You need to be the world's foremost expert in C++, knowledge at least 10 various tools and libraries, and be willing to work 100+ hour weeks for $20k/yr.

zero

[Anonymous Coward]

Seriously, you need to know absolutely nothing, because otherwise you're liable to ask why something is being done so stupidly and thus damage some incompetent's incredibly fragile ego.

Actually answering your question...

[necro351]

The instinct for experienced people when getting a question like this is to just ignore it and give you some broad generic advice (e.g., "he language shouldn't matter!"), which is not what you want. I will try to actually answer your question.

Fact is these days simple programs are not written in C++. C++ is used in kernel code, storage array code, file and database system code, i.e., things with caches where strict control of resources matter for uncommonly important performance reasons (uncommon because performance is not usually a priority 0 problem for "Apps" but it is for systems). If your friend is going to write C++ code they are going to work on a complex system. So then the amount of C++ they will need to know will be probably most of it because for complex systems the code base is large and mature, worked on by many engineers, and usually strictly controlled (code reviews, regression testing, etc...).

What makes the job entry-level then? Answer: they will not be responsible for making large sweeping changes, but instead will be focusing on fixing specific bugs. It will take a while until they earn enough trust and domain-specific knowledge to fix bigger bugs (bugs involving multiple components) and even more until they can design/architect new features. What that means is your friend in an entry-level C++ job will actually be _reading_ more then they write, a lot more.

So your friend will be working on a mature, complex system, fixing bugs with limited scope, and reading lots and lots of code written by other engineers. In the context of reading code the minor features will matter less (e.g,. type parameterization via templates, or various constructor syntaxes, or throwing/catching exceptions). What will matter? What does he need to know to read C++ code and fix small bugs?

1) Being able to identify layers of abstraction and modularization so your friend can tell what a particular piece of code is trying to do and how it fits into the larger system. In this case the major C++ things to understand would be how classes and their data members are declared (often in separate .h and .cpp files), and how class hierarchies are declared (e.g., abstract classes, inheritance, overriding virtual functions, etc...).

2) Being able to understand common memory bugs. The fact is 30+% of bugs in C++ are because it doesn't have strict reference tracking and GC like, e.g., Java, has. Your friend needs to know pointers, pointer arithmetic, referencing, dereferencing, call-by-value, call-by-reference, references, arrays, malloc, free, constructors, and destructors cold. Also your friend needs to know how to use a debugger (e..g, gdb) and something like valgrind that can help find where memory bugs originate from.

3) Soft-skills. Your friend needs to be able to talk to other engineers to ask them how a problematic part of the system was supposed to work, what was the intent? They also need to propose their solutions, and explain what they think the bug is. Particularly for large and complex systems this is really important as you do _not_ want to introduce breaking changes and with more complex systems it is often difficult to regression test just the bit that your friend changes to fix the bug, so you need to import others' experience and get more eyes on your changes when necessary.

Bottom line your friend will be fixing small bugs (often memory related), reading a lot of code, and learning about the particular system they are working on as an entry-level C++ coder. Good luck!

how much C++ ?

[Anonymous Coward]

None. C++ causes brain damage.

Re:how much C++ ?

[Anonymous Coward]

...seems to have affected you

more than the next best applicant

[Anonymous Coward]

I guess they don't teach critical thinking in school?

Jesus H. Christ

[Anonymous Coward]

This is what passes for content on Slashdot these days?

Huh?

[MichaelMacDonald]

Huh. It's not about knowing templates or overloading operators, or virtual this or that. It's about knowing when those things are necessary, and how they should be used. Know your way around pointers and memory management, and know how to avoid memory leaks and corrupting the whole system with them. Know the difference between a memory leak and every other kind of bug that can show up in code. It, really, is a specific thing and it doesn't just describe everything. This is why coding in C++ is looked at as hard, I think. it's not about knowing this and doing that. There's no formula. You actually have to be able to think and react accordingly. Seeing people overuse templates when they're unnecessary is worse than people who under use them, for example. I've seen coders rewrite C++ so it will read like Pascal, because that's what they're used to. I want to rip their guts out and kick them back to whatever hell they came from.

None

[Ben Hutchings]

If it's an entry level job I think it's unreasonable to expect applicants to have experience with a large, complicated and - these days - quite specialised language. It's not as if they teach it at most universities any more.

None

[Anonymous Coward]

If you are a programmer the language you use is unimportant. Whatever it is you will know it well in a few months.

Memory Management

[Anonymous Coward]

Know how to code without causing memory/resource leaks.

Know how to find them if they creep in.

yes. Also, know that you don't know

[Anonymous Coward]

That's great, for especially for more experienced developers.

For entry-level, the first thing to know is that you don't know. The summary says that senior developers will be annoyed by having to teach the entry-level people. Sometimes that is annoying. What's much more annoying is having to teach someone who thinks they know it all. You took a Python class. Great. That means you're qualified to understand what I'm telling you. In 20 years of full-time programming I've learned a few things that weren't covered in your class, which was 48 clock hours. When I warned you that doing X would take down production systems, I didn't learn that from a book.

Re:Answer : as little as practical

[rwa2]

Well, you really weren't that far off the mark.

I went to an Ivy League engineering school about 2 decades ago. They did just about all of their classes in anything *but* C++ . Intro to intermediate courses were in Java, because it pretty much worked as documented. Higher level courses were in scheme, lisp, or whatever. Low-level assembly language classes were done in your own virtual machine that you had built in the java courses. Engineering programming classes were in C (for low-level I/O), Labview, and Matlab. There was *one* small 2-credit elective on C++ that taught the vagaries of C++ for the students who wanted official exposure to that stuff. That was enough to land them at Microsoft or Apple or Google or whatever big shop they wanted to run off to or start their own thing.

My wife and most of my friends went to State University. Intro-intermediate CS were total weed-out classes, and taught in C++ . They spent all of their homework time fighting the tool, debugging stack and buffer overflows, adjusting ulimits, tracing pointers... anything but actually learning about data structures or algorithms. The smarter students figured out how to use the debugging tools and source control to get by, which weren't covered in the curriculum. The State U. didn't exactly produce CS grads so much as CS survivors. Which I guess is an important quality for employers too.

Silly question

[Anonymous Coward]

You need to know enough to convince an employer to hire you! If there is a specific company you are interested in working for then you can ask them which qualifications they require. Then study to the job requirements.

Every nail...

[Anonymous Coward]

Can be hammered in by Perl. *argg more ducks* //someone had to say it

You don't unless you are Indian.

[Anonymous Coward]

If you are a white american with a degree only unpaid internships are available to you.

Not completely useless in practice.

[nobby]

While it wasn't C++, I have used multiple inheritence as a mixin mechanism to implement a common protocol (e.g. propogating events) across classes that have ownership relationships but no other inheritance. The non-contrived examples I've seen for multiple inheritance all tend to be this sort of thing. Multiple inheritance isn't completely useless. You would probably find it useful for implementing default behaviours in environments where there are multiple sources of program control coming from a framework that an object has to play nicely with. One example might be a widget library for a GUI toolkit.

Re: Answer : as little as practical

[Anonymous Coward]

Did you expect the curriculum quality at State U to match that at Ivy League U? Or are you intentionally conflating the language used with quality factors elsewhere in the environment?

How much of language?

[ememisya]

How much English should you know for an entry-level translator job? Hmmmm... all of it.?

Re:How much of language?

[Anonymous Coward]

English has no less than 200,000 words. Do YOU know them all??

Re:How much of language?

[Psychotria]

Do you know the rest of them?

http://www.languagemonitor.com...

Re:How much of language?

[Anonymous Coward]

Many of those are foreign words adopted into English, so no, I probably don't know them.

Meanwhile, you can work on the meaning of the phrase "no less."

All of it

[TheBilgeRat]

I landed an entry level C++ job out of college (where we lived in Java land). Read Design Patterns. Read Essential C++. Read More Essential C++. Know the stdlib. Learn the gotchas. Just be prepared to keep at it.

Technology builds on technology.

[UrbanMonk]

C will still be relevant as the trend is always towards miniaturization of systems - in our case the industry of embedded systems. Yes, I do believe manufacturers want 'tighter code', 'tighter integration', less overhead, 'closer to the metal' software. However, I can't imagine writing hundreds of device drivers in ASM, that would be nerve racking. Likewise, I can't imagine writing scale-able, modifiable, multithreaded, mind-blowing User Interfaces for Operating System / Game Engine XYZ without modern OOP found in C++. I feel C is sandwiched between these two aspects of technology. The reason you only see half the size of other programming communities is because the spectrum that C dominates is more mature. "You have the roots, the trunk, the branches and the leaves. I want my fruit."