wow - you really call that better than c++11 range based loops - just wow
Yes. I actually believe that. When you've got dealt with a fair share of bugs caused by yourself, caused by external libraries, caused by the compiler, caused by hardware errors, caused by weird garbage collector behaviors (i.e. when interacting C++ with C#), caused by driver errors, caused by OS errors... you learn to appreciate the beauty of a loop in 4 lines:
- container.begin() can fail (container's bad).
- vector<T>::const_iterator itor = container.begin() can fail (vector<T> and the container's type matched at compile time but they don't match at runtime, likely DLL hell, but not the only explanation).
- container.end() can fail.
- vector<T>::const_iterator end = container.end() can fail.
- while( itor != end ) can fail.
- *itor can fail.
- ++itor can fail.
Now condense that into ranged for, a single line of code, where all of those multiple failure points (which aren't mutually exclusive) are hidden behind compiler-generated code. Debugging that is a nightmare, because you have to look at the assembly of code you didn't write (which I often do, but I'd like to prevent if possible).
Modern C++ features seem to be focused around typing speed. That is hardly the limitation factor when developing code. I don't save much time from typing that while loop by typing a ranged for. I do, but it's not much. But I do save a lot more time when the loop crashes and I need to debug it.
Furthermore if I later need to add a second condition to the loop, I then need to remove the ranged-for loop and convert it to a regular one.
If you think this is harsh, you should look at Nasa's
coding guidelines for mission critical flight software.
If you think these edge cases won't happen to you... well they happen to me. And quite often. Just 6 days ago I filled a bug report regression to Apple where the latest XCode 7.3 compiled iOS code incorrectly crashing inside the initialization of constant global variables (__cxx_global_var_init). std::vector was involved btw.
I had to change our code just to workaround the compiler bug.
So yeah, I'll take my 4-line loop any day over a ranged-for loop.
I just hate it when companies deliver their own string/vector/network class
I get what you are saying, but the flipside of that coin is:
I hate it when every platform ships with its own implementation of the standard libraries which could have different behaviour from my other platforms.
Indeed. Diverging behavior causes a lot headaches when you're writing a library that targets Windows, Linux, OS X, iOS, Android & Windows Phone.
One of the things I like about std::vector is that you get a lot of sweet functionality, grab a pointer to its internal data and treat it like a raw pointer. But even then, there are edge cases where std::vector could eat a lot of performance in some, but not all, of the implementations.
This is the reason I wrote "Ogre::FastArray". It's a replacement for std::vector in critical paths. FastArray behaves the same way in all platforms and has a very well known behavior with little hidden surprises. But it's not a container to be used everywhere. Try using it in complex non-POD datatypes and it may crash.
I could bring more examples but I don't have the whole day.
I just hate it when companies deliver their own string/vector/network class. U can't google issues. Often these classes are terrible documentated. These devs believe they can achieve better results. And they do, in their specific tests. But most of the times they fail in overall performance.
Honestly I rarely see they fail in overall performance. Writing your own std replacement that outperforms the standard std::map for example is quite easy.
But scratch that. Because often we wouldn't use std::map in performance critical paths, and like you said, writing your own does indeed come with a bag of potential bugs in the implementation (which translates to lost development time and frustration).
What I see is a difference in phylosophy. When you say "U can't google issues" (which is good to be able to google issues) I say "yay, I can step inside and see what's going wrong. Heck I may even be able to fix it!". My first reaction "step inside, then use google". If I step inside and see it's a complex trainweck, then perhaps I should reconsider my choice of libraries.
std::string is another class I like. Quite easy to use, and string manipulation can be very difficult. Its performance sucks (it's filled with reallocations), but it's great for dealing with logging or user interaction.
I don't like reinventing the wheel either. The thing is, boost isn't a wheel. It's a decagon that happens to roll enough to get things moving, but it drags like hell.
I would choose libevent a billion times over Asio for example, libevent is a great example of a library I would use over handrolling my own. It's small, simple, efficient, portable, and popular.
std::vector is nice, std::string is nice. std::map & std::set are useful but if avoidable then better. std::find is great, std::lower_bound is great. std::sort is very useful.
We move outside these functions and we enter controversial territory. Heck, I had to write our own Ogre::min and Ogre::max for floating point (literally one minss and maxss instruction) because std::min & std::max were generating horribly bad code.
mkultra333 wrote:VS2015 wouldn't install, it kept freezing midway, I suspect while trying to download Android components. The ISO doesn't work either, it still requires online downloading.
That's sad. I installed VS2015 without Android components (I plan on installing that
later), so far I'm much more happy with VS2015 than 2013; particularly when it comes to UI responsiveness. That is a huge win in my book. Build times didn't seem to have improved much though.