Slashdot Mirror

Modules are coming.

For some years now, an ISO/IEC working group, WG23, has been compiling lists of programming language vulnerabilities, both for specific languages and generically. The documents list for the WG is a bit of a mess, with the main link to the current draft getting a 404, but you can find links to sections on individual languages there. Some language committees are actively participating in WG23, but the C++ committee, I am told by another member, refuses to do so.

Microsoft doesnâ(TM)t make a C compiler. VisualC++ is just that a C++ compiler (that just happens to compile some C programs).

Nice try.

But C++ subsumes significant parts of the C language, such as 27.9.2 C library files, on p 1019 of the C++ standard,

Besides, you're fucking WRONG anyway:

C99 Conformance Visual Studio 2015 fully implements the C99 Standard Library

The C Standard added Annex K, Bounds-checking Interfaces in an effort to address this.

Every see all those "sprintf() is deprecated" misleading error messages from Visual Studio? The ones that make you think that functions that are required by the C standard are "deprecated"?

Well, Microsoft on the surface seems to be pushing you to use those "safer" Annex K functions? No, not really. They're pushing you to use Microsoft's bullshit versions. Per the C committee:

Field Experience With Annex K — Bounds Checking Interfaces

...

Microsoft Visual Studio

Microsoft Visual Studio implements an early version of the APIs. However, the implementation is incomplete and conforms neither to C11 nor to the original TR 24731-1. For example, it doesn't provide the set_constraint_handler_s function but instead defines a _invalid_parameter_handler _set_invalid_parameter_handler(_invalid_parameter_handler) function with similar behavior but a slightly different and incompatible signature. It also doesn't define the abort_handler_s and ignore_handler_s functions, the memset_s function (which isn't part of the TR), or the RSIZE_MAX macro.The Microsoft implementation also doesn't treat overlapping source and destination sequences as runtime-constraint violations and instead has undefined behavior in such cases.

As a result of the numerous deviations from the specification the Microsoft implementation cannot be considered conforming or portable.

So, MickeySoft, just STFU about memory problems when you use them as nothing more than an excuse to push your proprietary version of C on the population.

> Most other work is Java and C++, for both a simple editor like vi/vim (even with ctaggs) is completely unsuited. But I guess you hate both such languages :)

Out-of-the-box Crap++ is a complete clusterfuck of over-engineering.

I personally use C++ with ctags -- I will clarify that in a moment.

When even a C++ committee member admits that they write in a sub-set of C++ you know the languages is b-l-o-a-t-e-d.

Myself, like many other game developers, such as John Carmack, use something called "Super C" or "Embedded C++" -- basically C++ without all the bloated features.

* No exceptions
* No RTTI
* No References (use pointers)
* Minimal usage of templates
* Const everywhere
* Shallow Class Heirarchy
* Polymorphism when it makes sense
* Inheritance when it makes sense

CppCon 2014: Nicolas Fleury "C++ in Huge AAA Games"
https://www.youtube.com/watch?...

And when _another_ person on the committee officially recognizes iostreams' performance is crap and hates it: ... and not so much interest in fixing or somehow superseding iostreams which I hate in all its forms. you quickly realize iostreams' slow performance and over-engineered design will never be fixed.

In case you didn't notice those C++ morons are STILL trying to add a 2D graphics library -- which would have been fine 20 years ago -- but everyone is either using Direct3D, OpenGL, Vulkan, or some other proprietary piece-of-shit 3D library. We don't need Yet-Another-Graphics library.

Title: A Proposal to Add 2D Graphics Rendering and Display to C++
Date: 2018-02-1
http://www.open-std.org/jtc1/s...

**facepalm**

There is no _standardized_ name-mangling -- something that would help solve _today's_ real problems.

Gee, when are packages coming to C++? You know, something Pascal had 30 years ago???

I could go on but that's enough.

Java is an even crappier language. I wrote some CRC32 in version 7 2 years ago -- it was one of the worst programming experiences I've ever had.

