next »

[oahda]

Can you elaborate?

[Daid]

Can you elaborate?

Did a bit of searching, for starters, they are not standard yet. Part of C++20 most likely.

It seems to put a lot of limits on what you can do, which on one hand is good. On the other hand, those limits remove some things that are really part of a core workflow for quite some people. Most noticable, no macros/defines (that you expose), no circular dependencies. The more I read about it, it feels like static libraries with pre-processed header files...

[Crimsontide]

There's a few main issues (AFAIK... I didn't pull out the standard and triple check everything, but I did read a number of sites that I felt were quite reliable and knowledgeable).

1st is no proper namespace 'renaming'.  The biggest issue right now with headers (at least IMO) is that everything gets dumped in the global namespace whether you want it to or not (Win32 API, for example, being a massive headache because of its header).  So its up to the library author to decide how to set up a namespace (usually just 1 large one for a library and forget about it).  The exporting of a public interface is nice, but still doesn't stop namespace clashes.  A proper module system would allow you to import all the names of a module into a new namespace.  For example something like:

Code:

import my_lib as my_lib_namespace;        // one example of a syntax they could use
import std.iostream using namespace std;  // another example of a syntax they could use, it really doesn't matter the syntax
import Vulkan.Graphics using gfx;         // yet another possibility

This feature just seems like a no-brainer and without it IMO there seems to be little reason to use them.  I mean sure we avoid macros polluting the macro 'namespace' but that leads to issue number 2...

2nd there is no way to pass compile information 'up' to modules.  Many libraries use macros to add/remove/alter features at compilation time.  The use of non-standard extensions, intrinsics, assembly, instruction sets, etc... can no longer easily be controlled by a library user.  Now macros were a mess, fragile and error prone, but we need a way to pass constant arguments through an import to a library 'instance' in such a way as to allow conditional compilation.  This, admittedly, isn't as easy as issue #1 to solve, but if we want modules to replace headers and we want macros to go away for the most part (which I do), we need a way to replace this functionality.

3rd is that sub modules are difficult from a maintenance point of view.  Headers were often seen as annoying to maintain (I personally never felt this way but many other programmers apparently do) with the need to ensure that header contents are consistent with the library contents.  This 'ease of maintenance' was touted as an important feature of modules over headers.  And yet sub modules are a mess and require (at least IMHO) even more effort to ensure consistency.

4th the addition of even more convoluted lawyer-esque concepts that affect all corners of the language with the addition of 'visable' and 'reachable'.  Like in good-old C++ fashion these two concepts are defined by a whole list of caveat's and 'quid pro quos' requiring far too much time scouring the deep corners of the standard to properly grok.

5th... apparently as they are specified they'll actually lead to longer compilation times under many scenarios (https://vector-of-bool.github.io/2019/01/27/modules-doa.html).

 

[ProgramGamer]

Sounds like we need a new language.

[Crimsontide]

Sounds like we need a new language.

LOL yeah...  I've been working on my own over the years; but it'll still be a while before its at the point where I would want to use it in place of C++ or something else.  I don't think most people would like it though.  I find when discussing things on forums, few people (even fellow programmers) approach problems the way I do.  The arguments for or against languages seem to center are silly/nonsensical issues, nullptrs, object vs data orientate design, compilation speed.  We should be focusing (IMHO) on issues like dependency analysis and handling, object and systems relationships, state management, and usability.

As far as alternatives to C++, the D programming language is pretty good, most of what is good about C++ without much of the nonsense.  I'm also impressed with Rust, its more like a true successor to C.

[oahda]

And this mess is the official spec, it's not just Microsoft rolling their own thing with VS before it's properly out? ):

Rust does seem really cool, but not yet where it can replace my whole pipeline ATM either. Maybe in the future.

[qMopey]

