Slashdot Mirror

FAQs:

"Q: Why is the standard hard to read? I'm having trouble learning C++ from reading it.

"The standard is not intended to teach how to use C++. Rather, it is an international treaty -- a formal, legal, and sometimes mind-numbingly detailed technical document intended primarily for people writing C++ compilers and standard library implementations.

"Fortunately, there are lots of good books that do teach how to use C++! See these recommendations as a starting point for high-quality tutorial and reference information about how to learn and use C++."

Free book about C++ (PDF file): A Tour of C++ by Bjarne Stroustrup.

I doubt the problems are solved by that book. But I haven't yet investigated.

FAQs:

"Q: Why is the standard hard to read? I'm having trouble learning C++ from reading it.

"The standard is not intended to teach how to use C++. Rather, it is an international treaty -- a formal, legal, and sometimes mind-numbingly detailed technical document intended primarily for people writing C++ compilers and standard library implementations.

"Fortunately, there are lots of good books that do teach how to use C++! See these recommendations as a starting point for high-quality tutorial and reference information about how to learn and use C++."

Free book about C++ (PDF file): A Tour of C++ by Bjarne Stroustrup.

I doubt the problems are solved by that book. But I haven't yet investigated.

I admit it, C++ didn't have a design process.

What do you call this?

Are you also going to admit that you have no working knowledge of C++?

> You are not an opponent, you are nobody.

Yet you seem to be compelled to reply to me. I find that funny.

> You fucked up by spouting off about 9 bits and you haven't been able to recover.

You're under the mistaken impression I'm loosing this debate. You're also mistaken that my argument depends on 9-bit bytes existing.

> The Texas Instruments engineers are bright people, who are not part of this conversation.

But their work is. And they have a product where a byte is not 8 bits.

> They did not utilize 9 bit bytes

Read my previous post again, I never said TI used a 9-bit byte. I said they used a 16-bit byte. So if your statement of "There are 8 bits in a byte, period." is correct then the bright Texas Instrument engineers must be wrong for saying their product uses a 16-bit byte.

> nor did anyone else for that matter.

Multics

https://en.wikipedia.org/wiki/... - "The standard C programming language requires that the size of the char data type be at least 8 bits,[3] and that all data types other than bitfields have a size that is a multiple of the character size,[4] so standard C implementations on 36-bit machines would typically use 9-bit chars, although 12-bit, 18-bit, or 36-bit would also satisfy the requirements of the standard."

https://isocpp.org/wiki/faq/in... - "The C++ language guarantees that a char* (char pointers) can address individual bytes." and "Another valid approach would be to define a “byte” as 9 bits"

http://multicians.org/pg/mvm.h... - "To get 64K (256KB, using 9-bit bytes"

> In the future, feel free to sling your garbage as it pertains to any real byte implementation.

I just gave you an example where a byte was not 8 bits but you chose to reply right away with insults instead of actually reading what I wrote about a product that uses 16-bit bytes.

Even if an architecture that used a 9-bit byte never existed it doesn't matter. My argument was that a byte is not always 8-bits. The 16-bit byte DSP I mentioned proved that I was correct.

I'm pretty sure he did, but you knew that and just wanted to try score a cheap +funny.

Here's an explanation of the problem (this was the 2nd link on google search for "std::vector<bool>"; the top link was to cppreference):
On vector<bool>.

Microsoft controls the MSVC compiler which is one of the C++ implementations, and this gives microsoft a seat at the table: https://isocpp.org/std/the-com...

Only because C++ has multiple compiler vendors it does not mean that the vendors do not try to do evil stuff with the control they have over the compilers, and therefore over the users. The usual suspect here is always Microsoft.

You may not be locked in into a particular compiler vendor, but as the std is very small you either use the unofficial extensions (and get locked in).

You know generally I share your attitude that you have to distrust single companies (this attitude is really healty!), but in the case of c++ the development is really impaired thanks to each vendor trying to become market leader, they focus more at fighting each other than trying to improve the actual language.

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 ... :-/