* It took _eight_ revisions to add support for a native unsigned type???
* Any language that _forces_ only one class per file is brain dead
* The compiler was brain dead -- it was unable to cast an int to a boolean and short-circuit an IF clause
* Let me know when there is a way to make the GC _100% deterministic_ AND give it a _hard_ millisecond deadline, or even disable the dam thing. Ignoring memory management doesn't magically make it go away.
* The extra/long/verbose/path/to/my/source is crap,
* The gradle/maven build system sucks
* Verbose languages, like Java and COBOL, suck.

There is a reason the stereotypical Java-weenie exists.

.

That's exactly the problem that C++ modules is trying to solve. Can't wait for it to make it into the standard.

> The C++ committee isn't "retarded" simply because you don't understand what they do or why. They are experienced and battle hardened.

BZZZT. Thanks for Playing.

1. C++ has become such over-engineered bloated crap that even the committee members themselves admit that they only uses a sub-set of it

2. This is the same committee that officially recognizes iostreams' performance is shit. When a committee member admits "... fixing iostreams which I hate in all its forms." you know something is rotten in Denmark.

3. The C++ committee is so far out of touch with reality that they wanted to add a 2D graphics API Cairo to the language. /sarcasm Gee, if only we had a cross-platform graphics library that has been around for 20+ years. Oh WAIT, we already do -- let's ignore OpenGL and invent Yet-Another-Standard that no one gives a fuck about.

4. When are modules coming again???

5. Bjarne Stroustrup was so far out-of-touch with modern hardware of the L1 cache that he was surprised to learn that doubly linked lists give shitty cache usage.

Here's a nickel kid, buy yourself a clue.

> They know full well that they simply can't drive through a change, because they have no power to ...

It is not fucking rocket science to standardize name mangling per (hardware) platform -- but keep making excuses for your ignorance.

> ... your a retard moran".

Pro-Tip: Only a moron misspells "moran"

Here's another nickel kid -- buy yourself a spelling and grammar checker.

> it needs dependency management

I would argue it first needs modules (PDF) modules (2016 CPPcon), something that Pascal solved 29 years ago

> Multiple versions locally that don't conflict

That would be a god send if it was standardized across platforms: Win, Linux, OSX. Gee, how did *nix solve this problem? :-)

>control over C++ ABI

Agreed. Except the retarded C++ committee doesn't think this is important. Every C++ compiler can call C code generated by ANY compiler but you MUST only call a .lib compiled with the SAME compiler. It is utterly stupid that in 2017 there is STILL no support for an Application Binary Interface.

Right - here's a better resource for that:
http://www.open-std.org/jtc1/s...

It seems that it does have to evaluate to a literal value. One of the benefits of using interpreted language, I guess. Most of what I work with wouldn't benefit much from being compiled.

> Then why aren't we programming everything in assembly?

Half joking, Half serious: Who says we're not?

Aside, because a developer's time costs more then the CPU's time -- THAT is why we use higher level languages. It comes down to price. We trade quality for iteration time. Most businesses can't _afford_ to justify writing in assembly. It is far cheaper to just hire a few recent college grads and have them bang out code in the latest iHipster language. High Level language are good enough.

/sarcasm Who cares how inefficient & bloated the code is we can "solve" the 80% of the problem. Who cares if it takes 4 GB of RAM to run and 2 minutes to startup!? This mentality of apathy "I don't care about the user's experience" is why we have crap like computers being 1,000 time faster but tasks still take longer!

> The world indeed doesn't need another rehash of C++ or Lisp:

Sooo when is C++ going to modules?? You know, something every other modern language has had for, you know, decades. Why do you have to copy/paste a function definition header to forward declare it when the compiler could do this automatically??

When you have idiots on the C++ design committee -- a native binary literal took DECADES to add, "A Proposal to Add 2D Graphics Rendering and Display to C++", etc. I would argue it certainly does. That's why we have D, etc.

Every year C++ piles on more and more crap. It needs a simplification, not more over-engineering.

As someone who has worked on a PS3 C++ compiler there are two jokes amongst compiler writers:

There are 2 things wrong with C++.
1. It's design,
2. It's implementation

