stl map of vectors

[monarch_dodra]

If you have problems exiting from them you probably shouldn't be a programmer.

I think people who can't recognize they are fallible are the ones that shouldn't be programmers.

[OReubens]

It really depends. Just make sure your loops are not too convoluted. *Personally*, I hate having variables such as "done" or "found". It bloats the code with later tests. I think a good break, return or (sometimes) even goto can be more expressive, as it reduces the amount of later conditional tests. But to each their own. The real goal is to break down your code into simple blocks until there simply is no complexity left.

Don't let anyone (including me) tell you that something is "bad" or "good" without backing and explaining why, and make sure you build your own opinion.

That said, when in Rome, do as the Romans, and if you have a style guide that says "don't use breaks", then by all means, don't use break.

using break to exit a loop and return right away is a clean design approach. If the style guide objects to it, maybe you should ask your team WHY it's a bad thing.
Dragging conditionals into your loop makes the code more complex, adds more cases to test for, and ultimatey and most importantly makes your runtime bigger and slower because it needs to do the extra tests each loop.

in case of nested loops, breaking out out of that is probably the ONLY good reason I have for using goto. Just be sure to slap a comment on it just for good measure. Again, if your styule guide prohibits is, it maybe a good idea to change the style guide to make this exception, while "goto is nasty", the alternative is even more nasty, adding extra tests to each layer in the nested loops. So the performance impact could be even worse.


Also: be careful with trying to break or goto out of a algorithm with a predicate (lambda).. Things may not work entirely as you planned them to.

[tiliavirga]

in my ( personal ) experience, descriptive and truth-telling names are far more important than anything else. Moreover, I'd have serious problems working with a programmer that finds std algorithms "unfamiliar" ...

the problem with #1 is that range based for loops ( however terse ) mean "traverse something" whereas I want that code to tell me "find something", the difference is huge IMO ... especially when you review/change your code months/years later ...

What's wrong with putting in a comment, or wrapping up general code in a function giving it a telling name?

The purpose of a standard library is to provide functionality, not to supply particularly telling function names. And even though library names can be telling they're often kind of bland aren't they? Why use plain find when find_string, find_out or find_love may fit the occasion better? Don't let the standard library limit your creativity.

Besides, relying on standard function names to express purpose can be misleading. Take find_if for example. In essence it's a range-based for-loop so when using find_if you may just be iterating and breaking not looking to find anything. The suggestive function name turns out a diversion rather than a help. Don't rely on standard function names to convey intent.

Furthermore, when your ignorant collegues put in a range-based for-loop there is no reason for you to sulk in your cubicle. Instead smile affirmingly as they have used find_if without even knowing.

uhm, I'd also have serious problems working with a programmer that does not *think* ( and think and think and think ... ) when adding parallelism to some piece of code ... yes, you can easily gain orders of magnitude of run time with those libraries, but exploting your parallel hardware optimally and packing the result in a quality product looks like another story ...

Then be happy Mother Nature took a chance and made your brain work in parallel. Otherwise you wouldn't be able to finish one single thought in your lifetime regardless of how hard you were thinking.

After many long hours and much deliberation the C++ standards committee in 2011 finally agreed on a concurrent version of C++. It was a milestone in C++ history and just in the nick of time because most computers came with multiple cores already. But when the operating system generously offers many cores to your applications you stubbornly decline, saying thank you but no thank you; One core will be just fine; Many cores gives me the creeps; Better slow and safe than sorry. This is both unprofessional and uncharacteristic. C++ is about efficiency and C++ programmers traditionally are performance conscious and known for their wish and ability to squeeze the last drop out of available hardware. Ignoring concurrency is no longer an option. It's time to shape up or ship out.