As long as there is a great visual debugger with a GUI (would need to run on Linux and Windows at a minimum to be viable for games) and a non-visual API as well (cross-platform), no garbage collection, no significant performance difference from C, no package system, and no OOP nonsense or RAII nonsense, and the ability to call into pre-built C code (and vis-versa) without a significant performance hit, then I'd be interested in the language.

Problem with language designers is they keep adding in "features" to "automate" things, when really all that junk just gets in the way. C is lacking in a few things, especially operator overloading, so this creates room for an alternative. But that doesn't mean pile on other methodologies onto the language just to make it different.

[Crimsontide]

And this mess is the official spec, it's not just Microsoft rolling their own thing with VS before it's properly out? ):

Its preliminary spec stuff, I didn't even get to the MS specific stuff.  I got through the standard nonsense and said 'f-this I'm out!'...  They keep making the same mistakes over and over again, at some point I'm left wondering if its intentional or if the committee is just dysfunctional.

[ProgramGamer]

I've messed with D a bit and I have to say it's a strong contender to C++. It gets rid of a bunch of the dumb things about C++ while adding sorely lacking features, like compile time execution, reflection, and optional garbage collection. You can even do incremental migrations of code with it since it interoperates with C and C++.

[qMopey]

I've messed with D a bit and I have to say it's a strong contender to C++. It gets rid of a bunch of the dumb things about C++ while adding sorely lacking features, like compile time execution, reflection, and optional garbage collection. You can even do incremental migrations of code with it since it interoperates with C and C++.

But does it have classes, constructors, or in general encourage OOP? These are deal-breakers for me personally. I don't know much about D yet

[ProgramGamer]

Not to be that guy, but why would optional features be a deal breaker for you?

Edit: For the record, I just checked and D does allow java style classes with constructors and all that jazz, but again it's all optional anyway.

[Crimsontide]

D is very much like C++, classes, RAII, all the bells and whistles and then some.  It just doesn't have all the backwards compatibility nonsense, and generally just makes more sense.  So if you don't like C++, D is not going to interest you either.

TBH from the sounds of it QMopey likes C and only C and nothing else.  Which is fine, but I don't think you'll ever see a language that'll out-C C, since its been around for so long, and is pretty much ubiquitous.

[Daid]

Yeah, qMopey sounds like the incarnation of this topics title.

Anyhow, the C++ modules, what do they provide over "just putting all code in the header file", like the https://github.com/nothings/stb, I think very little.

[InfiniteStateMachine]

And this mess is the official spec, it's not just Microsoft rolling their own thing with VS before it's properly out? ):

Its preliminary spec stuff, I didn't even get to the MS specific stuff.  I got through the standard nonsense and said 'f-this I'm out!'...  They keep making the same mistakes over and over again, at some point I'm left wondering if its intentional or if the committee is just dysfunctional.

I do recall Andrei Alexandrescu answering questions in the form of  "well you should use D but if you have to use c++.."

Also Bartoz Miliweski constantly praising haskell.

[qMopey]

Not to be that guy, but why would optional features be a deal breaker for you?

Optional features are the bane of C++! Every complaint of C++ is all the optional features. Why is this the complaint? Because people use them, and in practice they lead to many problems.

The optional features must be cut from the language, because if they exist then people will use them to cause problems. The nature of people will never change, so it is up to mechanisms to ensure desireable outcomes. Mechanisms, like a lack of features which resolve to problematic practice.

Here is a contrived example: Say we run a school for childen. We propose to place a sharp knife in every single room, easily accessible. The idea is that if the teacher ever needs to use a knife, for example to open a box of supplies, it's always in easy access. However, we say "the knife is optional for the teacher (they choose when to use it or not), and children should not use it without adult supervision". Obviously, in practice, children will play with the knife and endanger themselves one way or another. We judge this proposal negatively since it will obviously cause problems in practice. However, in an idealized scenario the knife proposal could be a net-win, where there are no downsides. We don't live in an ideal scenario. We live in reality, and C++ is made many optional with knives.