C/C++ are slow to evolve. It looks like at least this one proposal to add the various rotation operators to C/C++ has been authored and it has lots of good information. Your working example of "SHL 3 OR SHR 29 = ROL 3" is obvious when you scribble it on paper: a left rotate is a left shift where the bits that get pushed off the left and "discarded" instead appear on the right in the same order they fell off, so the 32-bit number 10000000000000000000000000000000 -> ROL 3 -> 00000000000000000000000000000100. Picture an arrow going from the "fall off" side back around to the "shift in zeroes" side you're used to seeing with the << operator and it makes more sense.

As for how the compiler "just knows" that this specific construct should become a ROL/ROR instruction, it's not that the compiler has a "special IF" statement on the front-end, but rather has to do with how compilers convert source code into object code. When the compiler breaks down our rotation idiom, it sees it as a series of simpler distinct steps with anonymous temporary variables, and a built-in optimizer can recognize the rotation sequence from there. This is what the compiler sees (see three-address code) when it converts the expression '(x > 29)' into its component parts:

t1 := x << 3
t2 := x >> 29
t3 := t1 | t2

Even a simple peephole optimizer can easily spot this short sequence of fundamental operations (left shift + right shift, the shift amounts equal the width of the variable type, ORed together -> ROL) and convert it to something like:

t1 := x ROL 3

...which is extremely simple to convert to assembler as i.e. ROL 3, EAX. One more important thing about rotations: if you rotate by the width of the unsigned integer type you're working with, you'll get the exact same number, and for any integer X of given width W,

X ROL n == X ROR (W - n)

So ROL 3 and ROR 29 are identical operations when performed on a 32-bit wide integer. That's part of why the C idiom works: a shift is a "rotate" that throws away the bits that "fall off" and zeroes the bits that would be missing, so by ORing two exactly opposing shifts together, you are manually grafting the bits that fell off one side back onto the other side.

ISO/IEC JTC1/SC22 has had a group looking at programming language vulnerabilities, including (a) how to define a 'vulnerability'; (b) how to assess languages against those definitions; (c) an assessment of languages (that have de-jure standards) for vulnerabilities, and related work. There is an introduction here http://www.open-std.org/jtc1/s... and the work is documented here: http://grouper.ieee.org/groups...

(Do you suppose the authors of this report are aware of the ISO work?)

> Game programmers often use C++ (for various reasons).

Performance is the #1 of reason, but yeah, C++ gets the right balance of power, compactness, performance, and multi-paradigm design which builds upon C's foundation.

> What do you typically use to write programs?

Just because I'm vocal, and passionate, doesn't mean I toss the baby out with the bath water.

I would be stupid to ignore the wisdom of Bjarne Stroustrup:

There are only two kinds of languages:

* the ones people complain about and
* the ones nobody uses.

To answer your question:

Pragmatic C++. (With some Javascript, since WebGL is my (current) day job)

Which is the balance of the middle ground between basic C and the modern over-engineered clusterfuck of C++. Why do you think there was an "Embedded C++" movement years ago which removed all the Templates, Exception Handling, and RTTI junk? Gee, look, Ubisoft C++ usage does the exact same thing.

To clarify, I use _only_ templates when it makes sense. Most of the time it doesn't. I use #define macro's where it makes sense. Most of the time it doesn't. I don't use Boost because it is over engineered 99% of the time. I uses classes where it makes sense. I use 3rd party libraries only when necessary. I use design patterns only when the model fits - instead of trying to shoehorn the code+data into a broken model.

I've shipped enough games where a full build was 45+ minutes. This is insanity.

Minimal C++ is the mantra. Use the expressive complexity and power of the language when it matters. Most of the time it doesn't.

I just want the insanity of C++ to stop and address the common core issues instead of adding yet-another-flavor-of-the-month concept. Retarded ideas like 2D Graphics Rendering API proposal is the epitome of everything wrong with the committee. Completely out-of-touch with reality and solutions in search of a problem.

When you _even_ have a C++ committee member admitting he writes in a sub-set of C++ himself you know the language has gotten too big. /Oblg. Murphy Computer Law: Inside every large programming language is a smaller one struggling to get out.

*ALL* programming languages suck. Most suck even more.