Plenty. All of your criteria have little to do with the language and much more to do with the developer. Any properly defined/debugged program is "safe". Any properly optimized program is "performant". "Clear" is just about source code, which means that it's entirely up to the developer.

ISO 9899:2011.
ISO 14882:2014E.
ECMA 334.

Swift is a "lookalike" to all of these in several ways, especially as that list goes on. The list of languages that aren't ancestral to Swift but that have standards could go on for quite a while longer.

What has all that got to do with how one compiler (or script engine) can link or call methods in a binary produced by a different compiler?

If you just mandated a standard name mangling you'd be 80% of the way there - the remaining bits are types, and typically you're not going to get far unless you define a subset of all possible types, probably using C types with struct and class layouts defined.

Nobody is suggesting we compile a binary for one platform and be able to run it on another - no x86 PE is going to be usable on a x86 ELF for example.

Anyway: some reading for you

Here's a link I found that gives approximate timelines to various features. Nothing is set in stone of course, because it's difficult to predict what sort of issues may come up that would prevent timely adoption. The committee has a tendency to just drop a particular proposal rather than letting it slow down the whole process.

If you're referring to cairo, it's not a standard yet, but the API is being seriously considered for inclusion into the next version of the ISO C++ standard:

http://isocpp.org/files/papers...
http://developers.slashdot.org...

Aside from that, consolidating around a single library means that effort can be focused on that library with any improvements benefiting all applications which use it.

These just came out, so I haven't read them, but you can't go wrong with these authors:
A Tour of C++ by Bjarne Stroustrup (the original creator of C++)
Effective Modern C++ by Scott Meyers

Dr Dobbs journal is always good.
Microsoft's Channel 9 has a lot of good talks like these and these.
The ISO C++ committee has a great website.

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.

In the WG21 meeting, the networking technical specification group voted to adopt Boost.ASIO as a starting point.

They have been working on low-level details, so this is a surprising turn-around and it is wonderful news.

I'm not sure if it will make it into C++17, but my fingers are crossed.

Do you think that one thing holding C++ back is the lack of a standarized binary interface?

[...]

I think an ABI for C++ would increase its "real world" attractiveness considerably with little, if any, overhead.[...]

ABI is the visible barrier that everyone sees, and thus, the apparent problem that everyone believes needs solving.

But the truth is that there are others.

Allocators, for one: If your two different libraries link to different runtimes, memory allocation and deallocation cannot cross library boundaries. In fact, you would have the same problem with all global variables (like the console I/O). In the end, I guess, in addition to the ABI, an unique runtime for each OS.

Then, you would need to make sure compatibility would be respected, both forward and backward. Because if not, then your two libraries compiled with different versions of the runtime would not even correctly start.

You should read Herb Sutter's proposition for more information on the subject:

https://isocpp.org/blog/2014/05/n4028

They're already working on modules (see 'SG2'):

http://isocpp.org/files/img/wg21-structure.png

My last post was a bit sparse on details but I'll try and improve upon it here. The main point I was trying to make was that just because you define a function as constexpr doesn't mean it will run at compile time unless certain conditions are met. This obviously isn't a bad thing as you can re-use the function at runtime.
 
If you have a constexpr function and all of its arguments are constant expressions (such as literals) and it is used in a constant expression (switch case label, array size, non-type template parameter, etc...) or to initialize a constexpr variable then it is guaranteed to run at compile time according to the standard. Otherwise it is up to the compiler. I've noticed a lot of people think that merely passing constant expressions to a constexpr function is enough to guarantee compile time evaluation, but it's not. For instance:

constexpr int factorial(int n) { return n <= 1 ? 1 : (n*factorial(n-1)); }

int main() {
      char c[factorial(5)]; // Compile time
      switch(n) {
            case factorial(3): // Compile time
            break; }
      constexpr int i = factorial(4); // Compile time
      cout << factorial(8) << endl; // *Compile time or runtime*
      int i;
      cin >> i;
      int j = factorial(i); // Obviously runtime
}

Here is a page that talks about it (especially in the comments). I was also mistaken about clang and gcc. At higher optimization levels the factorial of 8 will be computed at compile time rather than runtime.