next »

[JWki]

I wouldn't say this is really a grumpy post but I guess this area applies most.

I recently went on vacation and tried catching up on my c++. It's crazy that even with a year where I've only been putting maybe 10% of my time into c++ things have already moved so forward. I feel like I keep falling more and more behind in regards to the STL additions and changes.

Now I'm reading about C++ metaclasses and I can barely keep up. I'm a little weary about metaclass abuse but at the same time they sound like they would solve a lot of issues major frameworks have had to work around using code gen and macros.

I know I need to keep an open mind and should probably allocate more time to keeping up with c++ but sometimes I miss coding in C where I can fit all the rules in my brain at once. I've been writing a lot more C at home lately.

I used to try and keep up and be as cutting edge with my C++ as possible when I started out, for like the first two years. During that time I did have a subtle feeling of being overwhelmed every so often - how could someone possible wrap his head around the entirety of C++? Then I slowly got exposed to more and more programmers that despised C++, and I was irritated at first, but so many points they made resonated with me, slowly leading to the realization that my impression of C++, of its complexity, wasn't purely because I was a beginning programmer and just couldn't be expected to keep all of it in my head, but the language actually IS bloated and ugly in a lot of places, it DOES add complexity that is unnecessary in a lot of situations and trying to use all of its features is actually a dangerous road because the feature set is inconsistent and bloated and as a result your code will be inconsistent and bloated if you try to exploit it.

I'm not quite ready to jump to pure C yet as C++ does have some features that I like - I use captureless lambdas a lot, I do use templates for some things (although I'm looking into how to reduce that) - but apart from that my code looks much more like C than C++, and while it probably wouldn't pass code review by a C++ expert, I'm pretty happy with it, it's fun to write, easy to read, debug and optimize.

EDIT: And RenderDoc is probably the best graphics debugger you'll find atm:
https://renderdoc.org/

I found it to be amazing to say the least - I have started using it when I started working on my graphics API abstraction, and it saved me COUNTLESS hours, allowing me to find errors in my implementation, that I know from experience I usually need hours to find, within minutes.
Basically you capture a frame of your application and then inspect EVERYTHING related to graphics in that frame - draw calls, synch points, resource bindings at each point, you can inspect the contents of textures, buffers, debug shaders, visualize vertex shader input/output as 3D meshes, etc etc.
I don't know how many hours it could have saved me in the past had I tried it sooner.

[qMopey]

C++ is a ridiculous language. I don't even bother looking into the newer features. I enjoy some of the C++11 features (like using, and the = operator for member initialization in headers), but the vast majority of new stuff is not worth the time.

At work I just ask my co-worker who cares about new C++ features if I ever have a question. Typically the only reason I have questions is because said co-worker uses new features in production code. Personally I think it's super annoying when the new features pop up in production code. The new features are never really worth the abstraction cost (not performance cost, but readability, clarity, and code-flow cost).

I don't really think "pure C" is a good option. Some C++ features are wonderful, like namespaces, operator overloading, function overloading, and member initialization. These are things universally regarded as "good". There's not really a good reason to throw these features away and move back to C, other than a certain platform only supporting C, like some esoteric embedded device.

[JWki]

C++ is a ridiculous language. I don't even bother looking into the newer features. I enjoy some of the C++11 features (like using, and the = operator for member initialization in headers), but the vast majority of new stuff is not worth the time.

At work I just ask my co-worker who cares about new C++ features if I ever have a question. Typically the only reason I have questions is because said co-worker uses new features in production code. Personally I think it's super annoying when the new features pop up in production code. The new features are never really worth the abstraction cost (not performance cost, but readability, clarity, and code-flow cost).

I don't really think "pure C" is a good option. Some C++ features are wonderful, like namespaces, operator overloading, function overloading, and member initialization. These are things universally regarded as "good". There's not really a good reason to throw these features away and move back to C, other than a certain platform only supporting C, like some esoteric embedded device.

Yeah pretty much this.
Having to work with a subset of a language is somewhat gross though so I'm hopeful that at some point a new language pops up that works off the right parts of C and adds the modern features that actually benefit the programmer. JAI looks like a potential candidate but I haven't followed it closely lately.

[Schrompf]