Want to know someone else who hates C++? Andrei Alexandrescu. *Every* C++ programmer should read until they grok Modern C++ Design: Generic Programming and Design Patterns Applied Guess where he works on now? D (All Things D (programming language) - A Conversation with Andrei Alexandrescu.)

When you even have Scott Meyers at a D Conference (DConf 2014: The Last Thing D Needs (Scott Meyers), you know the language has potential. D has its own problems but I would keep my eye on it. :-)

As bad as C++ is, for my needs it is better then the alternatives.

Neither do you, apparently. C++ (the language, not the library) is the largest programming language in existence. Nothing is larger.

[citation needed]

A clue: there is no citation because you're making it up.

So let's consider languages where actual formal specifications exist because they have to be written in excricuiating detail because the asusmption there is no reference implementation that people can refer to if in doubt.

Java spec (788 pages, for the language only):

https://docs.oracle.com/javase...

C++ spec (425 pages, for the language only):

http://open-std.org/jtc1/sc22/...

C# circa 2006 language specification (553 pages for the language only)

http://www.ecma-international....

So there you go, definitive proof that there are bigger languages than C++.

Huh, looks like ADA and Fortran 2008 have longer specs too.

So there you go, there are 4 standardised languages I've given you which have longer specifications than C++.

The best C++ devs I've managed were those who openly acknowledged the fact that it is too large and too complicated to be used without sticking to a strict subset of some sort.

Given your propensity to simply make shit up about C++ [citation: see above], your statements lack credibility.

Posted says, "needs to manage memory usage and disk access at a very granular level and a desire to be cross-platform". Stdio/stdlib takes care of that. I don't see any mention of GUI, so if GUI is necessary, then I'd say, ya, just use Qt, because it probably is the best and it does come with a lot of other stuff, so you when in Rome...

Boost. What you'll get from boost is the filesystem stuff. It'll be similar in functionality as System.IO.FileInfo System.IO.Directory in .NET, but way more confusing to use. At least at first.

It's funny, the filesystem api was proposed over 9 years ago for c++.

http://www.open-std.org/jtc1/s...

Agreed that CUDA and OpenCL are great secondary and tertiary ways of heterogeneous multi-core programming.

Not sure what your beef again OpenMP is. OpenMP makes it trivial to add multi-threading to your app.

When did C++ get thread control again? Oh yeah, it wasn't until C++11 and you STILL had to wait for compilers to implement it. In the mean-time OpenMP was already here, and working for years. Considering OpenMP has been around for 18 years, calling it a hack when C++ ignored the whole standardization of multi-threading for YEARS is pretty fucking arrogant -- especially when Intel's, Microsoft's and GCC's compilers have natively supported OpenMP for years. What were Windows users supposed to use in the mean-time for portability? A port of pthreads wasn't even available for Win32 until ~2001 if this page is correct.

There are problems with std::future as this committee paper points out:

* N3964 (March 2014)

Even co-routines are still relatively new:

* N4134 (Oct 2014)

C++11 std::thread is great for the future. OpenMP was a perfectly fine solution when C++ didn't even have one back in the day.
 

Agreed that CUDA and OpenCL are great secondary and tertiary ways of heterogeneous multi-core programming.

Not sure what your beef again OpenMP is. OpenMP makes it trivial to add multi-threading to your app.

When did C++ get thread control again? Oh yeah, it wasn't until C++11 and you STILL had to wait for compilers to implement it. In the mean-time OpenMP was already here, and working for years. Considering OpenMP has been around for 18 years, calling it a hack when C++ ignored the whole standardization of multi-threading for YEARS is pretty fucking arrogant -- especially when Intel's, Microsoft's and GCC's compilers have natively supported OpenMP for years. What were Windows users supposed to use in the mean-time for portability? A port of pthreads wasn't even available for Win32 until ~2001 if this page is correct.

There are problems with std::future as this committee paper points out:

* N3964 (March 2014)

Even co-routines are still relatively new:

* N4134 (Oct 2014)

C++11 std::thread is great for the future. OpenMP was a perfectly fine solution when C++ didn't even have one back in the day.
 

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

Surprised they got modules so quickly. Someday modules will eventually make it into C++ ...

