Which programming language did you choose and why?

[Twiglard]

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.

MSVC++ is actually pretty conformant and doesn't ICE much. It also has better LTO pruning-wise. It's also better for debugging with anything other than -O0, as well as combining LTO with debug info, something GCC is completely incapable of and LLVM probably still has problems with.

clang with ld.ldd and libc++ is good too and probably has better PGO but there's no useful debug info on Windows when optimizing.

I didn't try LTO with ld.bfd having had some bad experiences with it years ago. ld.gold is entirely unavailable on Windows.

I'll probably resume gamedev next week but for now I can't get any useful performance metrics. Need to have an update function that takes at least several milliseconds. I want to check out various approaches such as drawing first, then glFlush followed by update and swapbuffers. Either that or wgl share lists and a condition variable, with everything except swapbuffers and the message pump happening off-thread.

If the draw/flush/update/swapbuffers trick works then the only threading I have to do will be texture streaming.

 

[Krice]

Surprisingly often you see people say "classes and especially inheritance are overrated" in which case these people don't have a clue what they are doing. It's ok I guess, not everyone can be good programmers. I personally don't see any problems in C++, that's because I'm good. No, I'm great. Sometimes it seems to be just trying too hard to fight against some language features that are there for a reason. Like classes, and inheritance. Stop trying to be "too" smart, because you are not that smart after all.

 

[Krice]

where we still have to compile a bunch of extra private data into our modules.

I don't even know what this means. Extra private data? What modules?

 

[Norfleet]

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.

See, speaking as somebody who is not actually a programmer, but plays one on TV, when I first encountered C++ and its "private" bits of code, I thought this was the most absurd and annoying thing ever, that existed purely to be irritating (especially when you are the only programmer or working with code against its will). It wasn't until I had to work with C# that this notion finally began making any sense to me, because in C++, it just plain didn't do anything useful at all, except for making C++ compile times absolutely horrid because it tended to cause everything to have to be recompiled. So I always ended up just using C++ in the form of C but with extras whenever I actually wrote anything in it.

 

[what am i doing]

C++. I like the syntax, it feels natural to me. I know a lot of people hate C++'s syntax, but I personally like it, and since I'm working solo, that's fine for me. C/C++ is basically industry standard for game development and high performance programming in general, so a lot of learning materials and guides are written in C or C++ (most commonly, C-style C++). It was basically the natural choice. I did consider Rust as well, but between the syntax (which I don't like) and the fact that it seemed to still be very "in development" with a lot of gamedev related crates having uncertain futures (I saw a lot of cases where this or that graphics-related crate was abandoned in favour of a new one) I felt like C++ would be the better and more stable choice.

I do prefer C++ over C for a couple reasons; one is that the C++ standard library offers a lot of really useful tools like vector, various hashmaps, smart pointers, etc., another is that RAII / destructors are great, and perhaps most importantly C++ makes it easier to write object-oriented code. By which I mean code that is oriented around objects, not inheritance. I find it easier, conceptually, to deal in objects that fit together and contain functions rather than a collection of free-floating structs and functions. I know you can basically write object-oriented code in C, but not as easily as in C++.

So C++ works best for me, and my personal style. I have heard it can be a pain for larger teams if you don't strictly enforce use of a limited subset of C++, because the language is so vast, and there's such a colossal amount of things that can be written in it, if you let a team do whatever they want you'll have person A write some C++ that person B will find difficult to decipher because it's in some area of the language that they've not delved into.

 

[SomeGuyWithAnOpinion]

Surprisingly often you see people say "classes and especially inheritance are overrated" in which case these people don't have a clue what they are doing. It's ok I guess, not everyone can be good programmers. I personally don't see any problems in C++, that's because I'm good. No, I'm great. Sometimes it seems to be just trying too hard to fight against some language features that are there for a reason. Like classes, and inheritance. Stop trying to be "too" smart, because you are not that smart after all.

Inheritance genuinely kind of sucks though in a lot of cases.

I have seen some composition over inheritance models which work FAR simpler and with far less code than inheritance-based systems. It depends on the context.

