Knowing C++ Beyond a Beginner Level 345
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?
Knowing when not to (Score:5, Insightful)
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
Re: (Score:3)
Basically, only use a language feature if it provides a tangible benefit (making the code easier to understand and maintain almost always qualifies; making the code run faster qualifies if it's not running fast enough yet; "This is cool, let's try using it!" only ever qualifies in your own private projects).
Re:Knowing when not to (Score:5, Insightful)
making the code run faster qualifies if it's not running fast enough yet
And then only if backed up by realistic macrobenchmarks. There are a lot of things in C++ that have interesting performance characteristics (templates allow more inlining, so make microbenchmarks faster but can cause you to run out of i-cache and make the whole program slower, virtual functions prevent inlining unless the compiler can do devirtualisation, but are actually slightly faster to call than cross-library calls via a PLT if they're not inlined). Generally, algorithmic improvements will make a bigger difference than any language feature. The main reason for using templates should be to eliminate copy-and-paste coding, not to improve performance.
Re: (Score:2)
Re:Knowing when not to (Score:5, Insightful)
I agree with your comment entirely. I would only like to add that a true C++ Master writes code that a C++ Novice can understand.
Time to get philosophical. Tomorrow, you could get run over by a bus. Take a wander around your Cubical Town. Are there enough folks there who could take over ownership of your code?
You can do some really cool things with C++. But if other folks cannot understand them, well it's best not to do it. Cool C++ features are like nuclear weapons: very powerful, but think about the consequences of using them . . .
Re:Knowing when not to (Score:5, Insightful)
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 ?
Also, unless you write frameworks, I doubt very much that your code will be reused.
It will probably be rewritten.
Re: Knowing when not to (Score:5, Insightful)
but why should I write code for somebody who'll replace me ?
Because future you will replace present you. If you need to revisit code years later to fix a bug or add a feature, you want to be able to pick it up straight away, rather than try to figure out the mess you left behind.
Re: Knowing when not to (Score:4, Insightful)
I have 30 years of coding experience.
Even though I believe I'm quite a good coder, when I read code from 5 years ago, I'm always surprised to realize that I can do better and simpler.
Whatever the state of your code is today, it will be a mess in a few years.
Re: Knowing when not to (Score:4, Interesting)
Even though I believe I'm quite a good coder, when I read code from 5 years ago, I'm always surprised to realize that I can do better and simpler.
Whatever the state of your code is today, it will be a mess in a few years.
Yes. I find this to be the case too (I was a programmer in the seventies and eighties, and have been in programming management ever since).
So it begs the question "can one write code that one won't think is sub-optimal five years from now?". I've begun to suspect that one can't -- so just learn to accept it and move on.
What I try to get programmers to do is write code that is A) clear and simple and B) balanced in terms of development vs. maintenance time. I don't want programmers wasting time perfecting code that's not going even be looked at for years to come, nor do I want code that takes days to get into when attempting small fixes.
It's like building a house: if you follow the building standards, it's quick, safe, and any plumber or other trade can walk in later and quickly fix or modify things. If you do a bodge job it all has to be torn out and redone properly, or, if you create custom installations, it gets very expensive to create and especially to maintain.
Re: (Score:3)
"Whatever the state of your code is today, it will be a mess in a few years."
Funny, I just said that to a colleague tow hours ago. It's the fate of all software development.
Re: Knowing when not to (Score:5, Funny)
Wow. You're right. It's only been four hours and your comment is already a mess.
Re: (Score:3)
Re:Knowing when not to (Score:5, Interesting)
Re:Knowing when not to (Score:5, Insightful)
If you can't be replaced, then you can't be promoted.
It depends on the kind of promotion.
Not everybody dreams to become a project manager.
Do you really want to be maintaining the same program for the rest of your life?
Not really, but if the pay is good and the job is nice, why not ?
Personally, I have a life outside of my work, so I don't really mind.
And do you want to have a reference that says 'no one can understand this guy's code' when you leave for the next job?
That's the least of my worries !
Do you think that the guy who will take your place won't hate you, even if your code is beautiful ?
Do you believe that your company will not fire you if there are problems ?
If the company doesn't care about me, why should I be faithful ?
Finally, I have a personal question: why do you work ?
Is it to receive aknowledgment, money, fame, self-esteem, or something else ?
Re: Knowing when not to (Score:2)
Re: (Score:3)
If you can't be replaced, then you can't be promoted. Do you really want to be maintaining the same program for the rest of your life? And do you want to have a reference that says 'no one can understand this guy's code' when you leave for the next job?
Or for people who don't care about being promoted above coder level... If you don't write good code that other people can work with, you will never be moved to new projects. If you want to live in maintenance mode that is one thing but personally I want my code to reflect my skills so I can work on bigger and better projects.
Re: (Score:2)
As a programmer, I make sure I remain employable by doing the best job I can do. Partly this is about basic ethics, but I know that even if I write ideal code, with perfect documentation, I'm still the best person to understand that. I don't want to work for any company I work for that doesn't realise this.
Re: (Score:2)
While I agree with your point of view, but I will give you an example where it fails.
Let's suppose that the program you are working on leads to the death of a person.
After analysis, you discover that the bug is due to your carelessness ("it happens").
Your self-esteem of "I'm doing the best job I can do" is shattered.
Will you hide the fact that the bug comes from your incompetence ?
Or will you take responsibility, even though you'll probably be fired ?
Re:Knowing when not to (Score:5, Insightful)
I'm both a programmer and a manager, so I can probably weigh in. I do care about what happens to your work when you leave the company. And part of my job is to make sure that your code is usable.
Because code is an asset that you are being paid to create. And if your code is not maintainable, it's not much of an asset; it's worth far less to me. So, if I notice our code is a fuck storm of uncommented overly complex verbiage, I'm not letting you work on anything important. So, maybe you get to work on small one-offs (really career enhancing), maybe I just fire you. But certainly I don't expect to allow you to keep extending your tentacles..
The reason you say "most of your code will be rewritten" is because it sounds like your code is poor. Why would I pay asset-level prices for stuff with a shelf-life of a year?
Re: (Score:2)
to be fair, the same applies to all languages - I recall the C# yield stuff someone wrote once (probably because it was cool, and even he couldn't understand what he had done sometime later).
And then I think of my colleague who writes the simplest of C# code, but writes it in layers behind layers that its a maze.
Language features do not necessarily make for confusion, like most things, its the way you do it that matters.
Re: (Score:2, Insightful)
These days it's questionable if any large projects that use those kinds of features extensively should even be started in C++. There are better languages for such things.
C has applications in OS, low level and embedded development. C#, Java, Objective-C and many other languages are better for applications. Somewhere in the middle you have C++, which is okay in moderation but wouldn't be your first choice for anything new.
Re:Knowing when not to (Score:5, Insightful)
This is complete and utter tosh.
No one I know who does high performance code (such as numerics, real time computer vision, that sort of thing) uses anything but C++, especially for new projects. There is nothing out there that combines the speed and expressivity of C++, and when you know performance is going to be a factor at some point, C++ is the only choice.
Frankly for a lot of scientific and numerics style coding, I often reach for C++ initially even when performance isn't required since it often maps on to those problem domains better than any other languages I've used.
Oh and then there's the embedded world, where your choices are C and C++. Plenty of people use C++, since it like C scales all the way down to the 8 bitters like Atmel.
Re:Knowing when not to (Score:5, Insightful)
If you need really high performance you don't use most of the C++ features anyway, and end up basically writing straight C.
Nope nope nope nope nope nope nope nope nope.
That is far, far, far away from correct.
Check out something like Eigen or TooN (a somewhat more obscure library which is used in the vision world for things like PTAM). They are very far from C++. The code written down in an editor reads more like maths. There's no explict loops, no explicit memory allocation. They're both high performance libraries used in challenging applications (seriously download and run PTAM, it's amazing).
They're also fully templated so you can stick in an AD type instead of a normal number and get derivatives out automatically with no extra effort.
Writing high performance C++ is nothing like writing high performance C. It's much better. All the messy C details of allocation and etc simply vanish, leaving clean, nice looking code which is straightforward to read, write and debug.
Or another example from today for me. I need to find the best N (lowest cost) elements during some wort of complex search. It's easy. Just create a priority_queue<pair<double, int>> where the double is the cost and the int is the index of the object.
Then about 3 lines of logic keeps the pqueue updated with the best N so far.
All the irrelevant logic of how a queue works is witten and debugged by someone else and hidden from me without ever losing either performance or type safety. For bonus points, if I find I'm searching very small things and memory allocation becomes a penalty, I can switch the entire thing to stack allocation with almost no effort at all!
Re: (Score:2)
You are not 100% correct.
LAPACK and BLAS outperform Eigen for large decompositions. For work like computer vision, you often have huge heaps of small, fixed sized matrices. In such cases, the overhead of function calls and blocking which makes LAPACK fast makes it much, much slower than naive algoithms. I'm not sure where the crossover point is, but it's somewere in the mid to high tens in size.
Anyway, other C++ numerics libraries wrap BLAS and LAPACK for large sized objects.
which part (Score:2)
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 sys
Re:which part (Score:4, Interesting)
Scientific (matlab but faster): who cares, you just want the answer, not the software, right?
Not always true. Sure, there is plenty of well-motivated ad-hoc coding in scientific research. However, we sometimes have supercomputers working for months to generate the answer. Even with well-written software this could mean many core-years of number crunching. Without good high-performing software we would not get the answer at all. Developing good scientific software takes time and effort too, but if the software can be used over and over to efficiently solve >1000 problems (for instance, the GROMACS papers have been cited by users ~15,000 times), then the time invested can be very good use of taxpayer money. C++ is not a bad choice for such software in that it enables very good performance and decent maintainability.
Re: (Score:2)
Quite true, with a caveat. Each feature in every language provides a balance of power to the developer versus a learning curve and potential gotchas. Different programmers will have different balance of opinions on where each feature lies on this spectrum. Each must decide in each case, "is this worth it to me for any potential difficulties I may encounter, and what about any others who work on this in the future?" (each alternative option will also bear such decision-making). There is rarely a single hard,
Re: (Score:2)
I mean, I know a guy, who teaches physics and basic programming in a public school. He thinks he writes great C++ code. He doesn't use templates, virtualization, [insert favorite c++ function here] . He doesn't even use use classes. He just uses a C++ compiler to compile his code. Total coding mastermind, if we look at the things he does not do..
Re: (Score:2)
I commonly formulate it in the opposite. A master of C++ knows when to use the simpler function. For example, is it more sensible to use 2 overloads than a template, when is a free function a better idea than methods or functor, when is a struct (a real struct w/o methods) a better idea than a fully fledged class. The point is that you should not use the most powerful tool for the job, but the weakest that will get the job done.
Novice programmers write code they don't understand, advanced programmers write
Re: (Score:2)
...and a good metric is if the feature simplifies the code you are writing or if it makes it more complex.
The more orderly a system is, the smoother and more functional it will behave with fewer unintended consequences. The easier it will be to maintain, and the less time it will take to understand. Simplicity truly is the essence of all that is good in a computer.
What is easily overlooked is that order requires effort to maintain. At zero effort, complexity is going to increase, and looking at any syst
Re: (Score:2)
Re:Experts... (Score:4, Funny)
Memory objects that clean themselves up after they go out of scope are the devil's work. The devil, I say!
Re: (Score:2)
Memory objects that clean themselves up after they go out of scope are the devil's work. The devil, I say!
Exactly. The devil creates work for idle hands, does he not? And what does not having to do vast amounts of error prone grunt work do if not leave hands idle?
Re:Experts... (Score:5, Insightful)
Re:Experts... (Score:5, Insightful)
I've made the exact same argument to co-workers at many firms... namespaces (e.g. Timer_Init()), virtual functions (tables of function pointers), etc. can be approximated / kludged together... but automatically invoking a function at the right place (destructor and, let's face it, the constructor is pretty handy too) is something that has to be baked into the language, and C++ has it. I work in safety-critical systems, and knowing that I can't leave a function with interrupts disabled, I can't forget to close this socket, etc. is incredibly comforting.
I'll quote Bjarne Stroustrup here:
"Just that closing brace. Here is where all the ‘magic’ happens in C++. Variables get destroyed, memory gets released, locks get freed, files get closed, names from outside the closed scope regain their meaning, etc. This is where C++ most significantly differs from other languages. It is interesting to see how destructors -- an invention (together with constructors) from the first week or so of C++ -- have increased in importance over the years. So many of the modern and most effective C++ techniques critically depend on them"
Re: (Score:3)
Well, it's a compiler extension, but GCC supplies the __cleanup__ attribute which essentially allows arbitrary destructor functions in C.
Mastery of the language is one thing, mastery of the tools another...
We're all learners... (Score:3)
: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.
Re: (Score:2)
The stuff in that article isn't really about C++; it's about knowing how to program when the abstractions of higher level languages are not available. In other words, if you can program masterfully in C and are mediocre in ASM then C++ really shouldn't be a big hurdle. But, I don't think people these days learn the fundamentals first.
Re: (Score:2)
Re: (Score:2)
I assume by something like this:
((my_class *) (0))->somemethod();
As long as somemethod() doesn't try to access any class members, the code may even fail to show any obvious misbehavior.
Error Handling (Score:5, Insightful)
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.
Re:Error Handling (Score:4, Interesting)
I may hate seeing it written that way also but that is also the current most common way to write it and that is what HR systems and their computer screening systems except. You are writing a resume for an HR person usually and if you want it t be seen by someone more important it has to get past them first. That means doing stuff that HR people understand.
There are many fights to take on in this world and others that are just not worth the effort to fight since the costs are so high compared to the benefits and this is one of those fights.
Given how C++ is taught. (Score:3)
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.
Re: (Score:2)
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.
That is complete nonsense.
At some point you have to allocate the objects/memory. And for that you need a "new".
Re: (Score:2)
see, for example, std::make_shared. http://en.cppreference.com/w/c... [cppreference.com]
Re: (Score:2)
That can't be right!
The guy you are replying to is the resident C++ ultraguru on slasdot. There is no one regularly here who knows more than him:
http://slashdot.org/comments.p... [slashdot.org]
So I don't see how it's possible that such a simple thing could possibly be right!
Re: (Score:2)
Re: (Score:3)
I think you missed an important concept here: std::make_unique can never, ever ever leak. It returns a std::unique_ptr<T> which will free the allocation and/or transfer ownership to another unique_ptr instance (or to a shared_ptr). At no point can it lose track of the memory it is managing for you.
Forget about "focussing on things have an equivalent delete/free". Understand that unique_ptr does this for you. So does shared_ptr. Their whole point is to manage allocations for their whole lifetime.
Re: (Score:2)
Not with smart pointers. Those will automatically call delete for you.
Re: (Score:2)
I don't like the sound of that.
Why not?
Re: (Score:3)
Smart pointers live where ever you declare them.
Either heap or stack or even with limited usability in static allocated memory.
Re: (Score:2)
A smart pointer has the same basic interface as a pointer, namely it supports * and ->, but not necessarily arithmetic. They're not supposed to be smarter than you, they're smarter than dumb pointers, because you can put logic into the various parts.
But yes, the standard ones essentially do lifetime management for allocated stuff, for when your object lifetime doesn't match the stack. They're pretty good things :)
Re: (Score:3)
Well, rather than "not liking the sound of it", I would highly recommend you educate yourself about them. There's plenty of examples floating around. I've been using std::shared_ptr for well over a decade, first as boost::shared_ptr, later std::tr1::shared_ptr and today std::shared_ptr (they are all the same, just going to the final standard name with C++11). The number of memory leaks I've had in my released software over that period: zero, checked regularly with valgrind.
Smart pointers aren't magic. T
Re: (Score:2)
Re: (Score:2)
> In a multi-threaded environment where objects may be shared, or not
Isnt it bad sign, if you're forced to use unreliable multi-threaded abstractions... Good luck finding all race conditions...
Re:Given how C++ is taught. (Score:5, Insightful)
Since when does Java's performance even come close to C++'s in benchmarks? C++ performance is generally very close to that of C's, and in some cases exceeds it (example: qsort vs. std::sort - C++'s use of templating allows for inlining of the sort function code)
Smart pointers have very, very little overhead. The worst is std::shared_ptr, and it's still only adding a reference counter, and that's only used on pointer copy and deletion. And if you have a use case that requires std::shared pointer as your smart pointer of choice, then this is counting that you'd have to be doing anyway in some form or another.
From the benchmarks I've seen, most people see about an additional 5%-ish overhead in debug mode with std::shared_ptr vs. raw pointers in pointer-heavy code. In a release build there's generally no measurable effect (the difference being, in debug mode it can't inline the dereferences).
Re:Given how C++ is taught. (Score:4, Insightful)
"Smart pointers" are great -- if you don't care about performance (in which case, why are you not using Java?). If the object is owned by one thread, it's just sloppy to put in the overhead of smart pointers to make your life easy.
If an object has a single unique owner, then std::unique_ptr has no run-time overhead and will ensure that the object is correctly deleted even in the presence of exceptions. I agree with the grandparent: any object that isn't allocated on the stack should be created with std::make_shared or std::make_unique.
Re: (Score:2)
Succinctly put and to the point. And people who can't or don't understand this have no business using C++.
Re: (Score:2)
It's not about knowing, it's about understanding (Score:5, Insightful)
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... [forbes.com].
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
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!
Re: (Score:2)
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.
Re:It's not 13bout knowing, it's 13bout underst13n (Score:2)
It's not 13bout knowing ex13ctly which register 13 is stored in, r13ther underst13nding how the compiler optimizes 13n 13lgorithm...
Ugh, d13mmit R13ndall...
Warnings (Score:4, Insightful)
Re: (Score:2)
And if the person fixes all 231 warnings by adding the single missing semicolon he is guru material!
In this case there would be more than just warnings - the code would not compile at all.
I would suggest the stl (Score:4, Interesting)
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.
Re: I would suggest the stl (Score:2)
If you want real high performance c++, don't use hacks to turn your single threaded code to MT. Use cuda and opencl2. (Both of which support a lot of c++ functionality)
If you don't want to cross over to using external drivers, use std::futures.
For real efficiency control other threads yourself!
Re: (Score:2)
CUDA and opencl are great for certain types of problems. If you don't have a problem that works well on GPUs then they are pretty horrible.
For the kinds of HPC work I have been doing I get a nearly linear speedup up to 128 cpus with appropriate use of openmp.
OpenMP is a standard and supported by all modern compilers. It works extremely well and gets rid of all the boilerplate code you would normally need with threads and gives extremely good scaling on high performance systems.
Re: (Score:2)
Agreed that CUDA and OpenCL are great secondary and tertiary ways of heterogeneous multi-core programming.
Not sure what your beef again OpenMP is. OpenMP makes it trivial to add multi-threading to your app.
When did C++ get thread control again? Oh yeah, it wasn't until C++11 [cppreference.com] and you STILL had to wait for compilers to implement it. In the mean-time OpenMP was already here, and working for years. Considering OpenMP has been around for 18 years, calling it a hack when C++ ignored the whole standardization
What separates learners from masters? (Score:2)
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 l
easy (Score:2)
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.
There once was a clear distinction. (Score:2)
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
Non-master (Score:4, Insightful)
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.
Re: (Score:2)
Looks like a master did answer it; discusses a Factorial Number System, provided code, and even ended it with:
TL:DR; You're code is already "clean" and correct.
The C++ master (Score:2)
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.
Masters don't play with Dice (Score:5, Insightful)
Oddly (Score:2)
Who else stopped reading at "this dice article"? (Score:5, Insightful)
Just asking. :-)
Simplicity (Score:2)
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
The same thing as every other language (Score:2)
I stopped trying to know all of C++ (Score:2)
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
Here we go again ... (Score:3)
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.
oh good lord (Score:2)
If you don't know about copy constructors, when & why to use them, you're not even a beginner.
Re:Masters know their limitations. (Score:4, Insightful)
I thought I was a guru level C++ programmer (I have been programming C++ for around 2 decades) but even I am constantly finding out about new things I didn't know existed.
Re:Masters know their limitations. (Score:5, Informative)
This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.
* /Oblg. Comedy: Hitler on C++ [youtube.com]
When you have even committee members admit they only use a sub-set [youtu.be] then you know the language is too big.
The C++ committee recognizes there are many problems with C++ iostreams [youtu.be] but nothing is being done towards performance and type safety.
The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.
* http://www.stroustrup.com/mult... [stroustrup.com]
Crap like long long [open-std.org], "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.
Modules have been in a constant state of on-again-off-again for over 10 years:
* First mention N2073 [open-std.org] (Sept.2006)
* Revived N4047 [open-std.org] (May 2014)
* 2nd draft N4214 [open-std.org] (Oct. 2014)
* 3rd draft N4465 [open-std.org] (April 2015)
* Wording N4466 [open-std.org] (April 2015)
The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:
There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 [open-std.org] in Visual Studio 2015!
The C++ committee failed to learn the first lesson about design:
* "Needlessly complexity is a symptom of bad design."
Or paraphrased from Einstein:
* "Things should be as simple as possible, but no simpler"
Re:Masters know their limitations. (Score:4, Informative)
This 100%. C++ has become a clusterfuck of over-engineering
Nope. It's mostly hampered by the need to be backwards compatible. The committee know full well if they make serious breaking changes, then the C++ world will split into two distinct languages. Many, many people won't adopt the new one and the vendors will continue to support them because there's money there.
It's a blessing and a curse. The curse it it's hard to do anything but add features. The blessing is my code I debugged 13 years ago still works.
The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.
You're basically being an arse. You're picking out one rather speculative paper designed to help C++ stay modern a ways in the future (and somehow labelling this as a bad thing) and yet knowingly ignoring the many papers on fixing core issues.
Modules have been in a constant state of on-again-off-again for over 10 years:
Yeah they should just slap in some module crap and if it's wrong, just rip it out and replace it. Who cares about getting things right and not breaking working code, eh? They learned their lesson very hard with export templates and are keen to not have to learn the same lesson again.
There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!
So you submitted a proposal, right? Or do you expect other people working for free to magically know your personal problems from your whining on slashdot?
Re: (Score:2)
Well, for starters '@' isn't a valid character in a token. Are you sure you worked on a compiler?
Re: (Score:2)
And that in a nutshell is what's wrong with C++. It has bloated and bloated over the years, never deprecated anything of note and now its this behemoth that few compilers implement in its entirety and few programmers now how to use including all the gotchas, weird semantics and vast complexity.
Much like the English language, which is also quite useful and therefore widely used. Being useful over a wide variety of scenarios and being bloated-and-complex are often two sides of the same coin.
Re: (Score:2)
No... That is more like the arrogant closed minded jerk.
A master will strive to learn more about such features and when they suffencly understand them they will implement when approproprate.
I myself have been out of practice in C++ for about 15 years. I recently began working on a project where I needed better systems control and huger performance. So I choose to use C++. I know most of the concepts however I needed to research how to to do some things over again.
My experience made it easy for me to searc
Re: (Score:2)
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 abou
Re:Simple ... (Score:4, Interesting)
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... [informit.com]
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?
Re:Simple ... (Score:4, Funny)
Congrats, you clearly have the bigger C++ e-penis in this case.
That's probably the most common type of logical phallusy.
Re: (Score:2)
If he was coding instead of making stuff from wood and metal, he would be using C++.
Re: (Score:2)
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.
Re: (Score:3)
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?
Re: (Score:2)
Mod parent up +1 insightful. Well said!
As someone else [slashdot.org] pointed out in the thread Report: Aging Java Components To Blame For Massively Buggy Open-Source Software [slashdot.org] from just a few days ago (June 16):
* "A good programmer knows when to use external libraries. A great programmer knows when not to."
To summarize: Great programmers know how to manage code complexity. Poor ones don't.