Being one of those coworkers pursuing new C++ features I think that there's a lot of good stuff worth the brain cost. Both the "quality of life" improvements such as range-based loops or auto and the seemingly arcane stuff like filesystem or future. Even variadic templates have their place and time, but I guess this is the part you're offended by. It tends to get misused by some people for the lone sake of using it. I, too, make a sad face when encountering code using type_traits, although I learned to read and maintain it over the years.

[JWki]

Being one of those coworkers pursuing new C++ features I think that there's a lot of good stuff worth the brain cost. Both the "quality of life" improvements such as range-based loops or auto and the seemingly arcane stuff like filesystem or future. Even variadic templates have their place and time, but I guess this is the part you're offended by. It tends to get misused by some people for the lone sake of using it. I, too, make a sad face when encountering code using type_traits, although I learned to read and maintain it over the years.

I have to admit I haven't looked at filesystem in depth but how does it seem arcane? Isn't it just, well, filesystem stuff like directory enumeration etc?

[Schrompf]

I have to admit I haven't looked at filesystem in depth but how does it seem arcane? Isn't it just, well, filesystem stuff like directory enumeration etc?

It is. It was just the first example of C++17 that came to my mind, it's probably a bad example. For the sake of the discussion I'd like to replace this with RValue References. Some people think those to be arcane.

[oahda]

C++ is under the curse of having to retain absolute backwards compatibility while still introducing modern features and cleanups over time, which does make it bloated and one heck of a beast to learn. I usually suggest to people who are weighing between C and C++ that they might as well set things up for C++, but use it similarly to C, only picking a couple of convenience features of their choosing from C++, as suggested above.

I'm personally one of those who likes to stay up to date and I actually can't even remember coding in C++98/03 at this point, even tho that's what I originally learned and probably used for more years than I have been using C++11/14, but that's just how I work. I stay selective and consistent about my own code, but working in teams it's probably very annoying (I haven't been on a team that uses C++) that there is so much legacy stuff and alternative ways to do things lying around the language, and C/C++ programmers have a much higher tendency to come up with their own wacky conventions than Java or C# programmers, who tend to follow more or less the same standard across the board.

I won't recommend or suggest anything tho. It's all a matter of taste. Figure out what you like. c:

I have to admit I haven't looked at filesystem in depth but how does it seem arcane? Isn't it just, well, filesystem stuff like directory enumeration etc?

It is. It was just the first example of C++17 that came to my mind, it's probably a bad example. For the sake of the discussion I'd like to replace this with RValue References. Some people think those to be arcane.

As far as I've understood, std::filesystem is basically boost::filesystem brought over into the STL (I haven't used it yet since I'm still sticking to C++14 for my main project for now tho). If that means anything to you (I'm using boost::filesystem in my current project for the first time and I think it's great at least, but I don't know how similar the STL version actually is, or if it's even finished). p:

[ferreiradaselva]

I'm gonna be the black sheep and say I prefer C over C++ . I almost never use data structures that C++ offer, and when I need some particular data structure (which hardly happens), I can always look for some library available on C. The only feature that I'm jealous for is the operator overload, specifically for the math operations (vector, matrix and quaternions).

I will def check that RenderDoc. It sucks to spend too many hours trying to debug something graphical.

[InfiniteStateMachine]

Good discussion.

