Which programming language did you choose and why?

[Davaris]

Then task them with writing a simple program that creates a vector<int>, adds a few numbers, removes one, and loop over the rest and print them with whatever function they like.
I'd bet they'll get as far as defining it, but fail to figure out how to do almost anything with it.

That's how programming works. You figure out how to do something with some language and then you do it. STL has a logic and it's actually quite easy to understand if you spend some time learning it. What I find funny is that people are never happy about anything, there is always something you could do to "improve" a language. We even have these improved languages like Rust, Go, Python etc. already, so it's difficult to understand why people don't use them. I mean some do, but you don't hear them talking about how much easier it is to do something, because it's not about the language, it's the game/program/whatever you are trying to create.

STL takes forever to compile, is very complicated under the hood so it makes debugging difficult, and was not designed for games, so it doesn't have the reliability, and speed that really good programmers can get. Also C++ templates are the cause of this meme. If you don't use templates, and use unity build, a program of any size will compile in less than 10 seconds, instead of hours, and days in some cases.

"We even have these improved languages like Rust, Go, Python etc."

I don't use Rust, but from the comments I have seen, from game programmers who gave it a good try, it is not productive to use, and they don't need its memory safety features, because they aren't junior programmers. Python is a high level language that is good for prototyping. You can get a lot done fast thanks to its libraries, but the programs run very slow, which is bad for the user experience. I tried learning Go and liked its style, then I remembered it uses garbage collection, and stopped learning it. Garbage collection is not useful for games, because players will notice your program stuttering, when the garbage collector randomly decides to release unused memory.

IMO all people ever really needed was C. They just needed to make better libraries for it, and make it easier to compile, so it is more accessible to new users. Hopefully an AI will be created that can sort out the mess.

Edit:
If any9ne wants to learn the simple way of C programming, watch Casey Muratori's first 20 or 30 youtube videos to get the main ideas: unity build, using bat/shell files to build programs, and his style of programming. I think he calls it compression oriented programming. Basically, he doesn't design everything upfront, he lets the program design itself. So he solves problems one at a time, and if he finds himself solving the same problem several times, only then does he make a general solution. Also, dig around the Handmade Hero forums, there's some good info there.

This is also very helpful.
https://www.gingerbill.org/series/memory-allocation-strategies/

 

[Krice]

STL takes forever to compile, is very complicated under the hood so it makes debugging difficult, and was not designed for games, so it doesn't have the reliability, and speed that really good programmers can get.

- forever to compile: not really, especially if you use IDE and compile only files you have changed
- debugging difficult: why would it be, and good programmers don't debug that much anyway
- not designed for games: why not, I'm using STL without any trouble, although my games are turn based and don't require super speed
- speed: I guess you don't need to use STL, you can write your own lists etc. but is it worth the trouble? If you need that 1% more speed then maybe

 

[Davaris]

STL takes forever to compile, is very complicated under the hood so it makes debugging difficult, and was not designed for games, so it doesn't have the reliability, and speed that really good programmers can get.

- forever to compile: not really, especially if you use IDE and compile only files you have changed
- debugging difficult: why would it be, and good programmers don't debug that much anyway
- not designed for games: why not, I'm using STL without any trouble, although my games are turn based and don't require super speed
- speed: I guess you don't need to use STL, you can write your own lists etc. but is it worth the trouble? If you need that 1% more speed then maybe

"- forever to compile: not really, especially if you use IDE and compile only files you have changed"

Often times you are forced to recompile your entire project, even when you don't want to. Even so, compiling part of your project can take a significant amount of time, which breaks your flow. My entire game takes a small fraction of a second to compile, so fast it seems instant to me. Its as fast and enjoyable to use as scripting. Also, its build system is very simple, and the same on all operating systems. Simpler than any build system in existence. Its just a couple of lines in a script.

"- debugging difficult: why would it be, and good programmers don't debug that much anyway"

