I'm writing a class (in a header file) that requires the following method:
static const foo::bar::clz* getSomething(void);
As I don't want to pollute the header file with an #include I choose to forward declare clz:
namespace foo
{
namespace bar
{
class clz;
}
}
But that's rather clumsy too. Is there a cuter way of doing this in C++11? Something along the lines of
class foo::bar::clz;
It would be nicer still if you didn't have to anticipate whether or not it's implemented as a class, struct or union. Have the C++11 grammarians covered that one too? (typename auto could be a candidate but I'm not an expert in C++ grammar).
The nested namespaces can't be avoided.
As for class vs. struct vs. union, partially: class and struct can be used interchangeably. If it's a union, it must be declared as such.
Related
I am working on several pretty heavy modules and I want to provide light-weight header with just some forward declarations. At the same time I am using std::type_index within the code in order to switch between different types and thus have to introduce this type in that "forward declarations" header.
For that I have two questions:
1) Is it so bad to make a forward declaration like
namespace std { struct type_index; }
2) If it is - are there any reasons not to inherit from it, like this:
// light.hpp:
struct TypeID;
// heavy_implementation.hpp
struct TypeID : std::type_index {}; // just empty body
Finally: if both options are error-prone and/or difficult to support for some reason - is there any way to transparently (without opaque types) introduce std:: type like type_index in light-weight header?
Not sure where to ask (feel free to close this if it is an inappropriate question) but I have not found anything on this specifically in C++17 proposals, neither this or this mentions it when dealing with the nested namespace addition to C++.
So currently this is the only option:
class A
{
public:
class B; //forward-declared INSIDE class/namespace
};
class A::B //defined outside
{
};
Will this be possible in C++17?
class A::B; //forward declared NESTED outside of parent class/namespace
class C
{
A::B *b;
};
and then either this (1) (as seems to be the proposal of nested namepsace definitions)
class A::B //definition of A::B without defining A
{
};
or this (2)
class A
{
public:
class A::B
{
};
};
or this [3]
class A
{
public:
class B;
};
class A::B
{
};
I suspect the definition of A::B without defining A first might not work though (although the proposal seems to allow it).
There's a proposal on the issue titled Forward declarations of nested classes P0289R0. However as you can see from the last Trip Report: C++ Standards Meeting in Jacksonville, February 2016, this proposal was pendent to proposals for which further work is encouraged. I'm quoting the verdict of the committee (Emphasis Mine):
This would allow things like X::A* to appear in a header without
requiring a definition for X to also appear in the header
(forward-declarations of X and X::A will be sufficient). EWG found the
use case compelling, because currently a lot of class definitions to
appear in headers only because interfaces defined in the header use
pointers or references to nested classes of the type. Several details
still need to be worked out. (For example, what happens if a
definition of X does not appear in any other translation unit (TU)?
What happens if a definition of X appears in another TU, but does not
define a nested class A? What happens if it does define a nested class
A, but it’s private? The answer to some or all of these may have to be
“ill-formed, no diagnostic required”, because diagnosing errors of
this sort would require significant linker support.)
IMHO lacking the ability to do forward deceleration of classes is a major hole in C++ language definition, which results in people using void* where a forward reference would be more safe.
Here is a workaround using namespaces:
Flatten the class structure you need to pre-declare
Use namespaces to separate the code
Do the forward deceleration using the namespaces
namespace ns1 {
namespace ns2 {
typedef class C * cptr_t; // declare both class and a pointer type
}}
ns1::ns2::C *cp; // use forward deceleration of the class
ns1::ns2::cptr_t cp; // use the typedef
This workaround does not solve the problem properly but may help in some situations.
I am trying to avoid including an auto-generated header (outside of my control), from inside my own headers. I therefore need to forward-declare a type Type that lives inside a namespace nm, which itself lives in the global namespace. Here is an example of MyHeader.h:
// My project defines two levels of nested namespaces
namespace foo { namespace bar {
namespace nm { struct Type; }
...
} }
Unfortunately this defines the new namespace foo::bar::nm and forward-declares the type foo::bar::nm::Type, which is not what I want. Ideally I would be able to forward-declare a type in the qualified namespace ::nm like this:
namespace foo { namespace bar {
namespace ::nm { struct Type; }
...
} }
My compiler complains I cannot use a qualified namespace here (using Intel ICC15 with C++11 settings). This forces me to put all such forward declarations at the beginning:
namespace nm { struct Type; }
namespace foo { namespace bar {
...
} }
In my case, this is inconvenient because I need to forward-declare many types and would prefer to do so alongside definitions of my own in various scattered places in my header. A workaround could be to constantly be "closing" and "re-opening" my nested namespace, which is not ideal.
Why can't I forward-declare a type in a qualified namespace ?
Because the C++ standard says so.
There is no real reason I know of. This is just not supported, probably, no one needed it and no one ever requested it. I see the benefit in your particular case, but since the forward declarations are expected to be provided in a separate file, you'd be better off by simply creating your own *_fwd.h with all the forward declarations inside it in the single namespace.
You can't because it's ambiguous. If you wrote:
extern int foo::bar;
Are you forward declaring an int named bar in namespace foo, or are you forward declaring an int named bar inside the class foo? There's no way for the compiler to know.
I have some code which looks like this:
namespace myLibrary
{
class A
{
public:
struct Nested
{
...
};
...
};
}
In some other parts of the code, I need to access A. Since I like readable code, I also like the using directive:
using myLibrary::A;
...
A a;
Now, at some point I also need to access my nested class, so I want to write something like this:
using myLibrary::A::Nested;
Obviously, the compiler can't know that this is a nested class and not a class member, and gives me an error:
error : using declaration can not refer to class member
What I can't understand is why this does not solve the problem:
using typename myLibrary::A::Nested;
The compiler still gives me the exact same error!
Luckily, I have alternatives:
// Using a typedef
typedef myLibrary::A::Nested Nested;
// Using the new C++11 syntax for type aliasing
using Nested = myLibrary::A::Nested;
but I'd like to understand why the using typename directive did not work. Does it not do what I think it does? Or is it not implemented by compilers? If it is the latter, is there a reason for it?
There is no "using typename directive". There are using-directives and using-declarations.
You're not using any using-directives, and they aren't relevant to the question in any case (they name namespaces, and can't use the typename keyword).
When using-declarations happen to appear within class templates, and happen to name dependent types, they have to use the typename keyword just like anything else that happens to be in a template and happens to name a dependent type.
For example:
template <typename A, typename R>
class Functor : public std::unary_function<A, R>
{
using typename std::unary_function<A, R>::result_type;
using typename std::unary_function<A, R>::argument_type;
public:
result_type operator() (argument_type) {}
};
In your situations, the namespace-declaration does not appear to be a part of the body of a class template, in fact it appears to be at namespace scope, in which case attempting to name a class member (doesn't matter if it's a type or a function or whatever) violates 7.3.3[namespace.udecl]/8
A using-declaration for a class member shall be a member-declaration
as the compiler correctly diagnosed with "error : using declaration can not refer to class member"
A using declaration referring to a namespace member A may only appear at namespace or local scope.
A using declaration referring to a class member Nested may only appear at class scope (along with member declarations), in a class derived from Nested. In fact, such using declarations are grammatically considered to be member declarations. They are used to adjust access qualification, and (with typename) to allow members of type-dependent bases to be used without qualification. These are specific use cases, so member using declarations are a bit specialized.
A nested class is a member of its enclosing class. You should generally avoid using class enclosures as a substitute for namespaces. Metaprogramming provides some exceptions to the rule, but in those cases you still wouldn't use using declarations, at least at namespace scope, because namespaces cannot be templated. Inheriting from an empty metaprogramming class is viable, but do mind the spaghetti.
The using directive is a different beast. It looks like using namespace and it links one namespace to another as a fallback path in name lookup.
This question already has answers here:
Why is "using namespace X;" not allowed at class/struct level?
(6 answers)
Closed 5 years ago.
I find that my C++ header files are quite hard to read (and really tedious to type) with all the fully-qualified types (which goes as deep as 4 nested namespaces). This is the question (all the answers give messy alternatives to implementing it, but that's not the question): Is there a strong reason against introducing scoped using-directive in structs and classes in the C++ language (while it's permissible to have scoped using-declaration in functions)?
e.g.
class Foo : public Bar
{
using namespace System;
using namespace System::Network;
using namespace System::Network::Win32::Sockets;
using Bar::MemberFunc; // no conflict with this
// e.g. of how messy my header files are without scoped using-directive
void FooBar(System::Network::Win32::Sockets::Handle handle, System::Network::Win32::Sockets::Error& error /*, more fully-qualified param declarations... */);
};
Since namespace is a keyword, I would've thought it's distinct enough to cause no conflict with the scoped using declaration such as Bar::MemberFunc.
EDIT: Read the question carefully ---> I've bolded it. Reminder: we're not discussing how to improve readability of the example here. Suggesting how scoped using-directive could be implemented (i.e. by means of adding keywords / constructs etc.) in the C++ language is NOT an answer (if you could find an elegant way to implement this using existing C++ language standards, then it would of course be an answer)!
Sometimes I do this to achieve almost the same effect:
namespace detail {
using namespace System;
using namespace System::Network;
using namespace System::Network::Win32::Sockets;
class Foo : public Bar
{
void FooBar(Handle handle, Error& error);
};
}
using detail::Foo;
Given that using declarations at class scope are not inherited, this could work. The name would only be valid inside that class declaration, or inside the declarations of nested classes. But I think it's sort of overloading the concept of a class with an idea that should be larger.
In Java and Python individual files are treated in a special way. You can have import declarations that inject names from other namespaces into the file. These names will (well, not exactly with Python, but it's too complicated to explain here) only be visible within that file.
To me that argues for this sort of ability not being tied to a class declaration, but given a scope of its own instead. This would allow injected names to be used in several class declarations if it made sense, or even in function definitions.
Here is an idea I prefer because it allows these things while still giving you the benefits of a class level using declaration:
using {
// A 'using' block is a sort of way to fence names in. The only names
// that escape the confines of a using block are names that are not
// aliases for other things, not even for things that don't have names
// of their own. These are things like the declarations for new
// classes, enums, structs, global functions or global variables.
// New, non-alias names will be treated as if they were declared in
// the scope in which the 'using' block appeared.
using namespace ::std;
using ::mynamespace::mytype_t;
namespace mn = ::mynamespace;
using ::mynamespace::myfunc;
class AClass {
public:
AClass(const string &st, mytype_t me) : st_(st), me_(me) {
myfunc(&me_);
}
private:
const string st_;
mn::mytype_t me_;
};
// The effects of all typedefs, using declarations, and namespace
// aliases that were introduced at the level of this block go away
// here. typedefs and using declarations inside of nested classes
// or namespace declarations do not go away.
} // end using.
// Legal because AClass is treated as having been declared in this
// scope.
AClass a("Fred", ::mynamespace::mytype_t(5));
// Not legal, alias mn no longer exists.
AClass b("Fred", mn::mytype_t);
// Not legal, the unqualified name myfunc no longer exists.
AClass c("Fred", myfunc(::mynamespace::mytype_t(5));
This is analogous to declaring a block for local variables in a function. But in this case you are declaring a very limited scope in which you will be changing the name lookup rules.
Maybe namespace alias?
namespace MyScope = System::Network::Win32::Sockets;
You can use a typedef inside the class declaration to achieve the same
class Foo : public Bar
{
typedef System::Network::Win32::Sockets::Handle Handle;
typedef System::Network::Win32::Sockets::Error Error;
void FooBar(Handle handle, Error& error);
};
The obvious benefit of namespaces is that they allow you to avoid naming conflicts. However, by introducing an entire namespace into a class declaration, this benefit is voided. It's entirely possible that a function in the System namespace could conflict with your own Bar::MemberFunc function. You even note this in your sample code when you added the comment "no conflict with this".
You obviously don't want to introduce entire namespaces into your class like this:
using namespace System;
using namespace System::Network;
using namespace System::Network::Win32::Sockets;
And you can't add more narrowly scoped using statements like this into a class declaration. Putting these directly into a class declaration is illegal.
using System::Network::Win32::Sockets::Handle;
using System::Network::Win32::Sockets::Error;
What you can do is use the unnamed namespace. So, your header file would look something like this:
namespace {
using System::Network::Win32::Sockets::Handle;
using System::Network::Win32::Sockets::Error;
}
class Foo : public Bar
{
using Bar::MemberFunc;
// clean!
void FooBar(Handle handle, Error& error /*, more declarations*/);
};
This has three distinct advantages.
The contents of entire namespaces are not introduced. This helps to more easily avoid naming conflicts.
You have a list, before your class declaration, of what your class depends upon to work correctly.
Your function declarations are clean.
Please correct me if I'm wrong; I only briefly tested this. Quickly wrote up an example, and it compiled.