And so we should judge language features not by the utility they might provide, but instead how they play out in common practice. We assume human nature will play out as it always does in reality, and assume human nature will never change, and instead design around human nature as a design constraint. This is the only way a language can succeed.

The potential utility of a feature should only matter as the driving motivation for consideration, like a hint or indicator of potential merit. Merit of the feature itself must be determined through rigorous trial and error, and with the guiding hand of utmost competence.

TBH from the sounds of it QMopey likes C and only C and nothing else.  Which is fine, but I don't think you'll ever see a language that'll out-C C, since its been around for so long, and is pretty much ubiquitous.

I certainly do admire C, but I only use C++. C is lacking basic features like operator overloading. In my opinion, C is not a good choice for modern development as the lack of operator overloading alone is a killer. I personally think another language needs to come along with just the right features, but no more, and it can easily supercede both C and C++ with a superior design.

C is lacking.

C++ lacks foresight.

A replacement can fix both simultaneously. I just personally do not think a replacement can look similar to other contemporary languages and expect a different outcome. All OOP languages with constructors, destruction, RAII, or other nonsense have all failed. It is silly to expect anything similar would fair better. If you want to design a language and have it really succeed it must be different enough to demand its own existence. It should consume the minimal subset of language features which decades have proven useful (all of C's features), and add on the bare minimum to achieve the next exaltation.

Learn from the past successes and avoid contemporary failures.

[qMopey]

In this way D, Rust, and all the other contemporary languages have failed. They fail to provide what people care about, and so they are not popular.

[Daid]

  "Optional features are the reason C++ sucks... except for operator overloading. That I like." - qMopey

[Crimsontide]

I agree that C++ is very not-orthonormal.  And I do agree with the sentiment that optional features are often poorly thought out/integrated with the excuse of 'don't use em if you don't need them' (perfect forwarding, universal initializer syntax, and noexcept being perfect examples); which I think it a poor excuse.  But I would'nt go so far as to call C++, D, or Rust failures.

I'm not sure as to why the fixation on operator overloading.  Its a nice feature but in the end its really only 'syntactic sugar'; and there's almost no use for operator overloading without some form of RAII.  Not to be argumentative but you're choice of features you dislike vs the ones you like, seem to be contradictory IMHO.

[buto]

I know - this topic is all about being grumpy... but actually I have to say that I really like C++! Even modern C++ (i.e. 17). It allows to write expressive, fast (if you know what you're doing), pretty safe code (with respect to memory managment and variable initialization). The only issue I have is with compile times in large projects. C compilers are really crazy fast in this aspect.

What are your experiences with Go? Isn't Go more similar to C?

A little off topic - so sorry for that!

[qMopey]

Operator overloading for math and POD types. Nothing else, especially not constructors or destructors! Sometimes syntactic sugar is extremely necessary. Also I didn’t mean to imply C++ was a failure, but definitely meant Rust and D. I have given C an earnest try for gamedev, but it makes math simply too difficult and verbose. Using math operators is too important to stick with C over C++. And for the record I do think lambdas were a great feature. Writing asynchronous or callback heavy code in C is simply too verbose. The ability to localize a function definition within another function is too important.

Go is pretty cool, but I think way too restrictive. You have to have your code in specific folders, and have to format the text a certain way. I think these are totalitarian and make the language inferior to C++. You must have an internet connection to use the go package manager, you have to use their garbage collection. I also think the go creators do not respect dependency cost. Hello world exe is like 2MB. To me go was the closest to superseding C I’ve ever seen, but still not that close. As a language designer there is a lot to learn from go.

I have found that poor engineers still manage to write terrible go code, despite all the restrictions. However when compar d with C, these go programmers actually feel like they’ve written great code because it “conforms to go standards”. At least in C what is defined as good code is community driven. With go I think the design encourages bad code to hide behind the “go style”, giving poor engineers a veil of undeserved ephemeral confidence.