People starting out at programming definitely do debug a lot. Experienced programmers less so, but can get themselves into trouble, and then will need good debugging tools that save them time. The handmade hero people value good debuggers so much, one of them made their own debugger called RemedyBG. Unlike Visual Studio which is very laggy, and buggy, it responds instantly, and is well supported.

"- speed: I guess you don't need to use STL, you can write your own lists etc. but is it worth the trouble? If you need that 1% more speed then maybe"

Very good programmers can get huge improvements over ordinary programmers (much more than 1%), because they can build things tailor made for the problem. This is not relevant to STL though.

You can get list libraries from Github if you can't make your own. One array library I saw last year had only 2 stars, but I thought it was good because it was so simple. On the other hand, I've seen libraries with thousands of stars, but they were incomprehensible underneath.

 

[quaesta]

C++/SDL. Mostly because I'm too lazy to implement data structures in C, operator overloading of structs so I can print them out, and lambdas are nice. I do not care for the C++ inheritance or OOP nature: most I ever use OOP is an interface. I find the rest of the stuff OOP stuff to be unintuitive
Funny thing about not using engines is my PC is so shit. Unity takes so bloody long to work. If I ever use a game engine I would either use Torque, Godot or some old Unreal Engine.

 

[Arbiter]

I am nominating you for the RPGCodex retard of the year award.

Voting has begun: https://rpgcodex.net/forums/threads...20th-anniversary-edition.145031/#post-8196578

 

[quaesta]

I am nominating you for the RPGCodex retard of the year award.

Voting has begun: https://rpgcodex.net/forums/threads...20th-anniversary-edition.145031/#post-8196578

Kek, this is a thing? Hot damn. Can't wait to see if I land top ten next year

 

[Catacombs]

Can't wait to see if I land top ten next year

You can accomplish anything if you put your mind to it.

 

[Twiglard]

So apparently C++20's <bit> header means that serialization tests can be run at compile-time. I checked and it works.

 

[rusty_shackleford]

I've replaced a lot of what I used to use python for with c#, other than small one-off scripts.
Very good standard library + good language features + decent performance, excellent lunix support now.

 