* 2006 http://www.open-std.org/jtc1/s...
* 2014 http://www.open-std.org/jtc1/s...
* 2015 http://www.open-std.org/JTC1/S...
* 2015 (April) https://isocpp.org/files/paper...
* http://www.infoq.com/news/2015...
* http://stackoverflow.com/quest...

I see the "use strict" HACK is still optional ("An ECMAScript Script syntactic unit may be processed using either unrestricted or strict mode syntax and semantics. ") but at least in the case of a class is mandatory ("A ClassBody is always strict code.") Someday Javascript will stop being a shitty language. Sadly it won't be this year ... :-/

Surprised they got modules so quickly. Someday modules will eventually make it into C++ ...

* 2006 http://www.open-std.org/jtc1/s...
* 2014 http://www.open-std.org/jtc1/s...
* 2015 http://www.open-std.org/JTC1/S...
* 2015 (April) https://isocpp.org/files/paper...
* http://www.infoq.com/news/2015...
* http://stackoverflow.com/quest...

I see the "use strict" HACK is still optional ("An ECMAScript Script syntactic unit may be processed using either unrestricted or strict mode syntax and semantics. ") but at least in the case of a class is mandatory ("A ClassBody is always strict code.") Someday Javascript will stop being a shitty language. Sadly it won't be this year ... :-/

Surprised they got modules so quickly. Someday modules will eventually make it into C++ ...

* 2006 http://www.open-std.org/jtc1/s...
* 2014 http://www.open-std.org/jtc1/s...
* 2015 http://www.open-std.org/JTC1/S...
* 2015 (April) https://isocpp.org/files/paper...
* http://www.infoq.com/news/2015...
* http://stackoverflow.com/quest...

I see the "use strict" HACK is still optional ("An ECMAScript Script syntactic unit may be processed using either unrestricted or strict mode syntax and semantics. ") but at least in the case of a class is mandatory ("A ClassBody is always strict code.") Someday Javascript will stop being a shitty language. Sadly it won't be this year ... :-/

> But that doesn't mean it is a bad language.

It is when programmers blindly use OOP as a Silver Bullet (TM) and then wonder WTF they run into all sorts of performance problems ...

"Pitfalls of Object Oriented Programming"
* http://research.scee.net/files...

I'm sorry but the C++ committee has their head up their @$$es for *practical* matters:

* Standardized Name Mangling?
* Standardized ABI so compiler A can call code compiled with compiler B
* Standardized error messages
* Standardized pragmas to enable/disable warnings for unused variables
* Standardized forced inline, never inilne
* A consistent grammar between forward declarations and function definitions to make it easier to copy/paste

void foo(); // semi-colon required
void foo(); // semi-colon is error
{
}

* Multi-column debugging instead of the archaic line debugging

foo(); bar(); qaz(); // try setting a breakpoint on bar .. most debuggers only support line debugging?!

Gee, who would ever want that!

Yeah, lets ignore real world issues for the past 20 years and keep adding CRAP onto the language ...

"A Proposal to Add 2D Graphics Rendering and Display to C++"
* http://www.open-std.org/jtc1/s...

For high performance games, most of the C++ features are *ignored*

"CppCon 2014: Nicolas Fleury "C++ in Huge AAA Games"
* https://www.youtube.com/watch?...

Promises and async is indeed a good point. I've been writing async (UI) code in C# for the past two years, and have almost forgotten what a mess it was before tasks and await.

BTW, async/await is also proposed for C++, though it is a much more generalized construct there:

http://www.open-std.org/jtc1/s...

VC++ has a preview of the implementation in the current betas:

http://blogs.msdn.com/b/vcblog...

It seems that threading isn't nearly so simple in C++ either; at least, not if you want to get it right. From https://akrzemi1.wordpress.com... and http://www.open-std.org/jtc1/s... it would seem that while initiating a thread as you've discussed within a C++ program is easy, the nuances of C++ threading are uglier than C pthreads threading. Quotes like these make C++11 threading seem a lot less trivial than your initially impressive example suggests:

