121–130 of 179 posts
While I find the "sane C++" approach pragmatic and practical all things considered, I'm firmly in the "time to use a better language if possible" camp. The problem with approaches requiring extra discipline is: it's an extra mental burden to bear while programming. Also, you'll always be limited by the fact that you're working in a less pure ecosystem and will likely end up using libraries written in "not very sane C…
Earlier quoted context omitted.
You don't have constructors that 'fail'.
So, allocating memory for objects is not part of construction? Again, why not just stick with C?
If you come to finance, most of the developers love premature templatization, it makes them feel like they know something. Not sure it that can be attributed to their insecurity about C++ coding skills, but it gets really ridiculous at times.
Earlier quoted context omitted.
What's wrong with using templates vigorously?
Well, let me give you an example that I have seen recently. There was this function that suppose to convert numeric value to string. So numeric type was templatized. Then with combination of enable_if and static_asserts there were checks to avoid doubles/floats negative numbers. So whats there left besides unsigned integers?
Earlier quoted context omitted.
It was almost the exact proposal specified by my grandparent post except using a pointer rather than an optional. It's also a technique that is widely used. See for example the cocos2d-x game library. The benefit of such a technique is that you can then make the constructor private, making it impossible to create an object and not also call the initialize() method.
It is very different from having a static method returning an optional, which guarantees that you can access the optional (with at least an assert in debug mode) only if the object is actually successfully constructed. Using a separate initialize member function means that you may have objects in a zombie state laying around after a failed construction which lead to all kind of initialization order issues (you might…
It does, and it can be, but in situations where it matters, the static create function typically returns a value from a preallocated pool of memory, so objects are all contiguous and cache friendly.
While I find the "sane C++" approach pragmatic and practical all things considered, I'm firmly in the "time to use a better language if possible" camp. The problem with approaches requiring extra discipline is: it's an extra mental burden to bear while programming. Also, you'll always be limited by the fact that you're working in a less pure ecosystem and will likely end up using libraries written in "not very sane C…
For example, this is what Oryol achieves, targeting OpenGL on native and WebGL on web. I don't think anything could beat the "Orthodox C++" approach for that purpose, aside from using C (which is what I'm using for a project right now).
If you come to finance, most of the developers love premature templatization, it makes them feel like they know something. Not sure it that can be attributed to their insecurity about C++ coding skills, but it gets really ridiculous at times.
I have a friend who runs a hedge fund, not really insecure at all but uses templates vigorously. More stuff in compile time rather than runtime. In critical sections inheritance can be prohibitively expensive because of the use of lookup tables.
While I find the "sane C++" approach pragmatic and practical all things considered, I'm firmly in the "time to use a better language if possible" camp. The problem with approaches requiring extra discipline is: it's an extra mental burden to bear while programming. Also, you'll always be limited by the fact that you're working in a less pure ecosystem and will likely end up using libraries written in "not very sane C…
It is, however, a rather restrictive standard with critical systems in mind. Usually, you don't want such restrictions in regular software development, you want the full power of the language.
Ensuring sanity is better served with static analyzers (linters) that can be tailored to the specific needs of the project and be regularly updated with new rules.
Earlier quoted context omitted.
What's wrong with using templates vigorously?
Some things that are not so nice about templates: - dozens to hundreds of compiler error lines for a single error, where it's hard to find out what the real problem is (IDEs often point to the wrong line) - Code is hard to follow. E.g. try to figure out from boost asio source code which code is actually used if if you do a async_read(socket). I personally gave up after the second level of template substitutions, and…