[Jonathan "Zee Nekomimi]

 

[SomeGuyWithAnOpinion]

I've replaced a lot of what I used to use python for with c#, other than small one-off scripts.
Very good standard library + good language features + decent performance, excellent lunix support now.

I replaced Python with Bash (actually POSIX Shell in most cases, Bash occasionally when shell decides to suck) and it's surprisingly performant.

For doing anything small-scale (especially system-level tasks), I would highly recommend ditching python entirely. It's a huge dependency and is very slow for what really should be a simple script.

I've always treated C++ as C with convenient extras, and just used C's stdlib.
C++'s template library really is just complete dogshit.

I do this too. "C Style C++" as I call it. If I need a class for something, I write it myself.
I just wish there was a way to jettison the C++ cruft entirely. A lot of it still ends up getting compiled into my binary.

Also, for the record, I don't hate C++ Templates. I think generics are an awesome idea in a lot of cases (like making a completely generic list class). But the STL doesn't really use them well (if at all) and they do take a while to compile.

 

[Krice]

I try to think what is better in C compared to C++, but can't think anything.

 

[SomeGuyWithAnOpinion]

I try to think what is better in C compared to C++, but can't think anything.

- Header Files that actually work for their intended purpose (C++ completely broke them)
- A simple library that doesn't add a bunch of extra bloat to your application or to the spec
- Error messages that are comprehensible.
- C syntax and basic library use can be learned in a day. C++ takes a lot longer to learn and is a lot more prone to issues to the uninitiated (For instance, DON'T use auto_ptr, it's deprecated. Nobody will tell you that and plenty of books still encourage you to use it)

I vastly prefer C++ over C, but some aspects of it are definitely inferior

 

[Krice]

How C++ broke header files? Never heard about it.

 

[SomeGuyWithAnOpinion]

How C++ broke header files? Never heard about it.

It's a very complicated issue, but here's the quick version

In C, header files are used to define a set of functions that are available outside of a module, and nothing else. They do not contain any implementation details whatsoever. There is a very strict delineation between public functions (declared in the header file) and private functions (declared in source files). All functions are implemented in source files. Modules can never see any information about the inner workings of each other and only ever interact through shared common function declarations in header files. Each module is essentially perfectly encapsulated.

I can have a source file with 25+ functions and some variables, but if I only expose 1 function in the header file, only that function will be available to other source files. Header files contain no implementation details, only public API. If I give you a precompiled library and a header file, you have no way to know what variables or functions are defined within that library without decompiling, except for the ones I specify in the header file. You have no information about the inner workings of that function, only it's signature. If I later decide to do a complete rewrite of my code, I can ship another version of the library, and as long as the function signatures in the header file are the same, you won't even need to recompile anything, you will only need to link to the new version.

Outside of sharing libraries, this is extremely useful for segmenting parts of your code into rigid well-defined blocks which can be easily modified, or swapped in and out with other implementations of the same public interface, all with minimal recompilation, and generally makes shared functions very easy to manage. It's fundamentally simple - anything not declared in a header file is free for you to change within your source file at any time, with an express guarantee that no other source file will need to be recompiled or have a dependency on that function or variable.

C++, for technical reasons, requires us to add private variables within a class to our header files. Even worse, if using templates, if we aren't going to define a strict set of possible types for them upfront, we need to define the entire template class within a header file (including the entire implementation) so that the compiler can generate new types for it when they are used. This has encouraged the trend of "header only libraries" which are awful for numerous reasons, please don't use or write them.

Because of the way C++ forces us to put implementation-specific declarations into our header files, we can no longer perfectly encapsulate code into modules. If you send me a pre-compiled library as a binary blob, you're going to have to expose all your private data to me in your header file in order for me to use it in my codebase. If I want to review your header file for the names of functions I can actually use in my code, I have to sift through all the extra private crap. This is even worse when using templates as you will have to expose a lot of your implementation logic to me through the header file as well.

Worse, any change to the signature of a class, including private variables and functions (such as adding a new private variable) will require every module using that class to recompile. If you've ever found that you change something in a class and half of your codebase needs to recompile, that's why. On a slow-compiling language like C++, that sucks extremely hard.

I guess if you wanted to get ultra pedantic about it, technically speaking, I can still use header files in C++ exactly the same way as in C. They aren't broken in the literal sense. But the moment you use C++ features (ie classes), you violate the encapsulation provided by header files because of the design of classes in C++, and header files as a concept become almost entirely useless.

The TL;DR is this. In C If I change function signatures within any module, and these signatures are not in the header file (ie they are local to that module only), no other modules will need to recompile. In C++, any change to any variable or function signature, including private ones, within a class will require all modules using that class to recompile. Because C++ generally compiles very slowly, this can result in a significant amount of wasted time.

All of this would have been fixed if C++ had used a proper import system like most other modern programming languages, and had a template system that didn't suck ass.

 

[Krice]

Encapsulation in C++ is done with classes, not with "modules". Recompiling has never been a problem in my experience, if you change something in a header it will obviously require recompile, so maybe don't change anything and write better code you don't have to fix all the time. I think many "C" programmers use classes, because they need them anyway, they are a superior invention compared to pure procedural programming. Then they whine that C++ sucks. No, you suck.

 

[rusty_shackleford]

I try to think what is better in C compared to C++, but can't think anything.

off the top of my head? restrict as a language feature.
C++ is mostly a superset of C, therefore there's little C does better.
C standard library is generally, significantly better than C++'s. But C++ has full access to it.

The main issue is the C++ ecosystem is trash. Standard library full of useless or poorly designed junk, most third party libraries are poorly implemented with little concern for size or compilation time bloat. This is partially due to people not understanding the C++ compilation model very well.

e.g.,

Encapsulation in C++ is done with classes, not with "modules".

Functions & variables being included across many compilation units that don't need it, needlessly bloats compilation time & binary size. LTO can somewhat help with the latter.
But really, this is just a technical issue that doesn't have to exist but does because ... reasons. People have been saying that modules will fix this for what, half a decade now? They won't. It will be another hacked on solution that barely works.
The only way to fix this is to kill #include and header files. Replace header files with thin interface definition files that are restricted in what they can expose. No definition would be required for things that require compile time computations as long as the module that exposes it is present when linking, which would just be language enforced LTO.
That's how I'd do it, anyways. But it would break far too much existing code.

I think the amount of computing time wasted on C++ compilation due to poor design is extremely underestimated.

 

[Twiglard]

I try to think what is better in C compared to C++, but can't think anything.

off the top of my head? restrict as a language feature.

All C++ compilers have __restrict without #ifdefs.

Template-based containers play better with aliasing since normally in C you use zero-element arrays or full-on type punning for containers. There are some C libraries creating function definitions for containers through macros which is pretty much the same as template containers, but even with them you lose the ability to actually compute things at compile-time.

The main issue is the C++ ecosystem is trash. Standard library full of useless or poorly designed junk, most third party libraries are poorly implemented with little concern for size or compilation time bloat. This is partially due to people not understanding the C++ compilation model very well.
e.g.,

Encapsulation in C++ is done with classes, not with "modules".

Functions & variables being included across many compilation units that don't need it, needlessly bloats compilation time & binary size. LTO can somewhat help with the latter.

That's mostly true, but you can still work to alleviate that.

• To define function return type or argument you only need forward declarations.
• You can use pure virtual ("abstract") or pimpl idiom when you absolutely have to.
• Use unique_ptr with a forward declaration for data members.
• Full specializations for functions don't need to be defined (only declared) in the headers.
• Use extern template to only declare things in the header, when the universe of things you specialize on is closed. For instance when typename T is restricted to built-in types, or you don't care about points or volumes that are 4D and beyond (and only allow builtin arithmetic types).

But it's also possible that the kind of programming work that you do wouldn't benefit from going from C to C++.

Encapsulation in C++ is done with classes, not with "modules".

I do it with namespace detail. Classes and especially inheritance are overrated.

But really, this is just a technical issue that doesn't have to exist but does because ... reasons. People have been saying that modules will fix this for what, half a decade now? They won't. It will be another hacked on solution that barely works.
The only way to fix this is to kill #include and header files. Replace header files with thin interface definition files that are restricted in what they can expose. No definition would be required for things that require compile time computations as long as the module that exposes it is present when linking, which would just be language enforced LTO.

Or just store all type information in object files and only operate on those type definitions that are recursively required for current compilation unit. Only operate on all definitions to detect ODR violations.

 

[rusty_shackleford]

All C++ compilers have __restrict without #ifdefs.

But it's not a language standard and implementation details likely differ. It's one of the very few things C has over C++.

Also, union type punning isn't well defined behavior in C++ but... meh, honestly probably just adds confusion. I think it was C++20 that added bitcast, but compilers generally knew to detect memcpy in this situation and optimize it away anyways.

 

[Twiglard]

All C++ compilers have __restrict without #ifdefs.

But it's not a language standard and implementation details likely differ. It's one of the very few things C has over C++.

It's one of these standardese things where technically sizeof(size_t) > sizeof(void*) could exist but it never does.

Also for many cases where you use restrict, C++ allows a zero-cost abstraction layer for SIMD intrinsics. With better code than autovectorization would allow. See opencv's hal module that's used internally for matrix ops in opencv_core or in opencv_imgproc.

 

[rusty_shackleford]

It's one of these standardese things where technically sizeof(size_t) > sizeof(void*) could exist but it never does.

It's not part of the standard at all.
Also,

All C++ compilers have __restrict without #ifdefs.

GNU's extension is __restrict__, msvc's extension is __restrict

MSVC's C++ __restrict implementation also differs from C99(documented), and cannot be applied in the same places as the GNU C++ extension. e.g., I see nothing in MSVC's documentation about applying restrict to a this pointer.
MSVC also has some extra syntax for applying it to a returned pointer. GCC specifies the behavior when applied to references, MSVC does not nor does it state whether it can be at all.

 

[Twiglard]

GNU's extension is __restrict__, msvc's extension is __restrict

GNU accepts __restrict.

The distinction is purely academic since you won't have issues applying the attribute on any compiler (GNU, LLVM, MSVC, Intel) you and users of your code are going to use.

C++ also has additional rules that deal with aliasing, such as value categories (this pointer is its own thing), elision of temporaries (expression templates), RVO, NRVO, constexpr (constant tables computed at compile-time), etc.

MSVC also has some extra syntax for applying it to a returned pointer.

That's a variation on __attribute__((malloc)).

 

[rusty_shackleford]

The distinction is purely academic since you won't have issues applying the attribute on any compiler (GNU, LLVM, MSVC, Intel) you and users of your code are going to use.

It's not academic, GNU's implementation is much more well defined.

What does __restrict do on a pointer in a struct in msvc? It doesn't say. GNU explicitly references the C99 restrict keyword, whereas MSVC explicitly states that it is merely similar, then goes on to state an example where it is different.
https://learn.microsoft.com/en-us/cpp/cpp/extension-restrict?view=msvc-170

__restrict is similar to restrict for C starting in C99 and available in /std:c11 or /std:c17 mode, but __restrict can be used in both C++ and C programs.

When __restrict is used, the compiler won't propagate the no-alias property of a variable. That is, if you assign a __restrict variable to a non-__restrict variable, the compiler will still allow the non-__restrict variable to be aliased. This is different from the behavior of the C99 C language restrict keyword.

'similar'
https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html

As with the C front end, G++ understands the C99 feature of restricted pointers, specified with the __restrict__, or __restrict type qualifier. Because you cannot compile C++ by specifying the -std=c99 language flag, restrict is not a keyword in C++.

'C99 feature'

We can already assume they differ solely based on the exception Microsoft defines above, as far as I can tell GNU does not behave that way.

We can assume that otherwise where explicitly stated, the GNU __restrict__ will work as defined in the C99 standard and if we were being pedantic we could analyze the implementation itself to confirm this. Microsoft makes no such guarantees, and until msvc is open source there is no way to verify for ourselves.
Therefore, __restrict/__restrict__ is not portable and I would reject it in any code that was expected to compile using msvc. I'd rather not have to deal with possible obscure implementation-defined errors. MSVC's __restrict is a vendor-specific extension that is very similar but not the same as C99's restrict, GNU's __restrict__ is a faithful implementation of C99's restrict with extra C++ support that is a vendor-specific extension.

 

[rusty_shackleford]

And on a tangent, I'd recommend sticking to vendor-specific extensions that don't affect program correctness if you are going to use more than one compiler. Various vendor-specific hints are useful, as even if they don't behave the same we can assume the program will still be correct.

If I were creating a cross-platform program that included windows, I'd probably only use clang. It has excellent native windows support now through its msvc-compliant frontend with the familiar GCC frontend on other platforms. GCC works on windows, yes, but it is a headache and not a drop-in replacement like clang-cl.
Otherwise, GCC. Most of Clang's advantages in other areas have been overcome by GCC, and clang has become slow — once its greatest feature is now gone.

 

[SomeGuyWithAnOpinion]

How C++ broke header files? Never heard about it.

...Long explanation of how C++ completely destroys encapsulation...

Encapsulation in C++ is done with classes, not with "modules". Recompiling has never been a problem in my experience, if you change something in a header it will obviously require recompile, so maybe don't change anything and write better code you don't have to fix all the time. I think many "C" programmers use classes, because they need them anyway, they are a superior invention compared to pure procedural programming. Then they whine that C++ sucks. No, you suck.

Really? Even when people point out genuine, serious, major issues with a language, you just blame them for being bad programmers?

There's obviously no reasoning with some people.

I am a C++ programmer. I use it every day. Stop comparing me to some C elitist. The language is kind of busted and I wish it worked better. And I wish we had real encapsulation like the C people have, not fake, polite, compiler-enforced-only encapsulation where we still have to compile a bunch of extra private data into our modules.

Your response was extremely stupid and I don't see much reason to waste any more time on you.