"If a thread is cancelled no destructors of automatic objects are called; or at least, it is up to the implementation if they are called or not. This would cause too much resource leaks. Therefore, it is not possible to cancel a thread in C++. There is a similar mechanism though: thread interruption. Interruption is coöperative: to-be-cancelled thread must acknowledge the interruption. If interrupted, a special exception is thrown that unwinds child thread’s stack until it reaches the outermost scope. However, interruption mechanism is not available in C++11 either."

"But all those threads computing fib1 are still running! And as they finish, they will write to all those instances of fib1. Which are no longer there, since the stack has been unwound. In its place will be the stack corresponding to the continuing computation that was initiated when the exception was caught. Thus we now have a large number of threads writing to various locations on the user's stack. By the time the user tries to debug the resulting mess, there is a good chance they will all be gone, leaving him/her with nothing but a stack with mysteriously smashed values. Or those might no longer be visible either because a return address may have been overwritten, causing the main program to take a wild branch."

As I am not well-versed in C++, I'm interested in knowing about these things. Perhaps it will give me a reason to seriously look at the language.

The C++ committee would rather add a 2D graphics API that no one cares about to the language libs then focus on binary compatibility.

You not caring about a standardized 2D graphics API doesn't mean no one cares about it. A standard 2D API will be welcome as part of a larger standard library.

Now, if you really care about a standard ABI for C++, please, feel free to contribute. Here is the proposition from Herb Sutter: http://isocpp.org/files/papers/n4028.pdf

Amusing Note: Herb Sutter supports both the 2D API and C++ ABI propositions. You'll have the occasion to speak about both subjects to him, I guess.

BeOS used C++. Microsoft Windows uses C++ -- albeit with the CRT (C Run Time) library separated.

Linus hates C++ for kernel development because C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling. The C++ committee would rather add a 2D graphics API that no one cares about to the language libs then focus on binary compatibility.

Can any language do unicode right yet?

You can throw away any language that uses UTF-16 right from the start. What's left is C/C++, if you are careful enough.

In fact C (C89/90 to C11) is character-set neutral, and continues to maintain support for EBCDIC for those still stranded without 7-bit ASCII (which is technically superseded by ISO/IEC 646) by providing trigraph (5.2.1.1) and digraph (6.4.6.3) support.

See Section 1 Scope: 2. "This International Standard does not specify / the mechanism by which C programs are transformed for use by a data-processing system" and the definition of 3.6 Byte which is an "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment". So yes Cray, you can even have 12-bit bytes (CDC Cyber).

Kids these days.

Can any language do unicode right yet?

You can throw away any language that uses UTF-16 right from the start. What's left is C/C++, if you are careful enough.

In fact C (C89/90 to C11) is character-set neutral, and continues to maintain support for EBCDIC for those still stranded without 7-bit ASCII (which is technically superseded by ISO/IEC 646) by providing trigraph (5.2.1.1) and digraph (6.4.6.3) support.

See Section 1 Scope: 2. "This International Standard does not specify / the mechanism by which C programs are transformed for use by a data-processing system" and the definition of 3.6 Byte which is an "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment". So yes Cray, you can even have 12-bit bytes (CDC Cyber).

Kids these days.

void main(int argc, char *argv[])

valid C

Nope. Not valid C. Valid would be int main(void), int main(int argc, char **argv)(and equivalent), and in some cases int main(int argc, char **argv, char **envp) (and equivalent).
Source

I wonder about this. Sure a C++ parser is monumentally harder to write than a C parser, no questions. However, writing a C/C++ (one of the few time I believe this combo is justified) worth a damn is far, far harder than writing even a C++ front end. The optimizer on the best compilers is vast amounts of deep magic.

Well, I'd much rather write a C backend than a C++ frontend. Look how long the specification is, and it is full of ambiguities (some of them purposeful!). It would take me a long time to write a compiler I felt confident matched the specification, whereas C is small enough I think I could write a good compiler in a reasonable timeframe.

There used to be a special version of the STL for games, EASTL which had a different implementation optimised for memory mainly.

So there's no reason not to use the STL, or a STL.

Spot on! That's one of the things I've noticed as I get older.

* Less reliance on libraries / frameworks.
* Simpler data
* Simpler code

> serves 100kb of files but somehow manages to take up 300mbytes of disk space and 600mbytes of ram...