In terms of a game, I have seen people use the standard "Everything inherits from Entity" model (like what Source uses) and it has it's merits, but having a mostly flat class hierarchy with classes like Inventory and HealthSystem and MovementSystem that you "glue" together in your entity classes works just as well if not better depending on the game environment. Unity uses that model and it works wonderfully.

Nobody but the most diehard procedural programmer (read: fat "minimalist" neckbeards like the losers over on suckless.org) makes blanket statements about classes and inheritance being inherently bad. At the same time, Inheritance is not a panacea and should be used with exactly the same caution as any other design pattern. I generally find it's overused, and horrendous use of multiple inheritance especially can utterly destroy a codebase, which is exactly why many other languages limit it. Hence, "overrated". People see it as a magic bullet for OO programming and it's really not. It's just another tool. Encapsulation and separation of concerns are FAR more important in my experience, and will do a lot more to make your codebase easy to work with than making everything inherit from something.

where we still have to compile a bunch of extra private data into our modules.

I don't even know what this means. Extra private data? What modules?

Each .cpp file compiles to a .o file before they are all linked together to make your program. Call them modules, or objects, or whatever the hell you want. C object files are tight and simple because of the simple way header files work. C++ forces us to put a bunch of private data (and in the case of templates, implementation details) into our header files which bloats our modules and forces recompilations when anything related to that private data changes. That's an inherent flaw with the way C++ classes and header files work. Pointing that out is not a criticism of OO or Classes or Inheritance or anything like that. You seem to be taking a lot of things personally.

 

[Krice]

C++ forces us to put a bunch of private data (and in the case of templates, implementation details) into our header files which bloats our modules and forces recompilations

If your class requires to include some header file, that's how it works. It doesn't "bloat" object files, your programming style probably does more on that problem, if you can call it a problem. You can use forward declaration in many cases and if you notice that your header file has lots of includes then there could be something wrong with the way you organize the code. Classes should not be large and they should not require a lot of includes in the header file, but of course some classes are bigger than others. However the structure of program should be a lot of small classes with less dependencies which are then used in couple of large classes.

 

[Not.AI]

Encapsulation and separation of concerns are FAR more important in my experience, and will do a lot more to make your codebase easy to work with than making everything inherit from something.

This.

 

[Not.AI]

I don't like how some frameworks pretty much assume MSVC to work in it. Say Vulkan.

 

[Tramboi]

I don't like how some frameworks pretty much assume MSVC to work in it. Say Vulkan.

How so ?

 

[Not.AI]

How so?

MSVC and project files. Vulkan as used in practice or Unreal Engine, all the "big" systems like that.
Don't like using cmake as well; make is fine for me. Don't rely much on IDE. As few files as possible. Just think and write.
Not not not spend time searching why something that has nothing to do with my part broke over time.
Minimal toolchain and all things in one simple structure forces making sure things that don't change won't be breaking anytime soon in the future.

BTW, speaking of minimal toolchain systems, OCaml 5 is finally out. So now useful for multicore. After like a decade. I always liked OCaml. Now it might be useful.
Just like erlang is super awesome.

I mean most systems are now 14, 16, 24, 32, 64 cores after all.

 

[SomeGuyWithAnOpinion]

Don't like using cmake as well; make is fine for me. Don't rely much on IDE. As few files as possible. Just think and write.

Fucking PREACH!

Nothing makes me cringe harder or abandon contributing to a project faster than seeing them use cmake.

cmake was the biggest mistake made by C programs.

so was gnu autotools

Just use make.

 

[Krice]

One thing that does annoy me in C++ are STL error messages... I think it's quite difficult to decipher them. Also it seems like C++17 stuff that works in MSVC doesn't work in GCC. This following error message was generated by couple lines of code, and this is a real example, sadly:

