I try to achieve this code using VS2017, and get errors :
template <class T>
class A {
public :
A() {}
};
template < template <class U> class T, class U>
class B : public T<U> {
using T<U>::T;//Errors : # 'T': is not a member of 'A<U>' # 'T': symbol cannot be used in a using-declaration
};
int main() {
B<A, int> test;
return 0;
}
Works perfectly using Clang and GCC according to https://wandbox.org/
I'd like to know why it's not working on Visual Studio, and how to fix it. Looks like VS doesn't want to consider second 'T' parameter as a template.
Here is another question previously asked the closest I could find about this matter. Couldn't find a solution reading it though :
Inheriting constructors from a template base class
The workaround is to define a typedef alias
typedef T<U> base_t;
and use it to inherit the constructors from the base class:
using base_t::base_t;
This is not a unique compiler bug; I dimly recall a similar issue with an old version of gcc.
Related
I am trying to get a cmake C++ project that compiles and runs with GCC to compile with MSVC. I am using VS 2017.
I'm not the author of the code I'm just tasked with making it compile with MSVC.
The project is large so I am unsure how can present a MCVE. However, I will try to explain as best as I can here:
I am getting this error:
Which correspinds to the friend declaration in the below sibling_iterator class.
However, leftmost_output() is a member of node.
The definition of node is appended below (see about 3/4 of the way down):
I'm pretty sure this is related to the bug in VS related to nested template classes as sibling_iterator and node are nested in a another template class.
My question is how could I make the whole node class a friend instead of specifying a specific member function? This might work failing at any other suggestions are most welcome.
Smallest reproducible code is:
#include <map>
template <class T, class T2>
struct relative_iterator : T {};
struct edge : public std::map<int, int>::iterator {};
using T_edge = edge;
class node {
public:
template <class T_iterable, class T_content>
class sibling_iterator : public relative_iterator<T_iterable, T_content>
{
public:
friend sibling_iterator<edge, T_edge> node::leftmost_output();
//..
};
static sibling_iterator<edge, T_edge> leftmost_output(); // <--move up
} ;
There are two ways to combat this:
Option 1
Move the definition of leftmost_output() above class sibling_iterator
Option 2
Make node a dependent name. If there is an alias to name which is dependent on T_iterable, then its lookup will be delayed to the time when class sibling_iterator<T_iterable, T_contents> is instantiated. The simplest way is to use standard utilities in the standard:
class sibling_iterator : public relative_iterator<T_iterable, T_content>
{
public:
static constexpr bool dependent_true = std::is_same<T_iterable,T_iterable>::value;
using dependent_node = typename std::enable_if<dependent_true, node>::type;
friend sibling_iterator<edge, T_edge> dependent_node::leftmost_output();
};
Option 2.5
But, if you prefer to define your own solution, you can define a dependet_type<T, Dependent> helper:
template <class T, class Dependent>
struct dependent_type
{
using type = T;
};
template <class T, class Dependent>
using dependent_type_t = typename dependent_type<T, Dependent>::type;
And use it:
template <class T_iterable, class T_content>
class sibling_iterator : public relative_iterator<T_iterable, T_content>
{
public:
using dependent_node = typename dependent_type<node, T_iterable>::type;
friend sibling_iterator<edge, T_edge> dependent_node::leftmost_output();
//..
};
I think that this is the best alternative, since it requires less changes to the existing code-base.
Option 2.5.5
I would have written a shorter variant:
friend sibling_iterator<edge, T_edge> dependent_type_t<node, T_iterable>::leftmost_output()
This looks perfect, since it requires minimal changes to the source code. I would have written it, had it not made the compiler crash:
fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'msc1.cpp', line 1469)
I am getting this error:
error C2039: 'leftmost_output': is not a member of 'mv::graph::node'
[...]
However, leftmost_output() is a member of node.
The definition of node is appended below (see about 3/4 of the way
down):
Apparently, the VC compiler doesn't find the definition of node, as it refers to something in a different scope. Try moving the friend declarations below the definition of the nested node class.
I'm trying to implement a kind of CRTP (if I well understand what it is) with multiple inheritance.
My main goal is to have a unified way to access list of instances of each subclass.
May problem seems to reside in the namespace utilization.
Here is the code of the simplest version :
http://ideone.com/rFab5
My real problem is more similar to :
http://ideone.com/U7cAf
I have an additional warning using clang++ :
test.cpp:28:63: warning: static data member specialization of 'instances' must originally be declared in namespace 'NS1'; accepted as a C++0x extension [-Wc++0x-extensions]
template <> std::list<NS1::Derived*> NS1::Base<NS1::Derived>::instances;
^
test.cpp:15:34: note: explicitly specialized declaration is here
static std::list<T*> instances;
Problem has been updated since it does not behave the same using namespaces.
Problem re-edited to post code on Ideone
The problem is that you've tried to define the list variable wrong. You need to provide a definition for Base, in general- you don't just define it for the one part that happens to be Derived's subclass, unless it's an explicit specialization.
template<typename T> std::list<T*> NS1::Base<T>::instances;
http://ideone.com/Vclac
Compiles with no errors. There are no intermediates or anything like that required.
Changing Base() and Intermediary() to Base<U>() and Intermediary<Derived> in the constructors makes the code OK for GCC.
There is no reason to change the definition of instances in the second case: the template is identical as the first situation.
Afaik, you got the following options.
First, if Intermediate is always templated on the derived type, you don't need a list for it, because it will never be the most derived type. If it could be templated on other types / not be derived, you can add a defaulted non-type bool template parameter like so:
template<bool, class A, class B>
struct select_base{
typedef A type;
};
template<class A, class B>
struct select_base<false,A,B>{
typedef B type;
};
template<class T, bool IsDerived = false>
class Intermediate
: public select_base<IsDerived,
Base<T>,
Base<Intermediate<T> >
>::type
{
// ...
};
// derived use
class Derived : public Intermediate<Derived, true>
{
// ...
};
// non-derived use:
Intermediate<int> im;
If the intermediate class is not templated and does not already derive from Base, you need to derive from Base again in the most derived class:
class Derived : public Intermediate, public Base<Derived>
{
// ...
};
The big problem comes when the intermediate also derives from Base but is not templated. You can add a defaulted derived type, but that would make the non-derived use a bit more ugly:
#include <type_traits> // C++0x, use std::
//#include <tr1/type_traits> // C++03, use std::tr1::
struct nil_base{};
template<class Derived = nil_base>
class Intermediate
: public select_base<std::is_same<Derived,nil_base>::value,
Base<Intermediate<Derived> >, //
Base<Derived>
>::type
{
// ...
};
// derived use now without boolean flag
class Derived : public Intermediate<Derived>
{
// ...
};
// non-derived use a bit uglier
Intermediate<> im;
// ^^ -- sadly needed
The following compiles OK with MinGW g++ 4.4.1, MSVC 10.0, and Comeau Online 4.3.10.1:
#include <list>
template <class T>
class Base
{
protected:
Base()
{
instances.push_back(static_cast<T*>(this));
}
private:
static std::list<T*> instances;
};
template <class U>
class Intermediary : public Base<U>
{
protected:
Intermediary()
:Base<U>()
{
}
};
class Derived : public Intermediary<Derived>
{
public:
Derived()
:Intermediary<Derived>()
{
}
};
template<class Derived> std::list<Derived*> Base<Derived>::instances;
int main()
{}
The instances definition is copied verbatim from your question.
I say as Isaac Newton, I frame no hypotheses!
Cheers & hth.,
I am writing a small class, the class is basically a factory for the C class, but I want other classes to be able to access some of the methods.
template<class C>
class CFactory {
public:
friend class C;
};
This should make the fields of CFactory available to the class C, but the compiler thinks otherwise.
I'm getting the following two errors using gcc on a mac.
error: using template type parameter 'C' after 'class'
error: friend declaration does not name a class or function
Can anyone tell me what I'm doing wrong and how to get et right?
Unfortunately, in my understanding, this isn't allowed in current standard.
§7.1.5.3/2 says:
[Note: ... within a class template
with a template type-parameter T, the
declaration
friend class T;
is ill-formed. -end note]
On a related note, this restriction seems to be removed in C++0x
(§11.3/3 in N3290).
Incidentally, MSVC may allow this if we write simply friend T;.
Ise's response is correct -- Comeau's FAQ contains a question concerning this issue in more detail.
However, perhaps you can try an extra template indirection that might work? Something like this:
template <typename T>
struct FriendMaker
{
typedef T Type;
};
template <typename T>
class CFactory
{
public:
friend class FriendMaker<T>::Type;
};
This seems to only work with gcc 4.5.x however so I wouldn't rely on it.
C can be anything - int, double, etc. and they are not classes. In general, this class C is not class. And you cannot have something like:
class A
{
friend class int;
//..
};
One more reason to prefer typename, instead of class when using templates
Can you please tell me, what am I missing?
template <class T> struct Base
{
T data;
Base(const T &_data):data(_data) { }
};
template <class T> struct Derived : Base<T>
{
Derived():Base(T()) {} //error: class 'Derived<T>' does not have any field named 'Base'
};
template <class T> struct Derived : Base<T>
{
Derived():Base<T>(T()) {}
};
There's still the question: Who's right? GCC is right here. Unqualified name lookup does not look into dependent base classes, hence will not find Base in the scope of Base<T>. You can change your code to the following Standard conformant variant too
Derived():Derived::Base(T()) {}
If I remember correctly, this is only supported by GCC4.5 though. Earlier versions didn't implement injected class name lookup properly.
Example:
template<class T>
class Base {
public:
Base();
friend class T;
};
Now this doesn't work... Is there a way of doing this?
I'm actually trying to make a general class sealer like this:
class ClassSealer {
private:
friend class Sealed;
ClassSealer() {}
};
class Sealed : private virtual ClassSealer
{
// ...
};
class FailsToDerive : public Sealed
{
// Cannot be instantiated
};
I found this example on this site somewhere but I can't find it... (here)
I know there are other ways of doing this but just now I'm curious if you actually can do something like this.
It is explicitly disallowed in the standard, even if some versions of VisualStudio do allow it.
C++ Standard 7.1.5.3 Elaborated type specifiers, paragraph 2
3.4.4 describes how name lookup proceeds for the identifier in an
elaborated-type-specifier. If the
identifier resolves to
a class-name or enum-name,
the elaborated-type-specifier introduces
it into the declaration the same
way a simple-type-specifier introduces
its type-name. If the identifier resolves
to a typedef-name or a
template type-parameter,
the elaborated-type-specifier is
ill-formed. [Note: this implies that,
within a class template with a
template type-parameter T, the
declaration friend class T; is
ill-formed. ]
I recognize the code above as a pattern to seal (disallow the extension of) a class. There is another solution, that does not really block the extension but that will flag unadvertidly extending from the class. As seen in ADOBE Source Library:
namespace adobe { namespace implementation {
template <class T>
class final
{
protected:
final() {}
};
}}
#define ADOBE_FINAL( X ) private virtual adobe::implementation::final<T>
with the usage:
class Sealed : ADOBE_FINAL( Sealed )
{//...
};
While it allows extension if you really force it:
class SealBreaker : public Sealed, ADOBE_FINAL( Sealed )
{
public:
SealBreaker() : adobe::implementation::final<Sealed>(), Sealed() {}
};
It will restrict users from mistakenly do it.
EDIT:
The upcoming C++11 standard does allow you to befriend a type argument with a slightly different syntax:
template <typename T>
class A {
// friend class T; // still incorrect: elaborate type specifier
friend T; // correct: simple specifier, note lack of "class"
};
I found a simple trick to declare template parameters as friends:
template < typename T>
struct type_wrapper
{
typedef T type;
};
template < typename T> class foo
{
friend class type_wrapper < T>::type
}; // type_wrapper< T>::type == T
However I do not know how this could help to define an alternative version of a class sealer.
Do you really need to do this?
If you want to prevent someone from deriving from your class, just add a comment and make the destructor non-virtual.