restrict is a C99 feature which is getting a lot of attention lately by allowing the compiler to perform "previously-fortran-only" optimizations to pointers. It's also the same keyword announced by Microsoft recently to be the underpinnings of the C++AMP specification.
Is that keyword actually in the FCD? If not, is there a specific reason it was omitted?
The only mention of restrict in the C++11 FDIS is on §17.2 [library.c]:
The descriptions of many library functions rely on the C standard library for the signatures and semantics
of those functions. In all such cases, any use of the restrict qualifier shall be omitted.
So restrict is not in C++11.
One argument is that C needs restrict more than C++, because many operations are done with pointers to primitive types and therefore C code has more aliasing problems than C++.
The aliasing rules say that pointers to different types cannot alias, so if the parameters to a function are of different class types they just cannot overlap.
In C++ we also have the valarray family of classes that are supposed to handle arrays of primitive types that are not allowed to alias. Not that it is used much...
Adding yet another way to resolve some aliasing problems, obviously didn't excite the committee enough.
http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/
Not only the VC++ team, but also the ISO C++ standards committee, considered adding restrict to VC++ and ISO C++, respectively. Although it was specifically suggested for ISO C++11, it was rejected, in part because it’s not always obvious how it extends to C++ code because C++ is a larger language with more options and we would want to make sure the feature works correctly across the entire language.
Don't think it's in C++1x (unfortunately time has long run out for 0x...!) but at least msvc and g++ support it through __restrict and __restrict__ extensions. (I don't use gcc much, I think that's the correct extension).
To work properly with C++ I feel that we would also need restricted references, not just pointers, maybe along the lines of my question C++ aliasing rules. Not sure if some of these considerations might be holding things up...
I will take a crack at "why not?"
restrict is basically just an assertion that the compiler cannot verify. (Or more precisely, when the compiler can verify it, the assertion itself is not helpful.) This is just not the sort of thing that the C++ committee is going to like. C++ has always tended to assume "sufficiently smart compilers"; heck, look at the hideous performance of the most trivial C++ libraries before the compilers caught up.
I also suspect the committee felt that defining restrict semantics precisely in the presence of all the other C++ features (references, rvalue references, blah blah blah) would be non-trivial.
So, non-trivial to specify + "a sufficiently smart compiler doesn't need it" = NAK.
Related
Why doesn't C++ allow containers of incomplete types to be instantiated?
It's certainly possible to write containers that don't have this restriction -- boost::container is completely capable of doing this. As far as I can see, it doesn't seem to give any performance or other type of gain, and yet the standard declares it to be undefined behavior.
It does prevent recursive data structures from being built, for example.
Why then does the C++ standard impose this arbitrary restriction? What would have been the downside of allowing incomplete types as template parameters wherever possible?
Matt Austern, the chair of the C++ standardization committee's library working group, explained this decision of the committee in his Dr. Dobb's article by historical reasons:
We discovered, with more testing, that even the [simple] example didn't work with every STL implementation. In the end, it all seemed too murky and too poorly understood; the standardization committee didn't think there was any choice except to say that STL containers aren't supposed to work with incomplete types. For good measure, we applied that prohibition to the rest of the standard library too.
My understanding of this is that the committee did not want to invalidate existing implementations of the library by requiring them to support incomplete types retroactively.
In the same article he concedes that
In a future revision of C++, it might make sense to relax the restriction on instantiating standard library templates with incomplete types.
Given that the article dates back to 2002, and the prohibition remains in place in the current standard, I think that the decision of the boost designers not to wait for the future and build their own containers that allow incomplete types was fully justified.
Edit: See this answer for information on using incomplete types allowed by C++17 standard for some containers in the Standard C++ Library.
I would like to start using static_assert in the codebase that I work on. Unfortunately, not all C++ compilers support them. In the past, we've used a compile-time assert macro that works reasonably for all the compilers I've tried (gleaned from SO!), but, it gives slightly awkward compile error messages.
We support a large number of compilers, including ones which do not have support for static_assert. Also, because our product is an SDK with source code our customers can recompile it with any compiler that they wish. So, while I could introduce conditional compilation for it in all the compilers we use, it's not really possible for me to do it for any 'unknown' compiler.
Is there some compile-time predefined macro or other facility that is standard across all C++ compilers for determining the availability of static_assert, or, are you just required to 'know' what every compiler supports?
You might consider using Boost's static assert.
Note on the boost website:
Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications.
For this reason, boost usually intentionally lags behind in use of language features. You can find the compiler compatibility list here.
If you must roll your own implementation, then here is a Dr. Dobbs article. If I'm not mistaken, Andrei Alexandrescu wrote about this in his Modern C++ Design.
In C++14, there are feature test macros, which allow you to generalize the use of C++11/14/17 features. For static_assert, the macro is __cpp_static_assert.
If your compiler does not inherently support these (yet), you can define them, based on knowledge of what your compiler does support, but they will be forward compatible with any standardized 'unknown' compiler.
Note: this answer was obtained from a question I asked generalizing this one, to any C++11 feature (Availability of C++11 features). I think there was some confusion about the motivation of this particular case, and the answers given tried to solve providing a nice static assert, more than than the actual question as it was asked (which, they didn't actually do).
I have this classic question of how should the C++ Standard (I mean the actual official document of the finalized ones) e.g. C++98, C++03 be used to learn and teach C++. My idea is only from the point of view of an average C++ user and not from the point of view of the language lawyers or someone who wishes to be in the Standards committee, compiler writers and so on.
Here are my personal thoughts:
a) It is aweful place to start learning C++. Books like "C++ in a Nutshell", "The C++ programming Language" etc do a very good job on that front while closely aligning with the Standard.
b) One needs to revert to the Standard only when
a compiler gives a behavior which is not consistent with what the common books say or,
a certain behavior is inconsistent across compilers e.g. GCC, VS, Comeau etc. I understand the fact that these compilers could be inconsistent is in very few cases / dark corners of the language e.g. templates/exception handling etc. However one really comes to know about the possible different compiler behaviors only when either one is porting and/or migrating to a different environment or when there is a compiler upgrade e.g.
if a concept is poorly explained / not explained in the books at hand e.g. if it is a really advanced concept
Any thoughts/ideas/recommendation on this?
The C++ language standard would be an absolutely terrible place to start learning the language. It is dense, obtuse, and really long. Often the information you are looking for is spread across seven different clauses or hidden in a half of a sentence in a clause completely unrelated to where you think it should be (or worse, a behavior is specified in the sentence you ignored because you didn't think it was relevant).
It does have its uses, of course. To name a few,
If you think you've found a bug in a compiler, it's often necessary to refer to the standard to make sure you aren't just misunderstanding what the specified behavior is.
If you find behavior that is inconsistent between compilers, it's handy to be able to look up which is correct (or which is more correct), though often you'll need to write workarounds regardless.
If you want to know why things are the way they are, it is often a good reference: you can see how different features of the language are related and understand how they interact. Things aren't always clear, of course, but they often are. There are a lot of condensed examples and notes demonstrating and explaining the normative text.
If you reference the C++ standard in a post on Stack Overflow, you get more a lot more upvotes. :-)
It's very interesting to learn about the language. It's one thing to write code and stumble through getting things to compile and run. It's another thing altogether to go and try to understand the language as a whole and understand why you have to do things a certain way.
The standard should be used to ensure portability of code.
When writing basic c++ code you shouldn't need to refer to the standards, but when using templates or advanced use of the STL, reference to the standard is essential to maintain compatibility with more than one compiler, and forward compatibility with future versions.
I use g++ to compile my C++ programs and there I use the option -std=c++0x (earlier, -std=c++98) to make sure that my code is always standard compliant. If I get any warning or error regarding standard compliance, I research on that to educate myself and fix my code.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let me start with explaining what I mean with "magic". I will use two examples from Java:
Every class inherits (directly or indirectly) the Object class.
Operator overloading is not supported by Java but the + operator is defined for String objects.
This means that it is impossible to make an implementation of the Object and String classes in pure(*) Java. Now this is what I mean with "magic": to make an implementation of these classes, you will need some special support from the compiler.
What I always liked about C++ is that, as far as I know, there is no such "magic" going on in the STL, i.e. it is possible to implement the STL in pure C++.
Now my question is: is this true? Or are there parts of the STL that cannot be implemented in pure C++ and need some "magic"/special compiler support?
(*) With "pure" I mean without using any class libraries.
in other words, has anything been done to the compiler to allow for a 'special case' the STL needed to work?
No.
It was all implemented as 'pure' C++ code, using the magic of templates.
There has been some work done to compilers to improve the STL (I'm thinking about various optimisations) but otherwise, no, you could write the entire STL if you really wanted. Some people did - STLPort is an implementation that didn't have the backing of any compiler manufacturer.
Like gbjbaanb correctly said, the STL can be implemented in plain C++, without relying on any kind of compiler "magic".
However, if you go digging in the STL source code for your compiler, you'll probably see code that either isn't standard, or which you're not supposed to write yourself.
The STL can be implemented entirely in standard C++, but that doesn't mean compiler writers aren't allowed to improve it occasionally, using compiler-specific extensions. For example, they might insert non-standard code that ensures better error messages, or perhaps works around some flaw in their compiler, or maybe enables special optimizations by using extra features of that specific compiler.
They also consistently use names that you're not allowed to use. For example, template parameters are typically named something like _Type, which, since it starts with an underscore followed by a capital letter, is reserved for the implementation. The standard library is allowed to use them, but you and I are not. So if you were going to write your own STL implementation, you would have to make some minor changes, but that's not because of any magic, just a way to avoid name clashes between the standard library and user code.
As others have said, the STL is implementable in pure standard C++98. What hasn't been said is that the development of the STL was concurrent with the development of the C++ template mechanism, and largely drove the inclusion of certain features. I believe that Argument Dependent Lookup (ADL, aka Koenig Lookup), template template parameters, and default template arguments all came to C++ to serve Stepanov's STL development.
So, with STL, they moved the magic into the language itself. Nice that the standards committee recognized that if those features were useful for what would become the standard library, they might be useful for the rest of us as well!
If by STL you mean only the template portion of the C++ Standard Library, then it is perfectly possible to implement it without any "magic". Whether each given implementation actually uses any "magic" is a different question (there are portions of STL where "magic" would help, but not absolutely required).
Now, if you are talking about the entire C++ Standard Library, then it does indeed have a bit of "magic" in it. The classic example would be the library-provided ::operator new and ::operator delete implementations. We often call them "overloadable" in everyday language, while formally they are replaceable. The C++ language does not offer such functionality to the user. The user cannot write a replaceable function.
Another example would be the offsetof macro (inherited from the C Standard Library). While it is usually implemented in "pure C", the popular implementation is actually illegal from the pedantic point of view (causes undefined behavior). I haven't seen any formally legal implementations of offsetof, so I'm not sure whether they are even possible.
Another example would be (again, inherited from C) the macros for working with variable arguments. They obviously cannot be implemented in pure C or C++.
I'm pretty sure some type_traits require compiler magic, for example has_trivial_constructor, has_virtual_destructor or is_pod.
std::initializer_list needs compiler support and cannot be reimplemented as another class (as far as I know), though I'm not sure if it counts since it's in c++0x.
C++0x is going to standardise some de facto "magic" type traits.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.htm
"Additional Type Traits for C++0x"
This contains a few remarks such as "XXXX is believed to require compiler support."
See also
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Type-Traits.html#Type-Traits
http://msdn.microsoft.com/en-us/library/ms177194(v=vs.80).aspx
As "gbjbaanb" rightly said, there is no magic involved in the implementation of STL. It is written in pure C++. You could implement it yourself but has been made readily available as a library to make your life simpler.
STL is standard (Standard Template Library). The standard specifies the requirements for STL implementations. From the usage point of view, there is no "magic", no special dependencies you have to take care of. It can be used on any major C++ compilers, on all platforms supported by those compilers.
I already read the FAQ, and i think maybe this is a subjective question, but i need to ask.
Does anyine knows what exactly (i mean formally) is a C++ language extensions.
I already saw examples, like nvdia CUDA c ext, Avalon transaction-based c++ ext.
So the point is something like a formal definition or so.
thxs anyway.
A language extension is simply anything that goes beyond what the language specification calls for. Your compiler might add new features, like special "min" and "max" operators. Your compiler might define the behavior of division by zero, which is otherwise undefined, according to the standard. It might provide additional parameters for your main function. It might be the incorporation of another language's features, such as allowing C-style variable-sized arrays in C++. It might be a facility for specifying a function's calling convention.
Using a language extension usually makes your code non-portable because when you take your code to another OS, compiler, or even compiler version, the extension may not be available anymore, or its behavior may be different from what you had originally used.
Please see Extensible programming:
Extensible programming is a term used
in computer science to describe a
style of computer programming that
focuses on mechanisms to extend the
programming language, compiler and
runtime environment.
and more to the point, the Extensible syntax section:
This simply means that the source
language(s) to be compiled must not be
closed, fixed, or static. It must be
possible to add new keywords,
concepts, and structures to the source
language(s).