Slashdot Mirror
Knowing C++ Beyond a Beginner Level
Nerval's Lobster writes: C++ is not an easy language to master, but many people are able to work in it just fine without being a 'guru' or anything along those lines. That being said, what separates C++ beginners from those with 'intermediate' skills, or even masters? According to this Dice article, it comes down to knowledge of several things, including copy constructors, virtual functions, how to handle memory leaks, the intricacies of casting, Lambda functions for C++11, (safe) exception handling and much more. All that being said, is there one particular thing or point that separates learners from masters?
What separates C++ beginners from those with 'intermediate' skills, or even masters?
Knowing when not to use templates, virtualization, [insert favorite c++ function here], etc.
... all the features have a time and place, and its probably not all the time and in every place.
Basically knowing enough about programming and problem solving with a particular language to tell a need from a want. Needing to use some language feature vs wanting to use some language feature. And being mature enough to stick to needs rather than indulge wants.
Or to state things differently
Well, that really tells you all you really need to know.
:eyerolls:
We're all learners. But anyone with more than a passing familiarity with C++ already knows everything in that puff piece of a Dice article.
The main differentiating factor between C++ beginners and masters are SourceForge, Malware and Dice's self-advertising.
Masters know they don't know everything, and only use language features they know they can use without introducing bugs.
any other questions?
I've always considered error handling to be the most important thing when it comes to knowing a language beyond the beginner level. Every language has it's own idiomatic ways from RAII in C++, finally/using in Java to the myriad of ways of handling return codes in C. It is also frequently undertaught in most programming language courses.
It is for this reason I despise seeing C/C++ on CVs. It implies that you don't have a strong foundation in either language as idiomatic code is so different between the two. By all means list them as two separate languages, but be willing to demonstrate sound knowledge of both, not the bastardised, resource leaking hybrid I see so often when the term C/C++ is invoked.
know better than to use C++
You should certainly be familiar with the syntax.
You should almost never see a new, and never a delete in normal code (rare exceptions for guru library writers only). If you do, you're almost certainly making life hard for yourself.
Another thing is programming with concepts. These aren't part of the language yet, but are part of the culture, part of the design of the STL and hopefully will make it into the language. Things having the same "concept" are types where the operation of the semantics are the same.
This is like a field in mathemetics: you have addition, multiplication, subtraction and division (well, really the additive and multiplicative inverses). If you get the proofs right, they'll work on any field. This is why you can muliply with a modular FFT.
For example, ints, floats, std::complex all obey the same concept, that of a number. There are more, such as automatic differentiation types provided by expernal libraries.
Another example is vectors in "metric spaces". A VP-tree is like binary search, but instead of working on an array of numbers, it works on a multidimensonal metric space of vectors. Normal 3D vectors in Euclidian space is a metric space (distances obey the triangle inequality), but interestingly so are bit vectors and hamming distance and even strings and edit distance. The underlying algorithm of a VP tree relies on several semantics. You need to be able to measure distances and update some lower and upper bounds. That is all.
The art of concepts is writing the algorithm using the abstract interface of the concept upon which it operates. This has several nice properties. Firstly, you use nothing more than the concept. If you use an operation which isn't part of the concept, it's almost certainly a bug. Secondly the algorithms are much clearer because they don't mix in the implemtation of one specific instance of a concept (e.g. building edit distance right into your VP tree) with the underlying algorithm. And finally, once you've done that you get genericism for free. Stick a template around the class and you have a working, debugged algorithm which works on everything it could work on.
This is how the STL works. For instance std::sort requires two concepts. The range spanned by the iterators passed to it must work with radom access and you must be able to compare the elements with <. Given that it can sort anything.
A good stage to get to as a C++ programmer is to write code like that, not necessarily even because you need the genericism but it forces you to separate the underlying abstract algorithm from the concrete specific datatype it is operating on this time. Doing so has many benefits.
SJW n. One who posts facts.
Since C++ is the language of choice when you need performance (along with C and - sometimes - assembly), to write good code it's essential to understand what each line of code does to the machine (memory, registers, ...) and if/how instructions can be optimized by the compiler.
This level of awareness is generally not required to be proficient in other languages, but in my experience it's what makes the difference between newbies and pros, at least in the areas where C++ is used for a good reason.
Said that, it can be useful to understand as much as possible of any language and C++ can provide strong foundations in that sense, as this short article points out: http://www.forbes.com/sites/qu....
There is no single one thing to look for, because what you really want is EXPERIENCE with C++ programming and that encompasses a lot of things. But if you want an easy test to see if somebody has got enough experience, get some code sample that produces a lot of different warnings at compilation time and have them explain what the warnings mean and how one should get rid of them.
There are many things you can use to improve your c++ code like std::vector. With that you store data contiguously in memory but you also don't have any manual memory management. No new, no delete, no malloc, no free.
For my high performance work I tend to use std::vector, BLAS and LAPACK and my programs usually have no manual memory management of any kind in them. Valgrind shows no memory leaks and the programs are very easy to read and work with.
If you want to do high performance c++ then learn OpenMP and MPI. If you want to do threading just use OpenMP since that makes it VASTLY easier to get threading correct. Add tasks with OpenMP along with their dependencies and you end up with a nice cross platform and very high performance code base if you have done your job correctly. If you need to scale to multiple nodes then use MPI between nodes.
Computer modeling for biotech drug manufacturing is HARD!
Beginners can code something up, intermediates can analyze it to find resource leaks (memory, locks, ...) and segfaults, and masters can attain sought properties of a program (plain simple maintainability even when unforeseen features must be added, binary compatibilities, max. memory limits, etc)..
lolololololol
lolololololololololololol
Slashdot is dead
How is going from a mediocre language to a crappier language 'moving on'?
The "masters" figured after 10 to 20 years of C++ that being a master is just mental masturbation, so they moved on to .Net and JVM based languages like C# or managed C++ and Java/Scala.
It's ironic how you accuse people of mental masturbation in a sentance that sounds likeso much wankery. I was going to correct you and point out where C++ is the superior alternative to almost everything else. I came to realise that you're not actually interested in learning. You seem more keen on letting the world know about your supposed mental superiority.
It also sound like you're intervierwing for C++ jobs you don't want purely so you can lord it over the interviewers. Get over yourself.
SJW n. One who posts facts.
If he was coding instead of making stuff from wood and metal, he would be using C++.
Why is Snark Required?
Experience writing, debugging and maintaining code.
The bucket list of having to know this and that means nothing when the programmer doesn't know how to apply it. Claiming things like the latest C++11 features (lambdas) as separating beginners from masters is just BS trying to artificially simplify the issue into something quantifiable. HR and managers love that, because it is easy to test.
I write C++ code for over 15 years now and I can't claim that I am conversant with all those new C++11 features, like lambdas or even move semantics. I didn't need or encounter them so far in production code. The first lambda I have found was only very recently in some brand new code that is explicitly written as C++11 - and had to look up what that weird syntax was about. However, I am pretty sure I will be running circles around anyone who has just drilled themselves on the C++11 specs, but never wrote anything serious in it - I have simply seen and written so much code already that I am fluent in the language, even without knowing all the obscure features. It is the same as with learning foreign languages - you can be excellent at grammar but you still won't be able to communicate until you have to speak it for a while ...
> And why the funk am I supposed to know that? Oh, easy: because you otherwise "might" shoot your self into the foot, and blow your whole leg off.
It sounds like you failed a lot of interviews.
The ability to write code that compiles and runs correctly the first time, without memory leaks, pointer errors, and other bugs.
How do you get that? That's easy too: write a few hundred thousand lines of complex code and debug and test it.
I have a friend who is retired and he makes stuff in his shop. Instead of buying hinges, he makes them himself out of raw metal stock. He enjoys the challenge.
If he was coding instead of making stuff from wood and metal, he would be using C++.
Except the STL provides a lot of those widgets off the shelf.
Has little to no experience, learns the first tasks. Every step he takes has to be supervised and controlled.
Knows how to do things, you can give him a list of task, and he will work on them until they are finished. Can supervise an apprentice.
Knows his trade. Knows how to organise task. Is able to split a project into several tasks he can either work on himself or give to a journeyman or even to an apprentice. Knows how to teach an apprentice. Knows how to differentiate between a well finished task and one you have to do over again.
What we have here is the question what you have to know in C++ to be on journeyman level.
More like a master template ;P
First you have to make the mold, then you have to cast the hinge, without setting the workshop on fire...
I recommend this link: http://programmers.stackexchan...
There is someone asking whether 8 lines of slightly clumsy looking code can be replaced with something better. The beginner wouldn't ask that question and wouldn't know an answer. The master would say "your code is just fine", because it is actually straightforward, easy to understand, easy to check for correctness. The first answer on stackexchange adds two arrays, one 20 line function, and a few lines of function calls resulting in code that is hard to understand and verify.
Now where C++ is a bit unfortunate is the fact that once you leave beginner level and think you know it all, you have unlimited potential to create code that nobody can understand.
It is a safe bet for me that I know ten times more about C++ than you do.
I for my part wrote an STL clone around 1993 when the STL was just a lab experiment at HP.
But I guess you will trump me in a few minutes by pointing out that you are a core boost developer.
Perhaps you should read what I wrote: I have roughly 15 years consecutive C++ experience from 1989 till 2005, plus random 3 or 4 years over the last decade.
I doubt you regularly find one here on /. who has significantly more C++ experience.
And yes: I'm tired to learn every year another pitfall of C++, hence I mainly work with "easier" languages where I can focus on the solution domain and have not to struggle with the problem domain.
Bonus point for you: figure to what that 'quote' refers. :D
Especially I don't have to run around and wonder why young programmers make trivial mistakes in C++ ... point is: the mistakes are only trivial for a "master" ... for the noobs the code they write is obviously correct. For the compiler it is correct as well. ... why?
But the code crashes
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
At this stage 'a' isn't in a register. It's a symbol that will probably be replaced by a constant 13 in a later operation, or pushed onto the stack if used as a parameter (assuming stack based calling)
The C++ master knows C, too and never forgets that he is still programming as close to the "bare metal" as with C. The only thing between him and the processor is the compiler, and no virtual machine, bytecode, or CLR runtime. C++ is a tool to write good (readable, reusable, "object oriented") C code.
bickerdyke
know better than to use C++
Ever heard of 'brainfuck'?
Info @ http://www.dmoz.org/Computers/...
Thanks to Nerval's Lobster, after Python, PHP, Java and now C++, now my brain is totally fucked
And oh, there's even an IDE for it
http://4mhz.de/bfdev.html
Yes, in very simple words, maybe you were never a master...
the code crashes because you failed to correctly pass on your superior knowledge
so, you claim you know:
...
int a = 13;
In which register a is residing, supposing we are on an ARM? Or suppose we are in an 68k? Or suppose we are on an x86?
You are just an idiot!
I don't claim i know, I claim that I understand: something that you're clearly neither willing nor capable of doing, as your question and offensive language suggest.
Have a nice day!
Yep. Java is better than C++, and java fucking sucks.
Since C++ is the language of choice when you need performance (along with C and - sometimes - assembly), to write good code it's essential to understand what each line of code does to the machine (memory, registers, ...) and if/how instructions can be optimized by the compiler.
No.
C++ abstracts away too much for that to be useful.
With C that kind of knowledge can be useful.
I write C++ code since more than 10 years and I try to use it to the limits. I never wrote C. I don't always write C++. Today I wrote PHP and JavaScript for example. I wrote quite large pieces of code, and I earn a living out of this. Having those said I would comment as follows:
1. If you are a master in C++ most probably you are just a master. You can write effective code in lots of other languages.
2. The quality of "master" in my mind is not related to a language but to all the languages. You are master coder in fact.
3. C++ is good as an entry point in the world of codding because of it's flexibility. A programmer has access to pretty much all the concepts invented so far in our trade. The migration from C++ to any other language tends to be way easier than the opposite migration.
And, there is a landmark of a master:
4. The code written by a master is easy to understand by any other guy. Including rookies.
Only the constructor, and you can go a lifetime programming in C++ without ever having to know this. The statement is perfectly clear to anyone who sees it. If you think this is hard, it is only because you _want_ it to be hard.
One of the defining feature of a non-beginner programmers is that they don't read Dice articles to find out anything about computer languages.
The most dangerous drug
And lots of it
The HR process will grill you on C++ at a master level and yet somehow their entire production system is some Ruby abomination that has never seen the touch of a person with more than 5 years of experience in programming. They may need performance, but they're unwilling to commit to the changes required to get it. They may need a master C++ programmer, but they'll never use you to the full extent of your capabilities. And that doesn't really matter as long as they're willing to pay you like they are.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Strange. One would expect him to write assembly, or machine code directly. At the very least, plain old C. Using C++ is the workshop equivalent of buying a finished cupboard and removing the hinge to use it for something else.
I agree with rippeltippel; you're being too harsh and would not work well in my team.
At the end of the day it's all bit and bytes and concepts generally not taught in school
but are learned from observing compiler output. Try it sometime -- gcc -S. See if you
can follow a variable in a simple function. It's pretty enlightening. Ever wonder how C++
"knows" where an object lives; that mysterious "this" pointer? That's how you learn...
so, you claim you know:
...
int a = 13;
In which register a is residing, supposing we are on an ARM? Or suppose we are in an 68k? Or suppose we are on an x86?
You are just an idiot!
I know it doesn't matter, which apparently is alot more than you do.
Btw, it might not be in any register, or even anywhere in memory.
-true masters have their own style of writing c++ code. They don't listen to the newest silver bullets, but instead can decide themselves, which techniques to use in each situation. Masters can dodge the pressure of bleeding edge features, and focus on the requirements. They implement the simplest possible code, without any advanced tricks or newest fads, never coding themselves to a corner. They don't listen when the world screams that the code is shitty, when they know better than everyone else. Masters develop their own coding standards and conventions, distinguishing his code from the gray mass that everyone else is doing. Going against the tide is important part of being a master.
C++ abstracts away too much for that to be useful.
Does it? :-)
I agree that C takes you very close to the bare metal. Yet C code is perfectly valid C++ code, and C++ allows you to achieve the same* level of control that you get in C, plus (as you pointed out) many useful abstractions that could hide what happens underneath.
However my point is that using some of those abstractions without understanding them could have nasty effects. Just a few examples:
Of course there are similar abstractions in other languages, but their implementation is often mediated by some framework/VM/etc that takes care of the shit for you to some extent. In C++ there's no garbage collector (although you can write your own) and you have full responsibility of what your code does. You can write your own tools for the job, your custom allocators, your libraries and abstractions, but you are responsible for most of it (new compilers help, thankfully).
To write good C++ you always have to see through the code, or you'll likely end up having sub-optimal stuff (which I concede can be enough in some cases).
* if you think that's not the case, please provide some examples.
C++ is a decent language to choose for many types of projects, and which pieces of the language depends on which type of project that is.
Embedded applications: There are several sets of best practice for embedded or hard real time c++, no exceptions (unbounded latency), no dynamic memory allocation (fragmentation), no dynamic casting (unbounded latency), no recursion and on and on. There actually seems to be a bit of consensus on this best practice, but it varies with the constraint of your particular system and if it needs some safety committee's approval.
Systems programming (OS or driver): I have never read any best practice documents for this, but the code I have read all looks like C with classes. few or no templates show up I've noticed.
Large scale performance critical stuff (games among other things): Widely varying best practice statements and all sorts of different coding, I have no idea.
Scientific (matlab but faster): who cares, you just want the answer, not the software, right? Don't read this stuff, it hurts. but it usually works.
I always look forward to /. c++ posts. I know I'm being clickbaited by Nerval's but its sooo fun!
refactor the law, its bloated, confusing and unmaintainable.
Just asking. :-)
We suffer more in our imagination than in reality. - Seneca
Trucks are better than motorcycles. Motorcycles suck.
That is only true when you need to transport enormous amounts of stuff.
When the goal is to quickly transport a packet through a city, the motorbike will be better.
Horses for courses, etc.
Java is a nice replacement for all use cases of Cobol.
Wow the smug condesention is strong in this one.
I for my part wrote an STL clone around 1993 when the STL was just a lab experiment at HP.
The hard bit about the STL is the whole concept of, well, concepts that Stepanov finally hammered out. The STL, especially 1993 era is not all that complex.
Well, iostreams and their interaction with locales is deeply fiddly and I'd steer clear of that. But the basic algorithms, you know, vector, list, set/ma/multiset/multimap, sort, heap, priority_queue and so on and so forth are not too bad.
Not to say it's not an achievement, but it's not enough to convince me that you're an uber-guru. I've written STL compatible containers, and STL like algorithms for things that weren't in there. Apart from quantity the principle is the same.
Perhaps you should read what I wrote: I have roughly 15 years consecutive C++ experience from 1989 till 2005, plus random 3 or 4 years over the last decade.
15 years experience, or 1 year of experience repeated 15 different times?
Given you've never seen code without new in it (as your other post claimed), I'm inclined to think the latter because you seem to be deeply ignorant of whole swathes of C++ style. In a lot of code, you never see new and delete. Everything is managed by containers. I work on computer vision systems, and you can get entire working, robust systems without a new anywhere in sight. The custom containers might have a new in, but that's---well, let me check the library I'm using---let's see there's 80 instances of new in 40k lines. Of those most are in old code from before TR1 gave us many standardised smart pointers, and others could easily be replaced with a std::vector (the code's not perfect, it's been hacked on for the last 15 years), some are strange, silly uses and the rest are to initialise now deprecated auto_ptr.
There's about one legit one which uses placement new and posix_memalign.
With spare time, I could make that one in 40k lines of code easily. In fact that's going to happen slowly as the library is being transitioned to C++14.
I find it terrifying that someone who pust themselves forward as a super C++ guru is splattering new so much all over the place. But you won't believe me because without knowing anything about me you've convinced yourself that you're superior.
Let's see what a real, certifiable C++ guru says:
http://www.informit.com/articl...
Bjarne doesn't like new/delete either. No offence, but I'll take his invention ans stewardship of the language over your 1 year of experience repeated 15 times.
I doubt you regularly find one here on /. who has significantly more C++ experience.
Out of interest, do you have any T-shirts with disparaging things written about n00bs on them? And are those slogans visible under the cheeto dust?
SJW n. One who posts facts.
It's not 13bout knowing ex13ctly which register 13 is stored in, r13ther underst13nding how the compiler optimizes 13n 13lgorithm...
Ugh, d13mmit R13ndall...
What about the Ant People? They owe us money.
C++ lets you have just as much control over the code as C. The key difference is that it doesn't make you memory manage your objects every time, when 99.99% doing that is irrelevant toward performance and only serves as a common route to introduce bugs.
What about the Ant People? They owe us money.
I shouldn't rise to the bait but, oh well.
There is no single job interview where I don't have to correct the interviewer about false assumptions of how certain stuff works in C++ ...
Any competent professional will be aware that C++ is a language so vast and with so many obscure corners that there will be corners that they would need to check to be sure and may well get wrong in an interview situation. However...
What is called in which order? Constructor? Assignment operator? A potential cast from bla to s? Or, the copy constructor?
And why the funk am I supposed to know that?
The reason this question would probably asked at interview is that there is a candidate who claims to be expert at C++ who is making statements about obscure corners of the language that are probably wrong but an interviewer doesn't want to get into an argument about it. So instead they'll ask something that any reasonably competent C++ programmer would be aware of (because this syntax is a legacy of C and doesn't do what a naive C++ programmer might assume)
It's also interesting that the really smart C++ programmers are usually quite self-effacing. They probably won't comment or will say something like "Oh, I thought it was B but I'm not sure" if they think something the interviewer said is wrong. They certainly won't be aggressive about interviewer mistakes (although any sensible programmer won't take a job where the interviewers are making to many basic mistakes in the language)
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
The software engineering profession has a super-shitty education system. You get quite a bit of important theoretical education on the uni and you get some basic training in designing, writing and debugging software.
BUT - the real education is done "on the job". And you might never "meet a Master" who can tell you about the "dos and donts" in a particular language, or in systems design. It is all essentially Left To Change.
Compare that to the Azubi, Geselle, Meister system where the person is systematically educated by certified professionals. Clearly, computer science and software engineering has a shitty, irrational education system. And don't get me started about the auto-didacts. They fare even worse. Which is a major reason for shitty systems.
"It is all essentially Left To Chance"
Dice, of course, is full of a lot of things, as well as rather pathetic. Just listing a few things
as "the" capabilities to have is rather adolescent and amateurish.
Knowing what is appropriate to use where and when is a better gauge.
Being able to do the same thing with or without any of these declared "IT" things would also count.
Past all of that there's algorithms, recursion, callbacks, event-ordering, and a touch of parallelism....
Just my 2 cents.
Albert Einstein once said: 'Everything should be made as simple as possible, but no simpler'. I think that sums up the most important quality a good developer must have. It is very tempting to try to use every known feature of a programming language, and even in a simple language, the result is not pretty - C++ is far from simple, so you can imagine how ugly it can become.
That said, to master a technology means that you are able to use the difficult features with reasonable ease, when the need arises. That includes all the reviled features in C++, such as templates and meta-programming; there is probably nothing in the language that is simply superfluous, and learning how these features are used is a good idea (and an important part of that is knowing when not to use them).
If your new recruits don't know ALL of the mentioned stuff in this article, then they shouldn't be working on your code base.
I would REQUIRE that any developer employed at my company, even at beginner level, understand basic things like the difference between shallow and deep copies, casting, virtual functions, operator overloading, writing templates, and copy construction. You can not properly write C++ code, without at least a basic understanding of the language and of programming. All of these things are intrinsic to any C++ code base. You can not write proper C++ without understanding all of them.
I sincerely hope that there are not people who consider themselves to be C++ developers, who do not understand this stuff.
These are BASIC C++ skills - not intermediate level.
Intermediate level skills might be template metaprogramming techniques, and advanced macro trickery, or a combination of the two. Intermediate level programmers will also have experience of some of the subtleties of C++. People have written multiple volumes if you don't know what these are.
It is difficult enough to design software well. If your developers don't know how to use the language, as well as having to design programs, your projects are doomed to fail.
I don't understand why people who have clearly never recruited a developer, or managed a software project, post this kind of rubbish.
because you otherwise "might" shoot your self into the foot, and blow your whole leg off.
Not really. If you code your copy constructor, empty constructor and assignment operator with the correct associativity then it doesn't matter what the compiler does in this case. And if you don't do that, there are plenty more ways for a client to fuck you up than that. The exact operation of the compiler for that case is something you don't need to know, and it's not even clearly defined IIRC (could be constructor + assignment, could be copy constructor, but since copy constructor has to be the same as constructor + assignment otherwise you're writing broken code, it doesn't matter except for a tiny bit of performance increase that might be possible if the compiler is pre-SSA.
Just consider that the user can also write
Something s;
s = bla;
and it's all pretty straightforward to realize that you have no control over what happens, so you have to actually code your class correctly for all such cases.
Converting C program into C++ makes you realize how much boilerplate code C++ can remove.
constructors/destructors and replacing code using reallocs often with std::vector.
At the end of the day, know enough C++ so that you can simplify a 500 lines, error-prime C program into an equivalent, simple to understand, 250 lines C++ and you are my C++ hero!
I used to be a big fan of C++ until I realised how this language has so many hairy corners. When you start spending hours figuring out which feature is best to express a certain thing and have to consider all the implications of your choices, this is called mental masturbation. I prefer to focus my mental energy into actually solving problems than figuring out the intricacies of the language. The beast has become way too much complex for my taste! for that reason, I have returned back to C for the most part
Experience.
Why write different articles that say the same thing? Just post the same one about how much X do you need to know Y each week instead of these permutations.
But then I would have to kill you.
Bullshit.. C is incredibly inefficient. Why, I get own down in there and optimize my NOPs, and I funroll loops!
wait.. wait..
Assembler is bullshit.. I get on down in there and optimize that microcode!
sorry.. couldn't resist...
Being able to write readable code. It's a very rare skill.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Get a copy or pdf of Stroustup, 4th Ed. You should become very familiar with the pitfalls and advice Effective C++ by Meyers, and Exceptional C++ by Sutter. Programming the examples in Gamma et al. Design Patterns is useful. Become familiar with Large Scale C++ Software DEsign, by Lakos. Most people still make a mess with physical design. Use a unit test framework like CppUnit or Google for everything you write. Be literate. I see a lot of garbage come from non-native English speakers
A somewhat related question is, what do you do when an interview candidate is scheduled to be there all day, but the first two interviewers report that s/he completely lacks the technical skills needed to do the job? Escorting him or her off the premises early would be rude, on the other hand, you don't want to waste the time of valuable engineers.
One trick I've seen is to replace senior engineers with new hires and interns in the interview chain, just to give them experience. Coach the interviewers to sell the heck out of the company. At the end of the day, the candidate is given an enthusiastic sendoff along with "We'll be in touch with your recruiter."
C++ is a multi paradigm language, which allows to use low-level and high-level features. The art of coding in general is writing readble code, which uses the offered features wisely.
My threshold for non-beginner knowledge of C++ is knowing how many distinct meanings there are for the keyword 'static'.
I can count 4.
Which is in line with my comment: when the programmer uses proper highly-abstracted C++ mechanisms, micro-managing knowledge is not useful.
Congrats, you clearly have the bigger C++ e-penis in this case.
Good points. You convinced me that it actually might be beneficial to know what happens under the hood even with C++, to write professional code.
Congrats, you clearly have the bigger C++ e-penis in this case.
That's probably the most common type of logical phallusy.
SJW n. One who posts facts.
The learner is stuck in an infinite loop to learn C++. the master aborts and retries with D.
This whole thread reeinforces the idea that programming is just a trade.
I certainly don't want to depend on code written by folks who just want to learn the minimum reqiured to get paid.
Progamming should be a craft to which one aspires to be excellent.
Folks who do this should have no trouble both earning a living and having fun.
For the folks who understand this and just want to get bootstrapped:
A good lesson for anybody is
How to make a hard problem simple and not the reverse.
Basic things any programmer should know include:
What is a computer, a program, a tool chain, a source repository, a library, a variable, a function, scope, syntax.
Where do you go to find an example of something and how to get it running in your environment.
For C++, the first skill seems to be knowing how to look up yet another feature in Stroustup.
The second skil seems to be gathering enough experience to have the judgement to know when not to use yet another feature.
For C and C++, not understanding pointers seems the first intermediate failure mode.
Althought C++ constructors give pointers a close race.
I started playing with C++ when I when into college in 1991. At one point I probably would have qualified as more or less a C++ expert. Then, as the language grew more and more insanely complex with each revision, I stopped trying to keep up on the whole language.
Nowadays I'm content to just make sure I understand the subset I normally use, read up when I come across a part I don't use, and ignore the rest. For my own programming, at least, the language has simply become too complex to be worth mastering.
And, once again, Nerval's Lobster gets a piece accepted which is little more than a thinly veiled reason to link to one of the endless stream of lame stories about "how much toilet paper do you really need" articles.
Have you guys become so blatant with the click-whoring to Dice you have designated people who write pithy sounding summaries for repetitive and lame articles to drive to Dice.com?
Because there are suspicious amount of lame "how much do you" articles submitted by this one poster, and all linking back to Dice.com. And never a mention that Dice.com is the parent company and is shamelessly shilling their own crap.
Sorry guys, but you're becoming really obvious with this.
Lost at C:>. Found at C.
Heard this quote years ago: "C lets you shoot yourself in the foot. C++ does also, but when you do it takes your whole leg off."
I'd say the best answer is simply experience. Know where the land mines are and what is required to avoid them--usually by having struck some before.
... have moved away from C++ to a more sane language :)
For instance, declaring a loop variable as "for (uint8_t i = . . .". On an 8051 this might be good, but on a 32-bit CPU the compiler may have to generate extra code to scale it to 32 bits whenever it is used. And it's not saving any RAM, because it probably won't ever live on the stack with even minimum optimization turned on, since 32-bit CPUs tend to have a lot of registers.
A full time job.
The first step beyond beginner level, for any coding language, test your fucking code!
I've seen so many times, beginners who make: just a small/trivial change to somebody else's sloppy code because they think they're smart enough to clean things up, manage break shit for everybody else because they didn't test their change. Then somebody else has to spend hours to fix that bullshit.
If you don't know about copy constructors, when & why to use them, you're not even a beginner.
is there one particular thing or point that separates learners from masters?
I think you mean "what separates those who are still early in their learning from those who have pretty much mastered the topic."
As anyone who has "mastered" any topic of significant depth will tell you, there is always more to learn.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
All that being said, is there one particular thing or point that separates learners from masters? Knowledge of public well known libs, how to overscope and underscope legacy code without touching it keeping it manageable.
If you can debug a generic memory leak or bounds overrun (which might not cause a crash until long after the breach), then you are no longer a beginner.
If you don't understand memory management then you are not yet a C++ programmer, let alone an intermediate one.
In my experience of interviewing, I have spoken to many alleged C++ programmers who can give a textbook definition for the terms 'copy constructor' and 'assignment operator', but who have no idea of their purpose, and their role in resource management. Unfortunately, I do not need to imagine the sort of code they write, because I have seen it.
You are thinking like a manager.
As a programmer, I don't want to be replaced easily, and I don't care about my work when I'll die, or even when I quit my company.
I have no problem to share my knowledge with my co-workers, but why should I write code for somebody who'll replace me ?
Software Engineer Code of Ethics
Your own insecurities related to job security are compromising your ethical values.
When a system you build fails or costs more to maintain than it really should all because you are scared of losing a job, you are not providing the value to your project or society that the profession demands and reflects negatively on everyone here. Don't ever call yourself a professional, don't comment on the matter, and quite frankly, get the hell out.
Much of the modern C++ dialects seem to be a winner. Certainly smart pointers and templates can be good, and are an improvement over the older C++ concepts. C++11/14/17 add features that make writing broken code harder.
Like anything, with much power comes much responsibility.
Lambdas and templates when overused make debugging next to impossible. I was working on some code that was so far nested in a bunch of templates, I couldn't use GDB to make any sense of it. Eventually I tore apart the templates to find a small bug in one of them.
Also the G++ compiler errors don't often point to anything meaningful. Missing a semicolon can result in a paragraph of errors, one may point at the actual error.
Don't get me wrong, I really appreciate C++, but you earn your pay using it.
In either case, once you turn the optimizer to high you don't know what's going on under the hood.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
1) Read all of Scott Meyer's books. Not all of the rules in the old books apply anymore, but a lot still do, and they are not covered in his new books. 2) Go to https://www.youtube.com/result... pick out the videos you like and especially focus on Bjarne Stroustrup, Scott Meye, Herb Sutter, Nico Jousittis. Watch them. Look for other videos ( believe me there are more then you can watch in a lifetime unless you're a C++ superwaonk ) from other conferences. 3) Be familar with the newer concepts: variadic templates, perfect forwarding, move semantics, and concepts (lite). 4) Of course you have to have done some programming touching these things, but Scott Meyer's IIRC has never written programs. Finally, if there is something that needs to be done: for example, writing a specialized template library; and you balk because you do not have the basic knowledge needed to write that, then you are not a master.
Yes writing in C++ ( or even C ) is more expensive, but programmer cost is no longer the biggest factor in cost. Every cycle more needed by a program needs so many more milliwatts. Every cycle more generates so many calories which require so many milliwatts of airconditioning. Add enough and it really costs a lot. If you are writing for Android, it may mean that the Galaxy Tab 3 is not good enough to run your code, which means so many customers lost. Etc. It really has always been this, Moore's law just did a good job of obscuring the fact.
From generic to specific, beginning to end. When you have a clear path the details fill themselves in. When you write, filling in the abstract concepts give flesh to inner methods, and code tends to become closer to self-documenting. This is also a critically important concept.
Someone wrote above that a master can write code a novice can understand. This is truth, because mastery is shown through clarity.
There are other truths; there is no quantitative or binary representation -- no master or novice, good or bad -- only qualitative. Even a novice can write the code of a master, and even be indistinguishable if the novice knows his way.
IMHO the best C++ programmer is the one that stays away from C++. When performance is a concern, C is the obvious tool of choice. If OO and speed of development are important, I'd opt for Java or Python any day over C++.... As a kernel engineer I may be a bit biased, however...
As for me, my path has been from C++ to C.
In particular many in the university environment, including computer science professors and would be phd - entrepreneurs, there is a lot of over-excitement about language features, and C++ provides a stream of new features almost each year. That leads to really bad, unmaintainable software, done with total disregard for good software engineering practice that comes from, well, practice.
I learned the advantages and pain points of the C++ features, and mostly abandoned most of them with time, until what I was left with was pretty close to C,
and that's where I abandoned C++ for good for my use cases.
Your mileage may differ, but knowing when _not_ to use C++ features is the key distinguishing element you are looking for I think.
It's really hard to master the entirety of C++, so you're better off knowing just a meaningful subset of it. Go and pick up Effective C++ and the sequel—they're basically just filled with the pitfalls of C++ to avoid and some decent things worth knowing. That's the stuff that tends to show up on C++ interviews. There's basic stuff in there and less basic stuff, but all of it is useful.
My company has a course on advanced C++ and C++ pitfalls, and even after 15 years, some of them caught me. Lots of them did, really. It was interesting because the room had a dozen or so programmers, and we all fell for completely different things.
C++ gives you a lot of rope to hang yourself with. The trick to using it well is to limit how much rope is around your neck at any given time—never do something cleverly that can be done simply, even if the simple way takes up a few more lines.
Oh, and comment your damn code. I don't care what language you're in, you're not a master of it until you know how to leave a trail of comments that even a new programmer can follow. When you're on your third 18-hour day, you have an imminent deadline and you're starting to go crosseyed, you'll either love or hate yourself based solely on the amount of good comments you left in your code. Things that are obvious when you're awake and well rested become muddy when you're tired and hungry and want to go to bed.
I had to look at the code for dbus. I found some "interesting" things. The first is DBusString and DBusRealString. One is effectively a String class. The other is a wrapper for the first class, that for some reason hides it's content. The second thing is something called something like DBusList, a linked list of generic pointers.
I can't say for sure, but I suspect that I could have replaced large chunks with C++ been slightly more efficoent. Just by a few simple tweaks which were obscured by all the extra verbiage and need to make sure such "localized" libraries were correct.
Hell, as I started to write this, I realized one major inefficiency. In C++ it would have been written using "vectors" contiguous array that are resizable instead of linked lists. This would make a big difference. Advancing the iterator to a linked list involves dereferencing a pointer. Advancing the vector iterator involves incrementing a pointer. A major difference as the majority of the time the link list increment will involve a cache hit.
So it seems a C++ version of dbus would be much faster then the C version.
As for readability. If you insist on readablity for all "programmers" then you wind up with the piece of shit that is the Google C++ coding standard. An intermediate C++ programmer will be able to understand, a highly intelligent beginner would. Someone who indulges in stupidity would not. If you see something like MyClass(MyClass &&my_class_in) and change it without knowing what it does, assuming it is wrong ( nevermind that it does compile ) you will get into trouble.trouble. I have a simple philosophy, I use any tool in C++ to organize the software as well as possible. Everuthing else follows from that.
or manage to proceed without collapsing the workshop, cause your iron ore was located under your workshop, so you started digging at the side...
And that is why I call sticking to C++ "mental masturbation".
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Of those most are in old code from before TR1 gave us many standardised smart pointers, and
And
The custom containers might have a new in, but that's---well, let me check the library I'm using---let's see there's 80 instances of new in 40k lines.
Wow, you want to argue about the amount of "new"s per kLOC? Do you really believe that makes any sense?
At some point you have to instantiate your business objects. Regardless what they are.
The only way around real need for new is to have all memory statically allocated.
So the argument how many news and deletes are around makes not much sense.
Every Smart Pointer is initially initialized via a new.
Given you've never seen code without new in it (as your other post claimed),
I did not claim that. I have plenty of source files that have no new, nevertheless the whole program has a lot of news. Well, actually as I mostly use prototype based factories the news are centralized and they are bottom line few.
convince me that you're an uber-guru You pulled this out. I'm just an ex guru who is stuck with 10 year old C++ standards and thus my knowledge is declining and regarding C++11 outdated ;D
But that is half what I want ... when I do C++ in our days I stick to Qt and occasionally embedded programming. Real business logic should be done in a safer easier to use language, and I'm tired about the "who knows more about C++" pub talks :D
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Erm, perhaps you should learn to read.
The parent claimed a good C++ developer can tell from every line of code, which registers are affected.
Which is clearly nonsense.
However: show me the trick how such a variable may not be "anywhere in memory" ... nice try.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You did claim that.
And there is not much to understand about those lines.
Obviously you have a mental problem, or why do you offend me by calling my language offensive?
Is that a new fractal approach to discussion or simply a misplaced double recursion?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
On a SPARC processor it would most definitely be in a register ... read about register windows and such.
The first 8 local variables in a function are in registers, so are the first 8 parameters to the function.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Real business logic should be done in a safer easier to use language, and I'm tired about the "who knows more about C++" pub talks :D
Didn't stop you from starting one.
That question is actually rarely asked.
It was more an example for the "complexity" of C++ that might occur in a single line of code.
The funniest supposedly difficult question was about the size of byte, char, short, int etc. in Java and char, short, int etc. in C.
I found that question retardedly silly and when I worked for that company in the end I met the interviewer and asked why he asked something so simple.
The answer was: I was the only one out of ~ten interviewed persons who answered this simple question instantly and correct.
When I point out an error of the interviewer (usually it is in his papers and not an error by himself) I'm obviously polite. But I'm also resolute. I take crafting software serious and being certain about facts and avoiding mistakes/defects is very important to me.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
However: show me the trick how such a variable may not be "anywhere in memory" ... nice try.
Easy: if the object 'a' is not used it won't need storage. If the object is only read from the compiler can easily detect this and fold it into a constant. One manifestation of a constant variable in generated machine code is that it is part of instruction encoding. Depending on the architecture this may not take any extra storage or the encoding schema may vary depending on the constant magnitude.
In compiler theory, dead code elimination (also known as DCE, dead code removal, dead code stripping, or dead code strip) is a compiler optimization to remove code which does not affect the program results.
Dead code elimination - Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Dead_code_elimination
These are part of the easy bits, bro. You shouldn't outright dismiss ideas you don't grasp immediately. p.s. I don't like you or your bad attitude
You are moving the goalposts.. your one-liner did nowhere mention that the object was one of the first 8 local variables. I don't see any code accessing the object either by reading and/or writing to it either.
It's not exactly rocket-science to grasp how simple statements could be translated into machine code. Expression trees are very popular mechanism for the translation process. When object is written into, the expression is stored in a tree and the leafs are transformed into instructions. The trick is to do this within a limited budget. SSA is very popular presentation and dynamic programming is usually a good starting point to get things moving forward.
The tree for your statement would look like this:
a - 13
Very simple, no? I don't see object 'a' being a leaf in any other expression, therefore it will be eliminated. As a machine I can exhaustively comprehend that object of type 'int' will not have any side-effects when omitted from code generation; e.g., it does not have any code associated with it that should be executed.
Therefore, I am unable to agree with you that the object would 'definitely be in a register' on a SPARC, or any other architecture for that matter, assuming the compiler is not completely brain-dead idiomatic piece of garbage.
Nice example of the Straw Man logical fallacy; good job!
Of all the people to reply, you're not the one I'd expect. You cant start an e-peen war, get out e-peened, then join in the fun laughing at people with epeen insecurity problems.
C++ is more like "artificial cow insemination". Somebody has to do it!
Debugging
Logging
Profiling
Leak tests
Unit/Integration tests
and most importantly, readability.
read your own code a month after you left it alone, is it readable?
how much time did it take you to figure out what you did last time?
how simple is it to follow the logic?
how simple is it to add new functionality?
and finally, how simple is it to shoot your own foot with what you wrote?
Excuse the lack of quoting, on phone.
First, business what now? There is so much more to C++ than that. I doubt I've encountered one this year. But when I do, they can either be shoved into a container, or instantiated with make share or make unique.
There's no need for new anywhere.
But it seems like you're massively misinterpreting what I say as no news happen under the hood. Certainly they do, but they're all safely hidden away, so lifetime is managed cleanly and safely for you. Not sure how you came to that conclusion, but whatever.
And dude, if you call yourself an ex guru, you're implying that you think you were a guru. It's rather tacky to describe oneself as such, not to mention lacking in credibility. Stroustrup and etc never call themselves gurus.
SJW n. One who posts facts.
BLAS and LAPACK are libraries.
You need to differentiate between the dynamics of a language (ie: FORTRAN vs. C/C++) and the libraries available.
FORTRAN 77 vs. FORTRAN 90/95 and up are completely different species.
So we start talking about eigen systems programming in one language vs. another. Well, when was that library written? In what version of what language? Just because it is a widely available library, does that mean it is any good internally?
Theoretically, if there were a fully C++ written linear algebra (or any other library) that isn't linked with some gawd aweful old FORTRAN code or (asm{ ... }) down in the bowels of the machine, then you could make an honest comparison. But since everyone seems to start off with poor examples from free programming cook books and someones opinion from the web, without seriously (re)designing or understanding the patterns used to accomplish the task, you then get what you get (ie: crap).
After long time programming in FORTRAN 77/90/95/etc. and C, and C++, and many other languages I would have to say that most programming comes down to energy expenditure. If a grad student comes out of school after programming mainly in Matlab the first thing that person is going to suggest for a programming project is going to be Matlab. This same phemomenon is what has kept FORTRAN alive. In the case of FORTRAN , the legacy dependency code of many scientific applications ultimately led to the refactoring of FORTRAN as a language rather than discarding all that code. It amounts to loss aversion and an unwillingness to learn new languages in entrenched users.
Why not create an open scientific co-processor card spec that has hardware advanced functions instead of farting around with GPU discretes that were originally designed for video games. Then we could just have linear algebra calls in the standard math library that are driven by math hardware instead of 50 years of accumulated CPU work-arounds for 8088 code (that was sarcasm).
Progamming always seems be 'VHS instead of BETA' because most programmers doing applied programming for science arrive in industry with only single language skills and programming was only a sideline from whatever thier degree was in.
I also continue run into 'C' programmers who refuse to learn C++ . it's some kind of religion thing. Deities will apparently smite them if they crack a manual.
As a programmer, I don't want to be replaced easily, and I don't care about my work when I'll die, or even when I quit my company.
So you're a selfish asshole. Got it. That advice is meant for people who actually give a fuck about anything other than their own petty selves.
Yes, so? If I was using a SPARC I'd be assuming register based passing.
If it was to be used in a calculation, and the architecture doesn't have operations on constants then I'd know it would go into a register. I wouldn't know which register, but that wasn't the point. The point is knowing it will be stored in a register. In the case of a SPARC, and if we're using it as a function parameter, and if there are fewer than 8 parameters, and if the parameters are all simple types, then it will be stored in one of the upper 8 registers in the window, and a competent programmer with low level SPARC experience will be able to tell you exactly which.
No, you miss the point completely.
The GP claimed a good C programmer can tell from every line of code (C code!) which registers of the processor are affected.
Which clearly wrong. No one knows that. Not even on a SPARC or Power PC where C code to register mapping is pretty straight forward.
And you are now running of into the wild arguing for the arguments sake.
and a competent programmer with low level SPARC experience will be able to tell you exactly which. ... they are simply stuck behind on portable assembler and often have no clue about any higher level architecture or language concept ... regardless what language or architecture.
Wrong! Every programmer who gets an introduction how SPARC register windows work, will grasp that immediately. No special "I'm a super competent programmer" skill is needed. That is exactly my point. People should simply stop to claim that a C programmer is by definition more competent than any "non C programmer".
They are not
Then they come and claim: "look at that! I know in what register that variable goes, you don't!" And how relevant is that exactly for 'what'?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I did not call my self an ex guru, some idiot called me an "uber guru" and I told him, I was perhaps once a guru. Long ago.
It does not matter how you call yourself, the question is what you are :D
I never call myself a master in martial arts, however I am ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I never call myself a master in martial arts, however I am ...
you just did.
SJW n. One who posts facts.
If you think so :D
I don't think that pointing out a fact to another person falls into "calling yourself something" .
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I don't think that pointing out a fact to another person falls into "calling yourself something" .
Ah, so it's a fact that you are/were a C++ guru, eh? So my man, what precisely defines guru that makes such thing a fact? Calling yourself a guru is akin to insisting your nickname is Mr Awesome.
SJW n. One who posts facts.
Er, you seem to lack reading skills.
I did not use the word guru about my C++ skills before someone called me mockingly an "Uber Guru" and I made perfectly clear that I once "perhaps was a Guru" but don't feel like that anymore ... after all I stopped using C++ hard core around 2000 and afterwards only used it it from time to time.
But seems you are obsessed with that word :D
As long as I can still show the youngsters how stuff works I definitely don't feel "underquallified" regarding C++. though.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.