So I was just happily going along defining a new class when this happend:
class Thing : public OtherThing
{
public:
Thing : public OtherThing();//here
};
I really have no idea why visual assist/studio did this and i've never seen it before so really my question is what does it mean?
Just for the sake of clarity I would normally define the same class like this:
class Thing : public OtherThing
{
public:
Thing();
};
The public keyword is defined in 2 contexts:
Deferring access to members of a base class to the access level they were declared with:
When a class uses public member access specifier to derive from a base, all public members of the base class are accessible as public members of the derived class and all protected members of the base class are accessible as protected members of the derived class (private members of the base are never accessible unless friended)[source]
Specifying the access level for all members declared following this specifier
Public members form a part of the public interface of the class (other parts of the public interface are the non-member functions found by Argument-Dependent Lookup).
A public member of a class is accessible everywhere.[source]
Since the code you have demonstrated is not declaring inheritance (1) or specifying member access (2) it is an invalid use of the keyword and should not compile.
I see your statement that this compiles for you, but indeed this cannot compile in gcc: http://ideone.com/Z33viJ or in Visual Studio 2015, which you can validate by going here: http://webcompiler.cloudapp.net/ The only plausible explanation that I can come up with is there is a malfunction in which the code your editor is showing you is not what has been written to the file and thus is not what's being compiled. If this is the case perhaps a restart of Visual Studio would solve the problem.
Related
In vscode how to check if a method is private, public or protected in editor?
If there is a solution to show this in outline that will help too.
EDIT: I can check the header file to see access level, but I want to see it in cc file in popup or in outline.
C++ access is defined by sections.
A class example
class Example{
public:
//anything that is public goes here
protected:
//anything protected goes here
private:
//anything private goes here
};
The default access is private.
You do not need to write all of these sections, nor in this order but it is generally good to write it like this public, protected, private.
It doesn't matter if you are in vscode, visual studio or code::blocks, the editor itself doesn't affect the code.
To access methods and fields from class you have 3 options
Public members can be access everywhere
Protected members act like private for every other scenario except for inherited classes. The classes that inherit base class can access protected fields and methods.
Private members of the class can only be accessed by that class itself.
I was looking at inheritance concepts in http://www.geeksforgeeks.org/inheritance-in-c/. I was confused with few sentences written by the author. At one place author says
If we derive a sub class from a public base class. Then the public
member of the base class will become public in the derived class .......
That means do we have something like public class in C++? Also below table from the article indicates that there is a concept of public/Protected class.
I looked at few other SO posts (Use of "Public" in a derived class declaration?) and found no reference to Public, Private or protected class itself. The post https://stackoverflow.com/questions/4792614/making-classes-public-to-other-classes-in-c talks of public, but by means of header file.
The Public, Protected and Private keywords are the visibility labels in C++. There is no public, protected and private class type in c++ (like Java). These three keywords are also used in a completely different context to specify the visibility inheritance model.
The table given below lists all of the possible combinations of the component declaration and inheritance model presenting the resulting access to the components when the subclass is completely defined.
It reads in the following way (take a look at the first row):
if a component is declared as public and its class is inherited as
public the resulting access is public.
Have a look at an example below:
class Super {
private: int x;
protected: int y;
public: int z;
};
class Sub : protected Super {};
The resulting access for variables y, z in class Sub is protected and for variable x is none.
NOTE:
The lack of a modifier yields private.
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.
With regards to a class, what does an interface mean? I think it refers to all the public functions of the class. Am I correct or does it mean something else?
I keep hearing it a lot but never quite noticed the explicit definition.
This one's the real question. What does it mean for a derived class to retain the interface of the base class it's derived from? I think it means that the public functions in the base class must be public in the derived class as well (which will be the case in public and protected inheritance). Am I mistaken?
Yes, the interface of a class is the collection of its visible member functions to the outside world, i.e. its public member functions. Some also include member variables in the interface, but it is not usually common to have public member variables (unless declared static). Most often, interfaces are implemented via abstract base classes. This is in contrast to Java, which has a different keyword for specifying interfaces.
Retaining the interface means having the public member functions in the base class visible across the class hierarchy. Also, you can override virtual functions so you get polymorphic behaviour, keeping the common interface. Note that only public inheritance preserves the interface, protected and private do not. Another way of failing to retain an interface is via name hiding in C++. Example: re-declaring Base::f(int) as Derived::f(float,float). In this case, the Base::f(int) is not longer visible in Derived, unless via a using Base::f; statement.
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