Using C++11 is it possible to specify class special member functions as defaulted and deleted?
I'm using Visual Studio 2012 version 11.0 and trying to set some class constructor as defaulted. Need to say this is abstract class and IDE underscores this code part as wrong. Also when I modify this class not to be abstract, the situation is the same.
class IProgressObserver {
public:
IProgressObserver() =default;
virtual ~IProgressObserver(){}
virtual void reportProgress(void* reporter,
std::int32_t done,
std::int32_t total) = 0;
};
You can default special member functions in C++11, but VS11 does not support that.
Support has been added in VS12 (2013) -- but not for move constructors / assignment-operators.
See MSDN: Support For C++11 Features
Related
I want to make a class in my Rhapsody model non-copyable, but
don't have the boost library available (from which I would just derive)
nor can I use the C++11 way of disabling the default generated copy ctor and copy assignment op (because I would need to manipulate the function signature, which AFAIK is not directly possible)
=> so I am doing it the old fascioned way.
What I need from Rhapsody:
In this context, I want to generate only a declaration for copy ctor and copy assignment op - I don't need the implementation.
Is this even possible?
Things that I considered:
I haven't found any helpful property yet.
Mapping only the specification of a member function to a file object won't prevent Rhapsody from generating the empty function body into an implicitly created file object (that I don't need nor want).
I would suggest a stereotype approach:
Create a NonCopyable base class, as, for example, described by #Dennis.
Create a stereotype, you can, for example, name it <<non-copyable>>.
a) Set the stereotype property CPP_CG::Class::AdditionalBaseClasses to NonCopyable (the name of the base class created above).
b) Make the stereotype applicable to classes.
Finally, add the <<non-copyable>> stereotype to all classes that shall be non copyable.
Write a private copy ctor and opertor:
class NonCopy {
// These private versions of the copy constructor
// and operator will signal to the compiler to
// prevent automatic generation.
NonCopy(const NonCopy& other);
const NonCopy& operator=(const NonCopy& other);
public:
// Your public ctors
NonCopy(int a);
}
You can look at the boost version of the non-copyable interface for a more complete example.
This can be done (at least in Rhapsody 8.2.0) using a combination of properties of the constructor. First, set the CG::Operation::Generate property to Specification, then set the CPP_CG::Operation::PostDeclarationModifier to = delete. (Both of these are set at the constructor level). This ensures that no function body is created, and also allows usage of the delete keyword via modification of the function signature.
I have not found a way to write this in code and have Rhapsody interpret it correctly while roundtripping, though.
I'm trying to migrate a project from to c++11 in Visual Studio. I fixed a number of issues, but there's one remaining which I can't seem to crack with MFC:
error C2248: 'CObject::CObject' : cannot access private member declared in class 'CObject' (file.cpp)
: see declaration of 'CObject::CObject'
: see declaration of 'CObject'
This diagnostic occurred in the compiler generated function 'CList<ParameterValue,ParameterValue &>::CList(const CList<ParameterValue,ParameterValue &> &)'
This is code that hasn't changed on our end and has been compiling fine when targeting the Visual Studio 2010 toolset. From what I could gather it doesn't seem like the definition of CObject has changed either which makes it all the stranger.
There's other similar questions reported here, but I couldn't find a solution to my problem there. In most other cases it would appear the issue comes from a lack of public default constructors, Copy constructors, or assignment operators.
Our class that extends CList however provides public versions of all these, and ParameterValue does not inherit from CObject.
class __declspec(dllexport) GParameterValueList : public CList<ParameterValue, ParameterValue&>
{
// ParameterValue is a struct that DOES NOT inherit from CObject (or anything)
public:
GParameterValueList();
GParameterValueList(const GParameterValueList& SrcList);
GParameterValueList& operator=(const GParameterValueList& SrcList);
}
Any help would be appreciated.
P.S.Our implementation is exported into a DLL, I'm wondering if that might be causing some conflicts?
Edit: Not a duplicate of error using CArray or error using CArray -> in these the CObject derived classes were missing public default and copy constructors. As described above, this is not the case with our code.
I think the problem is in your ParameterValue class. Try to declare public constructors in there, including the default constructor.
It seems to me that the CList tries to call the ParameterValue constructor somewhere, but the former can't because the latter is private.
Alternatively, try to use a List of Pointers, like CList<ParameterValue*, ParameterValue*&>.
Another alternative is to use a std container instead of CList.
I am writing a custom Exception class, with some additional features over the std::exception one. I added a custom constructor Exception(std::string details) : details(details) {} to my Exception class.
Later, when I extend the Exception class, with the class FileNotAccessibleException, and throw it, I get a compile error saying no matching function for call to ‘FileNotAccessibleException::FileNotAccessibleException(std::basic_string<char>)’ When I then add a method FileNotAccessibleException(std::string details) : Exception(details) {} to my class, it does work fine.
Is there no way to make the constructor work, without having to redefine the constructor for all my classes?
You can inherit the constructors of the base class with a using declaration:
class FileNotAccessibleException : public Exception
{
public:
using Exception::Exception;
...
};
See more on inherited constructors on Bjarne Stroustrup's C++11 FAQ.
Note: this does not apply to pre-C++11 implementations, and was one of the last C++11 language features to be added to popular compilers such as G++ and CLANG.
We use doxygen to document our classes. I would like to explicitly document that a class has generated constructors and/or destructors, to indicate that I've thought about it and decided that e.g. copying using the generated copy constructor is safe. However, the constructor/destructor is not declared and hence doxygen does not know to which function the documentation belongs. Are there ways to make doxygen include function comments even if the function is never declared?
//! The Foo class documentation
class Foo {
//! #fn Foo(const Foo&)
//! Generated copy constructor OK to use
//! method documentation
void method();
}
Also I wouldn't want to write the signature of the generated files at all.
I guess my other option is to just describe it in the class header. Are there any other approaches?
If you use the = default notion introduced in C++0x for your default generated constructors, doxygen should pick them up
http://www2.research.att.com/~bs/C++0xFAQ.html#default
I don't know if doxygen has implemented the C++0x new keywords and patterns yet though
I have a value class according to the description in "C++ Coding Standards", Item 32. In short, that means it provides value semantics and does not have any virtual methods.
I don't want a class to derive from this class. Beside others, one reason is that it has a public nonvirtual destructor. But a base class should have a destructor that is public and virtual or protected and nonvirtual.
I don't know a possibility to write the value class, such that it is not possible to derive from it. I want to forbid it at compile time. Is there perhaps any known idiom to do that? If not, perhaps there are some new possibilities in the upcoming C++0x? Or are there good reasons that there is no such possibility?
Bjarne Stroustrup has written about this here.
The relevant bit from the link:
Can I stop people deriving from my class?
Yes, but why do you want to? There are two common answers:
for efficiency: to avoid my function
calls being virtual.
for safety: to ensure that my class is not used as a
base class (for example, to be sure
that I can copy objects without fear
of slicing)
In my experience, the efficiency reason is usually misplaced fear. In C++, virtual function calls are so fast that their real-world use for a class designed with virtual functions does not to produce measurable run-time overheads compared to alternative solutions using ordinary function calls. Note that the virtual function call mechanism is typically used only when calling through a pointer or a reference. When calling a function directly for a named object, the virtual function class overhead is easily optimized away.
If there is a genuine need for "capping" a class hierarchy to avoid virtual function calls, one might ask why those functions are virtual in the first place. I have seen examples where performance-critical functions had been made virtual for no good reason, just because "that's the way we usually do it".
The other variant of this problem, how to prevent derivation for logical reasons, has a solution. Unfortunately, that solution is not pretty. It relies on the fact that the most derived class in a hierarchy must construct a virtual base. For example:
class Usable;
class Usable_lock {
friend class Usable;
private:
Usable_lock() {}
Usable_lock(const Usable_lock&) {}
};
class Usable : public virtual Usable_lock {
// ...
public:
Usable();
Usable(char*);
// ...
};
Usable a;
class DD : public Usable { };
DD dd; // error: DD::DD() cannot access
// Usable_lock::Usable_lock(): private member
(from D&E sec 11.4.3).
If you are willing to only allow the class to be created by a factory method you can have a private constructor.
class underivable {
underivable() { }
underivable(const underivable&); // not implemented
underivable& operator=(const underivable&); // not implemented
public:
static underivable create() { return underivable(); }
};
Even if the question is not marked for C++11, for people who get here it should be mentioned that C++11 supports new contextual identifier final. See wiki page
Take a good look here.
It's really cool but it's a hack.
Wonder for yourself why stdlib doesn't do this with it's own containers.
Well, i had a similar problem. This is posted here on SO. The problem was other way around; i.e. only allow those classes to be derived that you permit. Check if it solves your problem.
This is done at compile-time.
I would generally achieve this as follows:
// This class is *not* suitable for use as a base class
The comment goes in the header and/or in the documentation. If clients of your class don't follow the instructions on the packet, then in C++ they can expect undefined behavior. Deriving without permission is just a special case of this. They should use composition instead.
Btw, this is slightly misleading: "a base class should have a destructor that is public and virtual or protected and nonvirtual".
That's true for classes which are to be used as bases for runtime polymorphism. But it's not necessary if derived classes are never going to be referenced via pointers to the base class type. It might be reasonable to have a value type which is used only for static polymorphism, for instance with simulated dynamic binding. The confusion is that inheritance can be used for different purposes in C++, requiring different support from the base class. It means that although you don't want dynamic polymorphism with your class, it might nevertheless be fine to create derived classes provided they're used correctly.
This solution doesn't work, but I leave it as an example of what not to do.
I haven't used C++ for a while now, but as far as I remember, you get what you want by making destructor private.
UPDATE:
On Visual Studio 2005 you'll get either a warning or an error. Check up the following code:
class A
{
public:
A(){}
private:
~A(){}
};
class B : A
{
};
Now,
B b;
will produce an error "error C2248: 'A::~A' : cannot access private member declared in class 'A'"
while
B *b = new B();
will produce warning "warning C4624: 'B' : destructor could not be generated because a base class destructor is inaccessible".
It looks like a half-solutiom, BUT as orsogufo pointed, doing so makes class A unusable. Leaving answers