I should correct myself and say at home when I'm doing games etc I don't actually use ANSI C. I sort of do C with namespaces and a few minor c++ features such as lambdas so there's definitely value there. The only times when I use ANSI C is when I'm trying to make a reusable library in the style of stblib. When I do it in ANSI C it makes it a lot easier to generate bindings for other languages (I often bind my native code to C#).

The parts where I begin to dislike C++ are when the STL gets introduced. I've used maybe 5-6 STL replacements on console games and I found all of them to have WAY easier API's than STL and often they are more performant too. This is a minor complaint in the grand scheme of things but I wish they would use the standard nomenclature for common operations. Like std::transform should be called std::map (I know there's a collection type with that name but I would argue that's the one that needs to change). I guess the rationale for transform is I think you can specify the same region of memory as both the input and output which might technically not be a mapping. Other examples would be things like push_back etc. I know I'm nitpicking at this point haha

I think STL probably suffers from trying to be all things to all people and still be flexible enough to plugin your own allocators etc. When it gets that generic it starts to become unreadable.

Don't even get me started on R/L/X/PR/Etc values. I understand them enough to use them but there's a never ending source of discussion on weird edge cases relating to the value type that essentially requires me to carry the Scott Meyers book everywhere I go.

With the new C++, it becomes a huge time sink trying to maintain a coding standard in a team with 70+ programmers. Not to say it wasn't an issue before but now it feels even worse.

I don't hate C++ at all but I do hope that some of the new systems programming languages without the baggage become more viable in the future. It would be nice to have more options in the performance oriented language space.

Anyone here ever hear about M#? That sounds like a dream language to me. I'm sure in practice it doesn't work as nice as c#.

[InfiniteStateMachine]

Also Re : RenderDoc. Cool! I'm gonna have to try that out sometime.

Incidentally another similar program went OSS yesterday

https://github.com/milostosic/MTuner

[JWki]

Yeah STL is something I don't use anymore in my own code.

Edit: also I'm very grumpy because I'm having troubles with importing Fbx files. I'm using OpenFBX instead of the Sdk because it's way more lightweight and has all the features I care about atm so the actual importing of the data isn't an issue. However, due to a series of unfortunate events and arbitrary decisions, my application uses a left handed coordinate system at the moment and let's just say the matrix code is a bit handweavy so I'm running into all sorts of inconsistent behaviour with submesh transformations.
After messing with it for far too long then letting it rest in the back of my head for a few hours I've come up with a strategy to solve the issues - first, refactoring my matrix code so it's explicit about handedness and matrix layout, then rewrite the transformation code with explicit operations in the right systems, with clear conversion points.
Should have done that from the start really.

[qMopey]

rvalue references! Move semantics! Oh god just kill me now  like who cares. That stuff is just weird workarounds to other crappy C++-isms. Instead of writing code that performs deep copies and other nonsense, how about we just avoid all that cruft and stick to the features that are actually useful. /rant

[oahda]

i like move semantix

[JWki]

i like move semantix

They solve a problem that shouldn't be there in the first place though.

[Crimsontide]

I'm curious as to what others think would be a better alternative.  For example, if you could replace move semantics, how would you change them?  How would you replicate or work around what they propose to solve?

[JWki]

I'm curious as to what others think would be a better alternative.  For example, if you could replace move semantics, how would you change them?  How would you replicate or work around what they propose to solve?

The better alternative is not to tie ownership of data to objects. Have all your types either be value types or pass them around by pointer and forget about the rule of three, five, seven, nine or whatever.

[Crimsontide]

I'm curious as to what others think would be a better alternative.  For example, if you could replace move semantics, how would you change them?  How would you replicate or work around what they propose to solve?

The better alternative is not to tie ownership of data to objects. Have all your types either be value types or pass them around by pointer and forget about the rule of three, five, seven, nine or whatever.

Doesn't that sort of negate encapsulation and the single responsibility principle?  And the data has to live somewhere, do you advocate not using containers?

I'm not trying to be negative/call you out, I am just really curious and playing a bit of devils advocate here to further my own understanding (tone is hard to convey online, I want to emphasize this is not an attack or criticism).  In my spare time I've been working on my own language, and while I have a lot nailed down, move and rvalues have left me with a bit of an uneasy feeling.  I understand why they are in C++, and are pretty much essential to containers, but there are still things about them that feel a bit... iky?

[InfiniteStateMachine]

So one of main reasons I hear people want to use move semantics is often to avoid a copy on return. In this case that's pretty much the same as out parameters is it not?

I'm sure I'm wrong haha

[qMopey]

I'm curious as to what others think would be a better alternative.  For example, if you could replace move semantics, how would you change them?  How would you replicate or work around what they propose to solve?

The better alternative is not to tie ownership of data to objects. Have all your types either be value types or pass them around by pointer and forget about the rule of three, five, seven, nine or whatever.

Doesn't that sort of negate encapsulation and the single responsibility principle?  And the data has to live somewhere, do you advocate not using containers?

I'm not trying to be negative/call you out, I am just really curious and playing a bit of devils advocate here to further my own understanding (tone is hard to convey online, I want to emphasize this is not an attack or criticism).  In my spare time I've been working on my own language, and while I have a lot nailed down, move and rvalues have left me with a bit of an uneasy feeling.  I understand why they are in C++, and are pretty much essential to containers, but there are still things about them that feel a bit... iky?

Forgive me if I'm incorrect; please anyone that knows a lot about move semantics and rvalue references, by all means feel free to correct me.

OK that aside, my own personal understanding of the whole move semantics and rvalue references thing was to facilitate optimization, specifically moving values through semantic "hoops" that must be jumped through.

Take for example some kind of math notation that uses a std::vector style array data structure. We have a BigVector and a BigMatrix class, and they are used in a numeric algorithm to solve a big A * x = b linear algebra equation. Sometimes we may want to write out a line of code that looks like:

Code:

A = S * dF - Identity * S0;
tmp = A * v - g;
b = dF * tmp;

Completely nonsense math, but a good example anyways. The operators are quite expressive and sort of math actual math notation on paper. The level of expressiveness is nice from a semantic point of view.

Say A, S, dF, Identity and S0 are BigMatrix instances. Others are BigVector instances. If these operators are just overloads of a typedef of std::vector many deep copies are perform for all of the various rvalues mixed in on the rhs of the equations. Each expression forms a new temporary instance, often times with new memory allocations and their own set of memory deallocations.

This sort of stuff really is a limitation of C++ semantically. The language is not expressive enough in terms of expressions to support an optimal code generation here.

So then move semantics can come along and capture all of these temporary states left over by the *+- operators. They can "steal" the memory inside of different instances, passing along the pointer to an internal array across each operator. All of this could be implemented in C style to explicitly show handling of memory:

Code:

BigMatrix tmp;
tmp.memory = PRE_ALLOCATED_POOL;
Mul(S, dF, tmp); // do S * dF, store result in tmp
Mul(Identity, S0, S); // reuse memory of S as a tmp storage
Sub(tmp, S, tmp);

// and so on ...

Of course the above free-function style is also not very expressive; the user must manually and painstakingly track temporary values between operations. This isn't too bad, since explicit control over memory ensures the user can hit top performance, but still, the semantics are not well suited for this task.

So instead of designing a language of some kind (I don't know what this language would look like) that can solve these problems, C++ takes the approach of patching their old shitty designs with new shitty designs. It's exactly like solving the side-effect of a bug in production code as opposed to solving the root cause.

Move semantics and rvalue references are there for stupid things like stealing pointers across instances, and other bullshit. The reason I say "bullshit" is because rvalue references and move semantics are features useful to a C++ programmer only if said programmer is using certain C++ features. Making a language feature to solve specific shortcoming of another language feature is a typical pitfall in language design. It's a big no-no to make one-off language features that only solve one problem.

Ideally a language would provide some fundamental primitives that can be used to express whatever the user wants. Users really like encapsulation, but not necessary on an object-object basis. Users really like polymorphism, but not necessarily on a class to class basis, and not necessarily tied into C++-style inheritence. Users really like code-generation for compile-time polymorphism, but not necessarily in the form of C++ templates, which pollute translation units with codegen spam. Ideally users can express strict memory patterns across their statements and expressions (like the above examples), but not necessarily in the form of C++ deep copies or other OOP-ey messes.

IMO language design is in the cave-men age where we just discovered "fire", trying to burn everything down with objects and classes. Yet to discover the steam engine, or metallurgy.

People take OOP and run with it whether or not it actually helps. Polymorphism? Lets add polymorphism to our OOP! Encapsulation? Lets add that to our OOP! Inheritance? Lets put that on our OOP!

[qMopey]

As for what is a better alternative? Who knows.

Like, I want to be able to say I'm instantiating some kind of data type in one place in the call stack, and associate it with memory elsewhere, then move the instance around on the stack freely, and have the associated memory stay put, but still do some intelligent manipulation between different instance involved in useful operations.

The reason built-in types like floats are easy to work with is float instances fit in a register. So when we apply operators, pass them up and down the call stack, etc. they can be passed in registers. But if I have a small struct on the stack that is somehow related to memory elsewhere, I still want to pass the struct around in registers (if it's small enough), or at least copy it around the stack.

Creating "expression" objects in C++ is totally possible, but it's super verbose in terms of how much code must be written. The language designer would want to cut down how much code has to be written in order to associate external memory with a small stack object. This concept would also need to fit in with the rest of the language; ideally other language keywords or notations could be used to trivially build the concept we're talking about here, instead of designing a one-off language solution.