God that is so funny it hurts because it is so true!! I blame that on a few things ...

* Programmers who started on 8-bit CPUs are the last "good" breed of programmers IMHO who know how to manage TINSTAAFL. These days every 21-day programmers take Virtual Memory for granted, don't understand the speed hit of abstraction, don't understand "null rendering", "null IO", budgets such as run-time & memory, etc.
* C++, Java, and other "bloated" languages that tend to encourage to make _excessive_ use of libraries. While they make it trivial to get something up and running (good) also has a high memory overhead (bad).
* Badly designed & bloated data formats like XML instead of something simple like JSON
* Poor algorithm choice. C++ STL' & Boost vector are great except when it is not. No one cares that it chews up MB of RAM. Well except the console guys. See this excellent white paper:

"EASTL -- Electronic Arts Standard Template Library"
* http://www.open-std.org/jtc1/s...

The bigger problem is the (almost) no one cares about taking pride in being a _excellent_ programmer.

* Don't use more resources then necessary
* Know the difference if your app is CPU, IO, or Memory bound.

The other problem is due to management. They want something that worked last week, but are not willing to invest the time into doing it right. Like Murphy's Law says

"There is never time to do it right,
but there is always time to do it over!
  -- Murphy's Computer Laws

--
Only cowards censor.

int array[32];
and
int* blah = &(array[0]);
will both point to the exact same element in memory.

``array'' doesn't point anywhere, it's an object in memory of size (32*sizeof (int)) and of type int[32]. [yes, C does have objects.]
``blah'' is another object, of size (sizeof (int*)) and of type int*
 
Obviously these two things are not remotely "the same" (this was the original claim(*)).

With this out of the way:

If you do an equivalence operator on them, they'll be equal.

In fact (array == blah) will be true in this case, but this is only because there is syntactic sugar involved, and the actual comparison done is (&array[0] == blah).

*(int*)((int)blah+(3*sizeof(int)))