..\fs_path.h||In member function 'std::filesystem::__cxx11::path& std::filesystem::__cxx11::path::operator/=(const std::filesystem::__cxx11::path&)':|
..\fs_path.h|237|error: no match for 'operator!=' (operand types are 'std::filesystem::__cxx11::path' and 'std::filesystem::__cxx11::path')|
..\postypes.h|221|note: candidate: 'template<class _StateT> bool std::operator!=(const std::fpos<_StateT>&, const std::fpos<_StateT>&)'|
..\postypes.h|221|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::fpos<_StateT>'|
..\stl_pair.h|456|note: candidate: 'template<class _T1, class _T2> constexpr bool std::operator!=(const std::pair<_T1, _T2>&, const std::pair<_T1, _T2>&)'|
..\stl_pair.h|456|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::pair<_T1, _T2>'|
..\stl_iterator.h|311|note: candidate: 'template<class _Iterator> constexpr bool std::operator!=(const std::reverse_iterator<_Iterator>&, const std::reverse_iterator<_Iterator>&)'|
..\stl_iterator.h|311|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::reverse_iterator<_Iterator>'|
..\stl_iterator.h|349|note: candidate: 'template<class _IteratorL, class _IteratorR> constexpr bool std::operator!=(const std::reverse_iterator<_Iterator>&, const std::reverse_iterator<_IteratorR>&)'|
..\stl_iterator.h|349|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::reverse_iterator<_Iterator>'|
..\stl_iterator.h|1124|note: candidate: 'template<class _IteratorL, class _IteratorR> constexpr bool std::operator!=(const std::move_iterator<_IteratorL>&, const std::move_iterator<_IteratorR>&)'|
..\stl_iterator.h|1124|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::move_iterator<_IteratorL>'|
..\stl_iterator.h|1130|note: candidate: 'template<class _Iterator> constexpr bool std::operator!=(const std::move_iterator<_IteratorL>&, const std::move_iterator<_IteratorL>&)'|
..\stl_iterator.h|1130|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::move_iterator<_IteratorL>'|
..\allocator.h|158|note: candidate: 'template<class _T1, class _T2> bool std::operator!=(const std::allocator<_CharT>&, const std::allocator<_T2>&)'|
..\allocator.h|158|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::allocator<_CharT>'|
..\allocator.h|164|note: candidate: 'template<class _Tp> bool std::operator!=(const std::allocator<_CharT>&, const std::allocator<_CharT>&)'|
..\allocator.h|164|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::allocator<_CharT>'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\string_view|454|note: candidate: 'template<class _CharT, class _Traits> constexpr bool std::operator!=(std::basic_string_view<_CharT, _Traits>, std::basic_string_view<_CharT, _Traits>)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\string_view|454|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'std::basic_string_view<_CharT, _Traits>'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\string_view|460|note: candidate: 'template<class _CharT, class _Traits> constexpr bool std::operator!=(std::basic_string_view<_CharT, _Traits>, std::__detail::__idt<std::basic_string_view<_CharT, _Traits> >)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\string_view|460|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'std::basic_string_view<_CharT, _Traits>'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\string_view|466|note: candidate: 'template<class _CharT, class _Traits> constexpr bool std::operator!=(std::__detail::__idt<std::basic_string_view<_CharT, _Traits> >, std::basic_string_view<_CharT, _Traits>)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\string_view|466|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'std::basic_string_view<_CharT, _Traits>'|
..\basic_string.h|6056|note: candidate: 'template<class _CharT, class _Traits, class _Alloc> bool std::operator!=(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)'|
..\basic_string.h|6056|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>'|
..\basic_string.h|6069|note: candidate: 'template<class _CharT, class _Traits, class _Alloc> bool std::operator!=(const _CharT*, const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)'|
..\basic_string.h|6069|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   mismatched types 'const _CharT*' and 'std::filesystem::__cxx11::path'|
..\basic_string.h|6081|note: candidate: 'template<class _CharT, class _Traits, class _Alloc> bool std::operator!=(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, const _CharT*)'|
..\basic_string.h|6081|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|319|note: candidate: 'bool std::operator!=(const std::error_code&, const std::error_code&)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|319|note:   no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::error_code&'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|323|note: candidate: 'bool std::operator!=(const std::error_code&, const std::error_condition&)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|323|note:   no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::error_code&'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|327|note: candidate: 'bool std::operator!=(const std::error_condition&, const std::error_code&)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|327|note:   no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::error_condition&'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|331|note: candidate: 'bool std::operator!=(const std::error_condition&, const std::error_condition&)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\system_error|331|note:   no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::error_condition&'|
..\stl_vector.h|1772|note: candidate: 'template<class _Tp, class _Alloc> bool std::operator!=(const std::vector<_Tp, _Alloc>&, const std::vector<_Tp, _Alloc>&)'|
..\stl_vector.h|1772|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::vector<_Tp, _Alloc>'|
..\streambuf_iterator.h|209|note: candidate: 'template<class _CharT, class _Traits> bool std::operator!=(const std::istreambuf_iterator<_CharT, _Traits>&, const std::istreambuf_iterator<_CharT, _Traits>&)'|
..\streambuf_iterator.h|209|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::istreambuf_iterator<_CharT, _Traits>'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\array|257|note: candidate: 'template<class _Tp, long long unsigned int _Nm> bool std::operator!=(const std::array<_Tp, _Nm>&, const std::array<_Tp, _Nm>&)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\array|257|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::array<_Tp, _Nm>'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\tuple|1439|note: candidate: 'template<class ... _TElements, class ... _UElements> constexpr bool std::operator!=(const std::tuple<_Tps ...>&, const std::tuple<_Elements ...>&)'|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\tuple|1439|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::tuple<_Tps ...>'|
..\unique_ptr.h|706|note: candidate: 'template<class _Tp, class _Dp, class _Up, class _Ep> bool std::operator!=(const std::unique_ptr<_Tp, _Dp>&, const std::unique_ptr<_Up, _Ep>&)'|
..\unique_ptr.h|706|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::unique_ptr<_Tp, _Dp>'|
..\unique_ptr.h|712|note: candidate: 'template<class _Tp, class _Dp> bool std::operator!=(const std::unique_ptr<_Tp, _Dp>&, std::nullptr_t)'|
..\unique_ptr.h|712|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::unique_ptr<_Tp, _Dp>'|
..\unique_ptr.h|717|note: candidate: 'template<class _Tp, class _Dp> bool std::operator!=(std::nullptr_t, const std::unique_ptr<_Tp, _Dp>&)'|
..\unique_ptr.h|717|note:   template argument deduction/substitution failed:|
..\fs_path.h|237|note:   'std::filesystem::__cxx11::path' is not derived from 'const std::unique_ptr<_Tp, _Dp>'|
..\fs_path.h|511|error: specialization of 'std::filesystem::__cxx11::path::__is_encoded_char<wchar_t>' after instantiation|
..\fs_path.h||In function 'decltype (std::filesystem::__cxx11::path(__source, std::locale::classic())) std::filesystem::__cxx11::u8path(const _Source&)':|
..\fs_path.h|589|error: no matching function for call to 'u8path(std::__cxx11::basic_string<char>::const_iterator, std::__cxx11::basic_string<char>::const_iterator)'|
..\fs_path.h|584|note: candidate: 'template<class _Source> decltype (std::filesystem::__cxx11::path(__source, std::locale::classic())) std::filesystem::__cxx11::u8path(const _Source&)'|
..\fs_path.h|584|note:   template argument deduction/substitution failed:|
..\fs_path.h|589|note:   candidate expects 1 argument, 2 provided|
..\fs_path.h||In function 'decltype (std::filesystem::__cxx11::path(__first, __last, std::locale::classic())) std::filesystem::__cxx11::u8path(_InputIterator, _InputIterator)':|
..\fs_path.h|601|error: 'value_type' was not declared in this scope|
..\fs_path.h|601|note: suggested alternative: 'false_type'|
..\fs_path.h|601|error: template argument 1 is invalid|
..\fs_path.h|602|error: 'string_type' was not declared in this scope|
..\fs_path.h|602|note: suggested alternative: 'string_view'|
..\fs_path.h|603|error: '__tmp' was not declared in this scope|
..\fs_path.h|603|note: suggested alternative: 'rmtmp'|
..\fs_path.h||In member function 'int std::filesystem::__cxx11::path::compare(const string_type&) const':|
..\fs_path.h|1014|error: no matching function for call to 'std::filesystem::__cxx11::path::path(const string_type&)'|
..\fs_path.h|402|note: candidate: 'std::filesystem::__cxx11::path::path(std::filesystem::__cxx11::path::string_type, std::filesystem::__cxx11::path::_Type)'|
..\fs_path.h|402|note:   candidate expects 2 arguments, 1 provided|
..\fs_path.h|202|note: candidate: 'template<class _InputIterator, class _Require, class _Require2> std::filesystem::__cxx11::path::path(_InputIterator, _InputIterator, const std::locale&, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|202|note:   template argument deduction/substitution failed:|
..\fs_path.h|1014|note:   candidate expects 4 arguments, 1 provided|
..\fs_path.h|194|note: candidate: 'template<class _Source, class _Require, class _Require2> std::filesystem::__cxx11::path::path(const _Source&, const std::locale&, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|194|note:   template argument deduction/substitution failed:|
..\fs_path.h|1014|note:   candidate expects 3 arguments, 1 provided|
..\fs_path.h|187|note: candidate: 'template<class _InputIterator, class _Require> std::filesystem::__cxx11::path::path(_InputIterator, _InputIterator, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|187|note:   template argument deduction/substitution failed:|
..\fs_path.h|1014|note:   candidate expects 3 arguments, 1 provided|
..\fs_path.h|180|note: candidate: 'template<class _Source, class _Require> std::filesystem::__cxx11::path::path(const _Source&, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|180|note:   template argument deduction/substitution failed:|
..\fs_path.h|174|note: candidate: 'std::filesystem::__cxx11::path::path(std::filesystem::__cxx11::path::string_type&&, std::filesystem::__cxx11::path::format)' <near match>|
..\fs_path.h|174|note:   conversion of argument 1 would be ill-formed:|
..\fs_path.h|1014|error: cannot bind rvalue reference of type 'std::filesystem::__cxx11::path::string_type&&' {aka 'std::__cxx11::basic_string<wchar_t>&&'} to lvalue of type 'const string_type' {aka 'const std::__cxx11::basic_string<wchar_t>'}|
..\fs_path.h|167|note: candidate: 'std::filesystem::__cxx11::path::path(std::filesystem::__cxx11::path&&)'|
..\fs_path.h|167|note:   no known conversion for argument 1 from 'const string_type' {aka 'const std::__cxx11::basic_string<wchar_t>'} to 'std::filesystem::__cxx11::path&&'|
..\fs_path.h|165|note: candidate: 'std::filesystem::__cxx11::path::path(const std::filesystem::__cxx11::path&)'|
..\fs_path.h|165|note:   no known conversion for argument 1 from 'const string_type' {aka 'const std::__cxx11::basic_string<wchar_t>'} to 'const std::filesystem::__cxx11::path&'|
..\fs_path.h|163|note: candidate: 'std::filesystem::__cxx11::path::path()'|
..\fs_path.h|163|note:   candidate expects 0 arguments, 1 provided|
..\fs_path.h||In member function 'int std::filesystem::__cxx11::path::compare(std::basic_string_view<wchar_t>) const':|
..\fs_path.h|1021|error: no matching function for call to 'std::filesystem::__cxx11::path::path(std::basic_string_view<wchar_t>&)'|
..\fs_path.h|402|note: candidate: 'std::filesystem::__cxx11::path::path(std::filesystem::__cxx11::path::string_type, std::filesystem::__cxx11::path::_Type)'|
..\fs_path.h|402|note:   candidate expects 2 arguments, 1 provided|
..\fs_path.h|202|note: candidate: 'template<class _InputIterator, class _Require, class _Require2> std::filesystem::__cxx11::path::path(_InputIterator, _InputIterator, const std::locale&, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|202|note:   template argument deduction/substitution failed:|
..\fs_path.h|1021|note:   candidate expects 4 arguments, 1 provided|
..\fs_path.h|194|note: candidate: 'template<class _Source, class _Require, class _Require2> std::filesystem::__cxx11::path::path(const _Source&, const std::locale&, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|194|note:   template argument deduction/substitution failed:|
..\fs_path.h|1021|note:   candidate expects 3 arguments, 1 provided|
..\fs_path.h|187|note: candidate: 'template<class _InputIterator, class _Require> std::filesystem::__cxx11::path::path(_InputIterator, _InputIterator, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|187|note:   template argument deduction/substitution failed:|
..\fs_path.h|1021|note:   candidate expects 3 arguments, 1 provided|
..\fs_path.h|180|note: candidate: 'template<class _Source, class _Require> std::filesystem::__cxx11::path::path(const _Source&, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|180|note:   template argument deduction/substitution failed:|
..\fs_path.h|174|note: candidate: 'std::filesystem::__cxx11::path::path(std::filesystem::__cxx11::path::string_type&&, std::filesystem::__cxx11::path::format)'|
..\fs_path.h|174|note:   no known conversion for argument 1 from 'std::basic_string_view<wchar_t>' to 'std::filesystem::__cxx11::path::string_type&&' {aka 'std::__cxx11::basic_string<wchar_t>&&'}|
..\fs_path.h|167|note: candidate: 'std::filesystem::__cxx11::path::path(std::filesystem::__cxx11::path&&)'|
..\fs_path.h|167|note:   no known conversion for argument 1 from 'std::basic_string_view<wchar_t>' to 'std::filesystem::__cxx11::path&&'|
..\fs_path.h|165|note: candidate: 'std::filesystem::__cxx11::path::path(const std::filesystem::__cxx11::path&)'|
..\fs_path.h|165|note:   no known conversion for argument 1 from 'std::basic_string_view<wchar_t>' to 'const std::filesystem::__cxx11::path&'|
..\fs_path.h|163|note: candidate: 'std::filesystem::__cxx11::path::path()'|
..\fs_path.h|163|note:   candidate expects 0 arguments, 1 provided|
||=== Build failed: 10 error(s), 0 warning(s) (0 minute(s), 1 second(s)) ===|

 

