Slashdot Mirror
ISO C++ Committee Approves C++0x Final Draft
Randyll writes "On the 25th, in Madrid, Spain, the ISO C++ committee approved a Final Draft International Standard (FDIS) for the C++ programming language. This means that the proposed changes to the new standard so far known as C++0x are now final. The finalization of the standard itself, i.e. updating the working draft and transmitting the final draft to ITTF, is due to be completed during the summer, after which the standard is going to be published, to be known as C++ 2011. With the previous ISO C++ standard dating back to 2003 and C++0x having been for over eight years in development, the implementation of the standard is already well underway in the GCC and Visual C++ compilers. Bjarne Stroustrup, the creator of C++, maintains a handy FAQ of the new standard."
Enough said!
-Chris
Given that C++ is to C as cancer is to lung. Does this new standard constitute an advanced and terminal stage?
My collection of C++ books from Addison Wesley (who has apparently cornered the market for C++ books above intro level) has just become obsolete. Most likely new editions for most of them will be coming out over the next couple years.
C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.
...faints...
I've been reading about C++0x for years now, and never realized that the 0x referred to a new revision of C++ to be released in 200X, until I just now saw the FAQ entry about C++1x. I assumed it was some odd inside reference to hex number prefix that I just didn't get. I thought the Y2K bug incident had purged everyone who didn't use full dates :)
C++ is bad, not easy to program and inferiour to C#, Java and of course Python.
Ref: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00219.html
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Nothing comes close to C++ in terms of versatility, features, speed and overall professional appeal.
...it's not dead yet!
What a pity. So many interesting modern languages to choose from and still people are working on this mismatched fossil.
My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
TL;DNR
C++ was one of those languages that needed to come about if only for the industry to see, out of all of the "great ideas" what would work and wouldn't in practice.
C++ continues to mushroom, becoming ever more cumbersome. In the mean time, simpler (and arguably better) languages have come (and gone).
It's time to move on.
Stick Men
http://www-users.cs.york.ac.uk/susan/joke/cpp.htm
This one still makes me laugh
moi
Borland has also had support for parts of the C++0x spec for some time now.
Given all the negative comments about the complexity and misfeatures of C++, I one day decided to take a good look at D programming language.
I know Ruby, Python and Common Lisp, and as I have used Ruby's NArray and NumPy quite much, I appreciate that D language has first class Array objects and vector operations for arrays built into the language. D is also compatible with C and has two-way bridge for Objective-C. The version 2 also supports functional programming.
Overall, D seems to have taken good influences from dynamic programming languages like Ruby and Python.
I wonder why D isn't more popular? Maybe the division of the standard libraries is a big factor?
PS. I have been looking a similar library to NumPy for Common Lisp, but GSLL just doesn't cut it and Matlisp only handles two-dimensional matrices. Of course you can use map, but iterating even slices of two-dimensional matrices with map can be a hassle and is much more verbose than having a good iterator abstraction.
The way you put that, the uneducated reader may have mistaken it for a compliment.
Yes, you hate C++. We get it. Instead of complaining about it so much, just don't use it, stick to your own favorite language, whatever it may be, and leave C++ alone. There are plenty of us who love C++ and wouldn't give it up for anything. We mind our own business, write great code, and try to avoid complaining about whatever it is you are using. Please try to do the same.
We need to be able to write &T::T, just like we can do &T::somemethod and finally build dependency injection in C++.
As someone who spends all day developing a C++ library for massively parallel engineering simulation.... I'm really excited about this announcement. My team has played with some of the early C++0x features in Intel's compiler and GCC and we're definitely going to be adopting a few of them, but can't commit ourselves until they are a bit more universally available.... which now, they hopefully will be.
C++ certainly still has it's strong points over many other languages... especially when you need that cross section of good OO design and performance (like we do). There are many things I love using Python for but there a also a TON of times I need complete control over everything in order to get the most out of the machine I'm using.
enemies? none of what's presented is the least bit accurate. not even the body counts.
look out, the truth is representing itself, & it's accuracy, resulting in it's honesty mandate kicking in. there's a chance it may get out this time?
money, real estate, religion, fear, ego. any one of these 'features' can outweigh the right to life of many, except the chosen ones.
can't find this post where it was left last. must be deleted/meaningless compared to stuff that matters? space problem?
ret.4star.gen.hero, or hired goon psycho killer? (Score:0)mynutswon; the holycost may not be questioned
hard to tell? fog of tax free (for some) war can do that? did we say tax free? pardon, the non-taxpayers actually profit ($billionerrors$) on the heavy weapon (keeping ALL sides supplied including mexico) murder massacre business outings. so that's good?
we support the views of this former person
http://www.youtube.com/watch?v=TY2DKzastu8&NR=1&feature=fvwp ("stop killing")
we do not support the material in this cnn propaganda video from yesterday
http://www.youtube.com/watch?v=BXB75IK6pL4 ("we can win this, with my help")
same guy? clone? confused? we must focus... on the images. we must....saw a picture of one of those godaffy psycho-killer freaks being paraded around our military bases (may have paid for them, along with our holycost tithing's) like royalty, only to become our very worst 'enemy' just weaks/leaks later? focus-pocus?
Ah, it's articles like this that make me so glad I'm retired!
C++ programmers have it too easy. Why, in C we had to code our own bugs. C++ programmers just inherit them!
Some monster warts not addressed, like no designated intializers, no flexible arrays. Some backwards progress like the idiotic narrowing errors in cases like { 1, 2 } for an array of floats. But in general, a better language, I switched to -std=gnu++0x a few months back.
Have you got your LWN subscription yet?
After years of work, we are pleased to announce the++, a successor to the hugely popular english determiner "the". Although many people in recent times have been happy to use "the" as a determiner, we have worked hard to extend the semantics into verb, adverbial and noun forms. Thus; The the the the.
We have strived to create a professional and expressive tool and sincerely hope that english speakers and writers alike will get as much pleasure from using the++ as we had in creating it.
In closing, the++ allows the the the and the the. It is the correct the the the if the the the the clearly understood.
I hate C++. I have so many objections to it that I can't even list them here reasonably.
However, there is nothing that can replace it. Everything fails on some account or another. C++ lets you have high level power without sacrificing extremely low level control. No virtual machine, sandbox, or GC'ed language can do that.
So yes, it's a horrible language. But yes, I'm on a team writing an OpenGL based game engine, and we're using C++, because it's the only reasonable choice. We need exact control over bitfield layouts, we need inline assembly, we need good GL bindings, and so on.
Enough said!
-Chris
Incorrect. The year 2011 A.D. is 7DB Hexadecimal A.D. Ergo, if you're going to abbreviate the numeral using the last two digits you should be heralding C++'DB or simply shorten it to C++'B.
Note: Due to the fact that legacy versions are abbreviated as YEAR mod 100 in radix (base) 10, the new hexadecimal notation should include the a prefix or suffix indicating the radix in use. For quite some time there has existed such a hexadecimal radix prefix in C and C++: 0x
Thus: /* WTF! */ };
Hurray for C++ 0xB;
(Also note the above line does not parse as valid statement in C++, even though the ++ operator actually does take a dummy int parameter as the right-hand-side to differentiate it from the ++C; prefix increment operator.
operator++(int){
For meatball's sake people, even the ++ operator is a kludge in C++? ( "C++" translates to "C (with kludges)" to me.)
Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception? Should I wrap all such statements in a try / catch block!?) If you haven't studied the entire inheritance graph of the type that the C variable is declared as, there is really no way (beside a debugger) to know what will happen next. (What if a pointer is to a polymorphic class? *my_ptr->operator++(42); Now, it's not supposed to do anything with that "dummy" 42 value, the base type doesn't but a subclass might...)
Don't get me wrong, I code in C++ every day, and prefer it to C, but it surprises me just how messed up things have been allowed to get because we're shoe-horning in features into an existing syntax instead of just creating a new language that has less kludges.
int main() { //Constructed an int "object" by calling it's "constructor" // DOES NOT call the int object's empty constructor. // ERROR, the previous line declares a function. ... }; ARGH.
int my_var_a( 1 );
// ^^^ Uh.. OK ints are object-ified now.
int my_var_b();
my_var_b = 10;
return my_var_a;
}
^^^^^^ Declares a new function in the function/method body WTF? (because C lets you do that, for better or worse... )
use: int myvar; to "instantiate" a new int "object" using the empty constructor instead... So, why can't I subclass an int? class my_number : public int {
Look, it's clearly time to stop hacking extra features into the language, or stop letting it be hindered by legacy C conventions / syntax. I think that C++ could be much better than it is if it weren't pandering to C coders... It's too bad that we started down that path with C++, there's far too much time and energy invested to reboot it now.
I'm glad for some of the new C++ features, but at this point there's not much to celebrate for me -- Doing without for so long has caused us to create our own systems: the C++0x garbage collector is incompatible with my multi-threaded hybrid strategy (pool / slab & heap-like) memory manager (thank Spaghetti Monster, theirs is optional), I already have a ton of code that uses my cross platform multi-threading libraries, we've been using a HashContainer for over 10 years in our company...
C++0x7DB adoption to us means: "Oh great, they finally got around to standardizing all these things we've needed for years and made ourselves -- It's going to be a headache writing new code that conforms to the new standard while remaining compatible with our current code-base."
(And there was much rejoicing: "... yay... ")
Also note the above line does not parse as valid statement in C++, even though the ++ operator actually does take a dummy int parameter as the right-hand-side to differentiate it from the ++C; prefix increment operator.
My mnemonic for remembering which version of ++ takes the dummy int is that postfix ++ is "ugly" in the sense that you shouldn't use it*, so the postfix ++ operator takes the ugly dummy int.
This doesn't justify the syntax which is admittedly horrid, but maybe it'll help people who have this problem.
* Take "you shouldn't use postfix ++" with a small grain of salt, though I do mostly believe it. With rare exception, I really really dislike increment operators mixed in a larger expression, which means with rare exception they are standing on their own, acting as statements. And in that context, prefix and postfix ++ do the same thing, and you should use prefix for the traditional efficiency arguments.
Declares a new function in the function/method body WTF? (because C lets you do that, for better or worse... )
What I like best about that is the standard's rule "if a statement can be interpreted as a declaration, than it is" rather than making declarations actually look different from statements. That's pretty awesome.
Bell Labs is gone, and the two most popular variants of Unix aren't officially Unix, but C++ lives on. Embedded in the name is the quirky operator that Dennis Ritchie invented some 40 years ago, as a way of shaving a few instruction cycles in inner loops from a high level language.
'nuf said.
Now the problem is to wait for one's customers to move to the latest compilers that support this. Having a big customer that uses Visual Studio 2005 can be a headache when you want to use a new feature in your tools.
Q: Your code is so beautiful, how do you do it?
A: I write the first version in C++, and then I chisel away everything that is not C.
How do you pronounce 'C++0x', and why does my modem keep resetting when I type it?
Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception? Should I wrap all such statements in a try / catch block!?)
It's quite simple: it increments the variable C, but evaluates to the value of C before incrementing it. The fact that someone may create an operator++ that does something else isn't a problem with the language but with the programmer. C++'s operator overloads are syntactic sugar for regular function calls. Do you really know what postfix_increment(C) does anymore than operator++?
That's like that couple who has been together for 20 years
and has a couple of high-school age kids
telling you that they just decided to get married.
Brilliant. It was bad enough in job interviews when they try to catch you out on your knowledge of the obscure bits of C++ that nobody ever uses, and now there's a whole new level of complex syntax, pitfalls and gotchas to deal with. C++ is turning into a warty freakshow. I could even start to forgive Python's idiotic indentation nonsense at this rate.
Cress, cress, lovely lovely cress
Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception?
to be fair, all the other 'oo' languages don't let you do that either, and C can give you the same problems if you're using #defines (C's equivalent to operator overloading :) )
At least in C++, you can look at the header file for the class definition and see what its doing. In languages like C#, those overloads can be anywhere - not even associated with the class itself. Scripting languages can be the same,
Still, I don't think C++ needs more low-level features, it really needs a higher level library of useful stuff - like boost but even higher level than that. And you're right - it really needs more consistency, even if that means breaking a bit of older code. Your examples show that the language is dying of old age now, its not the lean and fit language of its youth, especially as they're adding more wrinkles to it now. This is the thing that worries me (as a C++ dev) most.
I can see why there's so much favour towards D.
You should see a psychiatrist. That level of masochism is really unhealthy.
Brilliant! I assume they've got rid of those things called header files by now.
And before anyone moans that "header files provides a good overview of a project", well, it should be up to the IDE to display information (much better presented) about a project and its classes and members. Even Bjarne Stroustrup said that header files were a kludge,
Break backwards compatibility a little bit and you can do so much stuff better. Otherwise you ultimately have a dying language.
Why OpalCalc is the best Windows calc
Just as a side note, regarding "objectified int" - the term "object" in C++ standard actually comes from plain C, and doesn't have much to do with objects in OO sense. I'll just quote the C99 spec:
3. Terms, definitions, and symbols ...
For the purposes of this International Standard, the following definitions apply.
3.14 object
region of data storage in the execution environment, the contents of which can represent values
to be fair, all the other 'oo' languages don't let you do that either
C# has operator overloading. Granted, it prevents you from doing certain particularly stupid things (such as overloading == but not !=, or overloading &&. In case of ++, it will require the return type to be the same as argument type, but the precise meaning is still controlled by the implementor.
I certainly agree that it's amazing how many things in c++ flagrantly violate the principle of least surprise. A good example: read these two articles about the assignment operator and weep. The author (who by no means could be accused of being biased against c++) concludes:
I'd have to disagree with you about c++0x though. While there is additional complication, many of the added ideas seem to have few "gotchas" relative to most of c++, and it even manages to eliminate a few "gotchas." I didn't learn c++ until last year (mostly have done my programming in Java and MATLAB, with little bits of everything from C to Scheme along the way), and I ended up using gcc's c++0x option because there were a bunch of ways in which c++0x made things less painful and made c++ seem less braindead.
n/t
So, does Garbage collection work on C++ now or is that just another point on the list of features that sound good, but never worked?
Just like overloading operators, which only works for some operators. Or copy constructors.
"Certainly, lack of standardization hasn't prevented other languages, such as Java in the past, but look what happened there. Microsoft was litigated out of the market, and now Oracle is sueing Google and possibly others. This is not very commercial compiler friendly."
On the other hand IBM has its own JVM and wasn't/isn't paying licensing fee to Sun/Oracle.
The license only prevents incompatible forking. As a Java developer, I don't think it's a bad thing.
It is great!
I don't know why people whine about it so much - it isn't that hard, and if you don't like it use something else.
I am very small, utmostly microscopic.
*puts on sun glasses*
BOOST productivity.
YEEEEEEA...etc, .etc.
My -1 Troll is actually a +1 funny. And my -1 flame is actually a +1 insightfull.
Only if the programmer intentionally obfuscated the code. But then, he doesn't need operator overloading of #define; tell me, what does "increase_by_1(C);" do?
Oh, and if C is an int (or another incrementable builtin type), the statement C++; will indeed increment C, with certainty.
The Tao of math: The numbers you can count are not the real numbers.
Have any C++ programmers tried using Google's Go programming language? Any opinions?
Do you really know what postfix_increment(C) does anymore than operator++?
Yes, unless the programmer was deliberately setting out to obfuscate things it is very unlikely they would call a function postfix_increment unless that is what it actually did and even then it would be a pretty strange way to name a function and an immediate red-flag.
In all the langauges I have experiance with there is a very limited set of operators. The result is where there is no operator that is a good fit the programmer must either give up on operator overloading entirely or (ab)use an existing operator which is a poor fit. This forced descision make operator overloading a dangerous tool. Used properly and sparingly it can make code clear and concise. Overused it will make code smaller but harder to follow.
Below are a couple of examples from the standard library of what I consider to be bad uses of operator overloading:
The streams code overloads to use to output stuff. This makes outputting stuff a little more concise but also means you have to manually keep track of variable types to tell the difference between outputting stuff and shifting bits. To make things even more confusing they made the operator return the stream so users can chain the operations.
auto_ptr uses = for assignment but has rather weird symantics which break the normal assumptions that people are likely to make about the behaviour of an assignement operator. In particular assigning something to an auto_ptr effectively destroys the original (either immediately in the case of an assingment from one auto_ptr to another or when the auto_ptr goes out of scope in the case of an assingment from a plain pointer to an auto_ptr).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
"C++ is an octopus made by nailing extra legs onto a dog."
Where can I donate money to help the victims?
"You can't allow somebody to commit the crime before you detain them." [Condoleezza Rice]
You have to keep in mind that one of the major advantages of C++ and most likely the thing that made it a wide used language, is it's backwards compatibility with C. And that's not because C programmers had a hard time learning C++, but because there exist enormous quantities of C legacy code that would have to be completely re-written if C++ wouldn't provide this backwards compatibility. With the C++ compiler you could continue the work on these projects with the added benefit of finding a few bugs that you didn't even knew were there.
Of course, some of the monster constructs that are allowed in C++ should not be used, they are there just so your old C code compiles. That is the reason best practice books exist, so you know what features of the language to use and when.
Instead of hating on C++ (and now C++0x) because of the features it offers, maybe decide which of those feature to use and which not in your project.
Like C++ is compatible with C, C++0x is compatible with C++, so I don't see any reason why existing projects in C++ shouldn't compile. Maybe I'm wrong here, but I'm under the impression that all the C++ code-base should compile in C++0x without modifications and should work exactly the same.
Bang: You're dead! Assumptions have that effect. My point stands that certainty is only derived from reading every flipping line of code that is ever "included" -- Who does such things? Masochists. Who designs language traps such as these? Sadists.
Only if the programmer intentionally obfuscated the code. But then, he doesn't need operator overloading of #define; tell me, what does "increase_by_1(C);" do?
Oh, and if C is an int (or another incrementable builtin type), the statement C++; will indeed increment C, with certainty.
Unless someone has overloaded the global ++ operator for int types... Your "certainty" assumptions amuse me.
You, my friend, have arrived at the heart of the matter, and thus was my initial point:
C++ is to be regarded as "a different language than C", not as C with extensions. However, C++ was surely developed by adding features to C, then calling it a new language after the fact.
My point is that the basic C syntax could have been kept in C++ without having to limit C++ to old language constructs. The main point is this: The C++ language itself has no business compiling C code. If C++ libraries need extern "C" { ... } to provide C interfaces for their functions, then why not REQUIRE a wrapper convention for any and all C code in a C++ project, then simply let code not wrapped in a "Parse this as C" block have whatever semantics are required -- Including those that break C syntax.
You see -- C++ could have both retained a close tie with the popular C language, while at the same time isolating itself from the older C syntax.
I've actually developed a few toy scripting languages that are "somewhat" C like... In fact, my favorite of these scripting languages has this very parse_as "C" { ... } construct, which simply extracts the code, invokes a C compiler on it to build a shared C library from all such blocks, and dynamically loads those libs at run time. (The VM translates these code blocks into a "load_shared_c" instruction, followed by op codes that add function names to the context's symbol table. These symbols contain functors that call the shared C lib's function by function pointer.)
In short: It is possible to retain the power of C, and take advantage of the C install base, WITHOUT polluting your language with the C language's syntax...
math' = parse_as( "C" )'(){
#include <math.h>
long multiply( long a, long b){
return a * b;
}
double divide( long a, long b){
if ( b != 0 ) return a / (double)b;
return -INFINITY;
}
}
args' = ( 6, 7 );
ans' = math.multiply( args );
say( "Multiply: " + args + " = " + ans );
say( "also, " + args.join( " / " ) + " = " + math.divide( args );
----- output -----
Multiply: 6, 7 = 42
also, 6 / 7 = 8.57142857e-1
You cannot overload the global operator++ for int types. It is explicitly forbidden by the C++ standard, and if your compiler really allows it (I strongly doubt it), it's time to get a better compiler.
The Tao of math: The numbers you can count are not the real numbers.
Just as a side note, regarding "objectified int" - the term "object" in C++ standard actually comes from plain C, and doesn't have much to do with objects in OO sense. I'll just quote the C99 spec:
3. Terms, definitions, and symbols For the purposes of this International Standard, the following definitions apply. ...
3.14 object
region of data storage in the execution environment, the contents of which can represent values
Yes, and the instance of a Class is a "region of data storage" used in the execution environment, the contents of which can "represent" a "value". Literals are also stored in regions of data storage, and used in the execution environment, with contents that can represent values... So also may a variable of an enumeration type, or even functions (which have stack frames) for meatball's sake! -- So once again, the multi-headed snake is happy to eat any of its myriad of tails.
I don't object to the object of object oriented programming; However, I do object to, "object" being the chosen term for objects in any programming language.
It's as if the object of choosing "object" to name objects were to cause confusion and ambiguities, not resolve them. (Clearly this must be some sort of bad joke, no?)
If it were one of the objectives of an object oriented programming language, to help provide clarity of concept, one would think that the creators of such languages would have been a bit more objective and chosen less objectionable terms, such as Entity, native type, idea, concept, form, pattern, formula, design, etc.
C++ is marketed as an "Object Oriented Language". IMHO, the term "object" is a very overloaded in English -- Like C++ functions can be...
"Object Oriented Programming" could describe a language that revolves around the concept of Objections -- Like C++ does (Exceptions).
"Object Oriented Programming" could describe a language that focuses on the objectives of the logic, not the data model, similar to the procedural aspects one uses in a language such as C++.
"Object Oriented Programming" could even describe a language that allows one to group data and behavior into a single unit, like C++ classes do...
Finally, given your citation of the ambiguous "standards", C++ being capable of "Object Oriented Programming", could mean that one spends most of their time reprogramming the syntax of the language to provide different behaviors for standard built in "primitive objects"... Like C++ operator overloading does...
You know what, I take it back, "Object" is a perfect term for C++ -- It's opaque, ambiguous, and ill-suited for its purpose, in other words, par for the course in C++.
( Don't even get me started on "classes" -- Are we talking classification system, or training of AI algorithms? Perhaps we mean that classes are where you must go when the compiler objects to your code in order to learn WTF the object of the object's objects are. )
Well I must apologize, I was wrong. language native primitive types can't have global operators overridden...
So I guess there's only one predictable set of operations you can do in C++, work with the primitive types. Except, you can't really predict the size or range of the primitive types until runtime, unless you know the specifics of the platform the code will be compiled on.
I grepped my code, and couldn't find a singe use of an int, long, char, etc... Turns out that we all use stdint.h types to provide cross platform capabilities (even though it's C not C++) -- typedefs for all the primitive data types, such as uint32_t are used in place of int, because sizeof( int ) is platform dependent... Now, quick, say you're on a 32 bit system. Without looking in the stdint.h file, prove that uint32_t is not really a class that implements all the int operators, has an internal state 4 bytes in size, and can cause the following statements to do any arbitrary operation.
#include <stdint.h>
int main( void ){
uint32_t C = 0;
return C++;
}
Use tricks with Templates? xxx_cast, etc? Typeinfo? All those things work at compile time -- looking at the code, and only the code, without compiling it and running it, there's no way to tell what the hell it's going to do.
Say you do read through the stdint.h and discover that uint23_t is an alias for int... ON YOUR SYSTEM. Who knows what stdint.h will define uint32_t as on anyone else's system -- Faith is a required virtue of C++ coders. On an 8 bit system, uint32_t may be a class that wraps an array of 4 ints (8 bit each == 32bits), and simulates 32 bit integer operations... or perhaps they open network connections and ask a mainframe what the answer is... I still can't really tell what's going to happen when that simple code executes... hell, even if I take for granted a "standard" stdint.h file being available, the semantics of #include <stdint.h> vs #include "stdint.h" are platform dependent -- some compilers will look in the current directory first regardless of the angle brackets or quotes.... so... Is there a stdint.h in the local directory? Only looking at the code, I can't tell... Is it really so hard to give a C++ programmer even the most basic tools, such as a few guaranteed size integer types? ( isn't in my C++ compiler; Is it in yours? -- stdint.h is C, not C++ )
I admit that I'm wrong about the special case where you actually use the platform dependent language primitive types such as int, char, etc, however, just because sizeof uint32_t == 4, doesn't mean that's a primitive type, and short of using typeid or other such compile-time or run-time operations, I'm not sure I can predict what that code will do without reading the typedef and/or class implementation of the uint32_t type.
Conversely, in languages that don't allow operator overrides, I can be sure that +, --, ++, and other mathematical operators operate on numbers, or at least perform defined operations given a set of parameter types.
Yes, and the instance of a Class is a "region of data storage" used in the execution environment, the contents of which can "represent" a "value". Literals are also stored in regions of data storage, and used in the execution environment, with contents that can represent values... So also may a variable of an enumeration type, or even functions (which have stack frames) for meatball's sake! -- So once again, the multi-headed snake is happy to eat any of its myriad of tails.
Literals are not stored in regions of data storage, except for string literals - and yes, those are objects (same as any other array). Variables of enumeration type are also objects - I don't see why you feel there's a contradiction here (did you mean to refer to enumeration members instead? they're not objects because they don't have any storage backing them). Functions are not objects, because they do not represent a value (though in C++ this is explicitly clarified in the spec, unlike in C).
C++ is marketed as an "Object Oriented Language".
If someone markets it to you that way, then they're clueless. C++ is a multi-paradigm language which offers OOP among many other approaches, without forcing any on you.
Oh, and even so, there's a common understanding of what OOP means in the field. You can come up with your own differing definitions, but it doesn't prove anything, as they're not the ones actually used in practice by anyone.
You know what, I take it back, "Object" is a perfect term for C++ -- It's opaque, ambiguous, and ill-suited for its purpose, in other words, par for the course in C++.
"object" is not a C++ term; it's a C term that was inherited in C++ simply because most C++ programmers were also C programmers, and it would be more confusing to change the terminology that they're using.
As for C, arguably, the term "object" there was used before OOP went truly mainstream.
Don't even get me started on "classes" -- Are we talking classification system, or training of AI algorithms?
Same as "OOP". This one has many meanings, but there is a very well established one in the context of C++, which everyone understands. There's no confusion here other than what you try to artificially induce.
Well, there are guaranteed minimal sizes, and rarely you need the exact size (unless you are doing very low-level stuff, but then you should better know your platform anyway).
Given that stdint.h is a C header, it will of course define it to whatever it is defined to be in C. Of course if using a compiler you always need to put faith in the provider that he doesn't do stupid things, or have glaring bugs in the compiler or associated library.
stdint.h is a standard C header, and therefore cannot use any operator overloading.
But even if it were a user-defined type, unless the programmer writing it was a complete moron who should not have been let closer than ten miles to a compiler (of whatever language), you can expect that any operator works exactly as expected.
The original C89 didn't have it either. And the next version of C++ will adopt it from C. But as I said, if you need specific sizes, you obviously do low-level programming, in which case you better know your platform (which defines the sizes of C integer types) anyway. Therefore a header with pre-defined specific-size integer types, while certainly useful, is not really essential.
And in languages that don't allow user-defined functions I can be sure that multiply(a,b), if defined, does indeed multiply a and b. We really should disallow user-defined functions; they can completely mislead you!
The Tao of math: The numbers you can count are not the real numbers.