No, this is utter gibberish, and even if some implementation choses to compile it, there would be undefined behaviour. (Protip: you cannot cast pointer types to integer types, and no don't argue that your implementation allows it, or that "heey, pointers are just integers to on the metal" (protip-inside-protip: there is no metal in the C Abstract Machine) If you go that route, you only demonstrate that you have no idea what C is)

(*) Some more reasons for why 'arrays and pointers are the same' is grossly wrong in C:

1. ``but i can assign an array to a pointer!'' -- try assigning a pointer to an array.
2. in fact, try assigning an array /at all/ (no, initialization is not assignment)
3. an array can hold multiple elements, a pointer can hold a memory address
4. in expression context, the array "value" is a pointer to its first element -- if both were the same, that rule would be fairly meaningless.
5. ...

Maybe you should read stuff from people who actually program:

http://www.utf8everywhere.org/

Here is some actual comments from boost developers:

http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/recommendations_and_myths.html

Here is an actual proposal to fix filenames on Windows by translating from UTF-8 (filenames on Windows are the *only* reason people use UTF-16, and Microsoft's refusal to allow the a api to handle UTF-8):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html

Long discussion with many points of view (including yours) but I hope this convinces you that there is disagreement with you:

http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful

Here is somebody trying to patch boost to handle unicode by supporting UTF-8:

http://sourceforge.net/p/tinyxml/patches/54/

OK, I give up. The fact that you still think that using a string as a vector of bytes is comparable with a class that is capable of understanding the text it stores, with some encoding conversion capabilities, and more, should be a clear enough indication that we don't have the same expectations on what is a class for human text. And the fact that you still try to put words in my mouth signals that it isn't worth wasting time with you.

Luckily enough that people admit that you should use a Unicode library, because even C++11 supports Unicode terribly, and there is work underway to improve it. Meanwhile, I'm happy to have QString. And I'll be happier if with Qt6 there is a type that can replace it.

That "proposed standard" is very very bad. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3572.html

It does not support decoding UTF-8 in an error-preserving way, and appears to also remove the ability to default character strings to UTF-8.

These are complete job-stopping bugs. Though if the intention was to try to save all the misguided investment in "wide characters" by making it as hard as possible to use UTF-8, it is a good attempt, and I suspect that is the underlying reason for this.

Supported or not, <regex> may yield surprising results when used with UTF-8 or other Unicode text, so those may require a non-<regex> library or the proposed <unicode> header for C++14 anyway.

If it were just up to the order of evaluation of the function arguments, then it would be unspecified. However, the program also modifies the same object twice without an intervening sequence point, and that puts it into undefined behavior territory (6.5/2, C99 draft standard).

Wrong. Only signed overflow and underflow are undefined. Unsigned arithmetic is, indeed, defined as modular. From ISO/IEC9899:TC3:

A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

Where are static_if (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf) and modules (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)?

*These* are the things that will really make C++ a better language and I can't wait to use them.
C++14 seems to be a very minor update. :(

Where are static_if (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf) and modules (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)?

*These* are the things that will really make C++ a better language and I can't wait to use them.
C++14 seems to be a very minor update. :(

Funnily enough you never hear the same complaints about Java. Fun fact, excluding libraries and the JVM, the latest java language spec is now slightly longer than the latest C++ spec.

Bullshit. Java 7 language spec, 642 pages. C++ latest working draft, 1320 pages. Not even close.

> I don't see the point of not using STL.

Code bloat, hard to debug, memory fragmentation, and no way to serialize/deserialize in a fast way.

I highly recommend ALL C++ programmers to read this doc on why EA designed and implemented their own STL version. It provides insight into the type of problems console game developers have face that the PC game developers just routinely ignore or are ignorant of.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

That letter *completely* misses the point Linus was making.

* C _forces_ a programmer to _always_ be thinking about efficiency.

* C++ _allows_ programmers to be _sloppy_ and not even bother to _think_ about efficiency.

When you have idiots calling a virtual function inside an inner loop because they don't know how a virtual function is _implemented_ that is PRECISELY the type of programmer Linus says is a crap programmer because they have never learnt the 0th rule of programming: TINSTAAFL

There Is No Such Things As A Free Lunch

Yes, C can be tedious, but it encourages a certain mindset. The GREAT programmer is always thinking about the high level theory AND the low level implementation. That is a more _balanced_ programmer then one who doesn't understand how to write atoi() and itoa() (aka printf) which is the typical C++ programmer.

The STL is a great example of the "rebuttal" completely ignorant of real-world needs.

The API _design_ of the STL is great because it is orthogonal and consistent. However STL is total crap when you need to :

- debug a container
- serialize and unserialize it in a FAST and PORTABLE manner

Part of the problem is that C++ compilers are crap and put out verbose messages because they can't output a simple, short type alias.
When you have tools like "An STL Error Message Decryptor for C++" you know your language _design_ AND _implementation_ is FUCKED. Sadly the C++ community doesn't have the balls to be honest and admit their ego is out of control. "OK, We screwed up in certain areas of the language. How could we simply the grammar and language for people _using_ the language AND people _implementing_ the language?"
http://www.bdsoft.com/tools/stlfilt.html

_That_ is why Linus says STL is crap. Programmers start using C++ features without thinking about the _consequences_. A hard-core C programmer will go "OK, this looks like a great design -- where are the areas where it excels in, and where are the areas where it sucks in?" In C you are locked into someone else's bad design.

To prove my point: WHY do you think EA (Electronic Arts) invented their OWN version of STL for game programming? Because the standard C++ STL has several KEY DESIGN FLAWS. Ignoring them doesn't make it go away!
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

C++11 _finally_ got Move Semantics. Gee, we've only had to deal with _that_ problem for the past 20 years. Typical over-engineer design-by-committee C++ ignoring real-world (performance) problems.

In closing, there are 2 points I'd like to make:

The *best* programmer is one who balances the simplicity of C with the features of C++; on that I agree that Linus is incorrect. Sadly you can't disable all the crap in C++. Linus' only _pragmatic_ solution was to ban the language outright. His project, his call.

and

The author(s) of the rebuttal need to put up or shut up -- when they have shipped their own kernel THEN they will have earned the right to disagree with Linus.

Hope this provides a little more insight into why C and C++ both suck. ;-/