[Krice]

It seems to be a known bug in GCC 8.1.0 with filesystem. Strange, but then again it's open source...

 

[Not.AI]

C++17 stuff that works in MSVC doesn't work in GCC

There is a lot of this sort of thing in many "large" existing systems : (

 

[Twiglard]

I haven't had compile errors with std::filesystem. Using Clang 15, GCC 12 and MSVC 2022.

But I don't like how std::filesystem::path allocates memory and there's no way around it. Same with how STL doesn't consistently have std::string_view overloads, and std::string itself can't be made into a view.

It's fine perf-wise as filesystem access after init is only done for resource streaming (which is malloc-heavy and takes a lot of cycles on its own), but the distaste remains.

Then there's the sheer size of <filesystem> and <string_view>.

 

[OndrejSc]

 

[SomeGuyWithAnOpinion]

I will reiterate what I said before:

If you're purely choosing a language and a programming style based on speed in CPU cycles, and aren't writing code for an embedded system, you have no place within the industry.

I still stand by my position on cmake being utter garbage after coming across yet ANOTHER open source project which is a major pain in the ass to compile because of it.

If your project needs anything more than "pull these libraries using your package manager, run make", then your project is fundamentally designed wrong.

 

[Vic]

I chose brainfuck.

https://esolangs.org/wiki/Brainfuck

 

[Rincewind]

I will reiterate what I said before:

If you're purely choosing a language and a programming style based on speed in CPU cycles, and aren't writing code for an embedded system, you have no place within the industry.

I still stand by my position on cmake being utter garbage after coming across yet ANOTHER open source project which is a major pain in the ass to compile because of it.

If your project needs anything more than "pull these libraries using your package manager, run make", then your project is fundamentally designed wrong.

Pretty much. Raw performance matters for probably 1% of the total code you write, in general. Well, as a DOSBox Staging maintainer having to put up with C++ (*sigh*), I rarely need to go into super low-level performance optimising mode 90% of the time. And when I have to, it's usually a few tight loops, so it's about a couple of tens of lines of code.

It's not that I don't know how to do it, I used to program in asm back in the 90s. But it's a colossal waste of time these days, it's just so pointless... Algorithmic optimisations get you in the ballpark and pretty close to optimal performance anyway without even going into low-level mode.

Better yet, give me some nice garbage collected environment with an option to control low-level memory access and allocations if I *really* need to. The thing is, for most desktop apps you rarely need to.

cmake is cancer and should be killed with fire. We use meson + ninja, those are quite nice. I'm exactly the same, if git clone plus make or maybe pasting a few lines from the README into the terminal isn't enough, I have to be *extremely* interested in the project to even bother... Life is too short to fuck around with bad build tools.

 

[Rincewind]

Nobody but the most diehard procedural programmer (read: fat "minimalist" neckbeards like the losers over on suckless.org) makes blanket statements about classes and inheritance being inherently bad. At the same time, Inheritance is not a panacea and should be used with exactly the same caution as any other design pattern. I generally find it's overused, and horrendous use of multiple inheritance especially can utterly destroy a codebase, which is exactly why many other languages limit it. Hence, "overrated". People see it as a magic bullet for OO programming and it's really not. It's just another tool. Encapsulation and separation of concerns are FAR more important in my experience, and will do a lot more to make your codebase easy to work with than making everything inherit from something.

You of course get it, but it's a preach to the choir situation. If you've seen the light, you get it immediately what you're talking about, but the less experienced folks need to work a few years or decades in the OOP mines to see the light. Or maybe they'll never see it.

OOP for code reuse is a horrible idea, and folks tend to use it like that. Interface inheritance where it make sense can be ideal, though.

 

[SomeGuyWithAnOpinion]

I will reiterate what I said before:

If you're purely choosing a language and a programming style based on speed in CPU cycles, and aren't writing code for an embedded system, you have no place within the industry.

I still stand by my position on cmake being utter garbage after coming across yet ANOTHER open source project which is a major pain in the ass to compile because of it.

If your project needs anything more than "pull these libraries using your package manager, run make", then your project is fundamentally designed wrong.

Pretty much. Raw performance matters for probably 1% of the total code you write, in general. Well, as a DOSBox Staging maintainer having to put up with C++ (*sigh*), I rarely need to go into super low-level performance optimising mode 90% of the time. And when I have to, it's usually a few tight loops, so it's about a couple of tens of lines of code.

Isn't one of the main big benefits of C++ (other than it being sane compared to average C code) is that things like iterators are FAR more efficient than the C equivalents?

I'm far from a C++ expert, but my understanding is that it allows a lot of optimisation in a generic fashion that just isn't possible with C (or at least has to be rolled manually, it's not part of the library).

C++ gets a lot of (well deserved) hate because there's so much cruft associated with the language, especially stuff from old versions that has to remain "compatible", but arguing the language is slower than C is just plain silly. It's generally the same speed and is provably faster in a significant number of use cases.

I know people whine about C++ and go "but muh vtable", but they are engaging in the same CPU-cycle counting that I hate. If they really hate vtables that much they can just not use inheritance since IIRC C++ doesn't generate vtables at all if you don't have any virtual functions.

It's not that I don't know how to do it, I used to program in asm back in the 90s. But it's a colossal waste of time these days, it's just so pointless... Algorithmic optimisations get you in the ballpark and pretty close to optimal performance anyway without even going into low-level mode.

I have literally seen people complain that "This language is slow, why should anyone use it" and I have looked at their code and they were using a fucking Bubble sort. I kek'd

Better yet, give me some nice garbage collected environment with an option to control low-level memory access and allocations if I *really* need to. The thing is, for most desktop apps you rarely need to.

You mean like C#?

cmake is cancer and should be killed with fire. We use meson + ninja, those are quite nice. I'm exactly the same, if git clone plus make or maybe pasting a few lines from the README into the terminal isn't enough, I have to be *extremely* interested in the project to even bother... Life is too short to fuck around with bad build tools.

Ninja isn't that much better. Neither is Ant or Jenkins or any of that junk. It's all symptomatic of the same problem, complicated and badly designed codebases.

Ninja is far better at hiding that complexity and simplifying it than cmake is (cmake somehow manages to make complex build situations even MORE complicated), but it's still dealing with a lot of complexity, especially if something goes wrong.

Instead, you should focus on making your codebase so simple and manageable that someone can compile it in a pinch without a build tool (even if it gives them a suboptimal result that takes a long time, like g++ *.cpp -o out).

I would say even make is pushing it, the only reason I recommend it is because generating .o files is pretty much the minimum requirement for efficient compilation of any sufficiently large C or C++ project, and it does that brilliantly, and not much else, making it the perfect build tool.

 

[OndrejSc]

Pascal uber alles.

 

[whydoibother]

Which programming language did you choose and why?

PHP-MySQL-JavaScript stack
Because there's many low effort jobs

 

[SomeGuyWithAnOpinion]

Which programming language did you choose and why?

PHP-MySQL-JavaScript stack
Because there's many low effort jobs

If you want low effort, go with Javascript all the way down

JS-based client app connecting to a node server using mongo