We can have a local class defined inside a function but this class cannot be a template which is bit annoying and inconsistent. Is there any update on that in C++0x standard?
Yes. Actually this rule change is what makes Lambda expressions possible since a Lambda expression creates a local unnamed type.
Sorry, I misread your question. I thought you were talking about using a local class as template parameter. This wasn't allowed in C++98 and C++03 but it will work in C++0x.
As for your actual question, C++0x will not change any of this.
I honestly see no reason to allow "function-local class templates". The support for "function-local class templates" is a feature that probably only a handful of people care about. And writing class templates outside of functions is an acceptable substitute for this. This obviously doesn't put enough pressure on the compiler vendors no matter how complicated it is to implement such a feature. Compiler vendors are probably more concerned about implementing other C++0x features.
But I understand your point. It may seem as an unnecessary irregularity of the language. If you care strongly about this feature you could write a formal proposal and send it to the C++ standardization committee in about two years when they are likely to accept proposals for "C++1y".
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.
Is there a way to find out what the protection level of a member is?
I'm making a singleton base-class and I'd like to ensure that the child class declares its constructor/destructor as private/protected. How can I do this?
template<class c>
class singleton
{
static_assert(std::is_private<&c::c> // does this exist?
|| std::is_protected<&c::c>);
static_assert(std::is_private<&c::~c>
|| std::is_protected<&c::~c>);
};
There is a paper written that proposed this in 2018, (and later 2019). In fact, it appears it was circulated in June of 2019 as part of the Committee's proposal process. However, I'm not really sure what happened to it (other then I think I found another revision).
Some compilers might support it experimentally. If they did, I believe the header you would use is <experimental/reflect> (according to the paper, at least).
Otherwise, you're kind of stuck. It appears reflection was deferred to a later standard, so nothing like this really exists in C++ as it stands. Hopefully it will make it into C++23. But for now we have to wait.
Unfortunately, what you are trying to do is not possible. So far, C++ doesn't have reflection features that are powerful enough.
In reality, programmers use singleton classes without needing protection mechanisms like this, because C++ is not designed for maximum compile-time validation. There are a whole lot of other similar things you can't do in C++ — in other words, it is impossible for C++ to accommodate for every possible feature users may expect, especially those that are not generally considered useful. Reflection is proposed because many people find it helpful, but so far the equivalent capabilities have not been included in C++.
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.
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.
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.