|
Why Virtual constructors are not allowed in C++??
|
|
|
|
|
Because virtual constructor are simply useless ! When constructing an object, the compiler knows exactly which object it needs to create (as opposed to the destructors). Take the following example (CChild1 and CChild2 both derive from CBase):
CBase* pData = new CChild1;<br />
CBase* pData2 = new CChild2;<br />
delete pData;<br />
delete pData2;
If you look at the above example, when creating pData and pData2, the compiler knows explicitly the type of the object being created (new CChild1 or new CChild2). But when you delete the object, the compiler doesn't know it explicitly, thus requiring a virtual destructor.
|
|
|
|
|
Hello,
The virtual keyword is used to say to the compiler that a pointer to an object might be a pointer to the base class instead of the class that was instantiated. This way the code looks in a virtual function pointer table for the right function to call. Since this mechanism is used to determine which member function should be called for the instance of a class, constructors cannot be virtual, since they create instances of classes.
If virtual constructors would be allowed, I figure that it would never be possible to instantiate a class with a virtual constructor, once a class has been derived from it. This would be far from nice.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
powerful explaination bob 
this worthes '5' ! ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
toxcct wrote: this worthes '5' !
Thanks! 
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Objects are created from the inside out, and destroyed from outside in.
class A {
public:
A( void );
virtual ~A( void );
virtual void F( void );
long DA;
};
class B : public A {
B( void );
virtual ~B( void );
virtual void F( void );
long DB;
};When you create an instance of A or B (or any class with a vtable) an pointer is placed at the start of the object. This pointer points to the class vtable.
e.g.
A a;
B b;
When b is created:
- memory is taken from the stack to hold size B object (12 bytes)
- vtable ptr is set to A vtable
- A::A() is called
- vtable ptr is set to B vtable
- B::B() is called
Setting the vtable ptr and calling the approriate constructor method can be considered an atomic action from our point of view.
From the above you can also see why you can't call virtual methods from a constructor and have them resolve forward - the vtable matches the class of the current constructor.
e.g.
A::A( void ) {
F();
}
This is part of the reason many frameworks adopt 2 part object construction:
1. create an instance, don't do anything important in constructor (init members)
2. call an Init() method that does the real construction - will resolve virtual methods properly
When b is destroyed:
- (vtable already set to B vtable)
- B::~B() is called
- vtable ptr is set to A vtable
- A::~A() is called
- memory is returned to stack
From the above you can also see why you can't call virtual methods from a destructor and have them resolve forward - the vtable matches the class of the current destructor.
e.g.
A::~A( void ) {
F();
}
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Can anybody tell me the difference between Abstract Base classes vs Interfaces??
|
|
|
|
|
If I remember correctly (I'm not sure anymore ) an abstract class is a class that contain at least one pure virtual function (a pure virtual function is a function that MUST be redefined in every class that inherits from the base class)
A pure virtual function looks like:
virtual void Test() = 0;
If you try to declare an instance of a class containing a pure virtual function, you will have an compile error saying that it cannot create an instance of the class due to a pure virtual function. It is used to 'forbid' an instanciation of the class (the class is just used as base class for another class and cannot be used 'alone').
Concerning the interface, also called pure abstract class, it's a class that contain only pure virtual functions and no member variables (for this last point, I think there are different opinions). So, the class itself is 'empty' because no functions has been defined.
Hope this helps
|
|
|
|
|
All the member functions in an Interface are pure virtual functions. But in the Abstract clas not like this, at least one pure virtual function must be there in a class to be called it as abstract base class.
|
|
|
|
|
if you are talking in a pure standard C++ point of view, Cedric already gave you the right answer.
now, if you heard with an interface, the keyword that we get as in java or in .NET languages, that's easy, such a thing don't exist.
but the difference would be easy to do :
when you inherit an abstract class, you get "as a gift" all the methods that are already implemented (and so, you don't have necessarily to write them if they do what you want).
you have to be laziness when you implement interfaces because you have to provide the code for each function...
to finish, abstract is not a C++ keayword, so sometimes, you could have difficulties to set your class abstract. that happened to me last month, and thanks to Mr Surhedayan, i now have it. the point is, when you have a base class that already provide some function bodies, that will not be overloaded in the children classes, you cannot set the function as pure virtual (with =0) ; and if you dont want the users to instanciate this class, the simple thing to do is to set the constructors protected...
cheers,
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Difference between Abstract classes and Interface
Little background:
A real world entity is represented in an OOP world as object. Objects are defined as classes any language.
A class defines objects in two aspects
Object's characteristics - Data Members
Object's functionality - Member functions
So, when the classes that are forced to provide implementations of the functions prototypes that are defined in either ‘interfaces’ or a ‘abstract class’ are not belonging to the same family (having some inherited parental characteristics from same parent directly or indirectly) but are rather related through some functionalities then 100% we will go with interface and if above said classes are belonging to same family then we should go with abstract class inheritance.
Also in case of inheritance as everything is a specialization of base parent object so there is allowance of providing some default definitions of the functions that are needed to be implemented further by specialized classes. This is not any way allowed in interfaces because implementing classes are not belonging to same family and are not any way related by characteristics.
An Example:
We have four real world objects:
• Airplane
• Bird
• Sparrow
• Eagle
We have one method that is a functionality of all above objects
• Fly
Now all objects share common functionality flying in air but differ in the mechanism they use to fly.
Also by close look we see that in general there is some common characteristics (as well as some common functionalities) between Sparrow and Eagle that can be a part of common class Bird (that has to be abstract because there is no real thing like bird!). But any way Airplane can't be related to Bird or its specialized classes Sparrow and Eagle.
So if want to expose fly functionality to outer world and want their implementations in Airplane and Sparrow (or any bird), so I will 100% go for Interface and Abstract classes will be a big NO!
But if we exclude Airplane want that fly functionality is exposed to outer world and its implementing classes are Bird, Sparrow and Eagle then 'Abstract Classes' is the best of best choice.
Happy programming! Please feel free in writing to me for further clarifications on other OOP concepts (im.himanshu2006@gmail.com)
Himanshu 
|
|
|
|
|
Hi there,
i would like to build a dll let`s say (DLL1) wich uses functions from a second dll (DLL2). The second dll is not jet available.(LNK2019 unresolved external symbol..). Is it possible to build the first dll in spite of the missing (DLL2)? and how does it work 
Thank you.
|
|
|
|
|
I would like to get help and suggestions from people who had worked with point and print protocol or other similar mechanism for easy installation of printer drivers in client.
Thanks & Regards
S.S.Palani
|
|
|
|
|
there's no need to reask the same question twice, even 17 minutes after... 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Dear friends,
Few days ago i developed an ActiveX control using MFC. The control was intened to be used by MFC dialog based clients. It is a windowless control. I preferred ActiveX control over simple COM dll, because it is easy to deal with the control events in MFC dialog based application. Just drop the control on the dialog, add a member variable, right click on it and handle events. So easy.
Now i want to use the functionality of this control in an application with no User Interface (i.e windows service). Is it possible to use the functionality exposed by ActiveX control in an application which provides no GUI container. If yes, then how ???
Ahsan
|
|
|
|
|
I would like to get suggestions and help from people who had worked with point and print protocol or other similar mechanism for easy installation of drivers.
Any suggestions will be appreciated
Thanks & Regards
S.S.Palani
|
|
|
|
|
Hey all.
I had a function that simply returned a LPCTSTR like
LPCTSTR getSomething() { return L"Hello There"; }
Using that in GetClassInfoEx, CreateWindowEx, etc worked fine. Though I tried to change it to a wstring like so
wstring getSomething() { return L"Hello There"; } or
const wstring getSomething() { return L"Hello There"; }
both compiled etc, though I always got memory access errors. I am just wondering why this is so, and what I can do to get around it. Mainly WNDCLASSEX.lpszMenuName = getSomething().c_str() would fall over.
Any ideas on how to do this correctlly? I did try casting it as a LPCTSTR as well with no luck.
Thanks all
|
|
|
|
|
|
Thanks, that looks like it may help. I'll have a read tonight
|
|
|
|
|
L"Hello There";
The above line says "Hello There" is wide character string, this means each character takes two bytes internally.
LPCTSTR should be pointed only to multibyte character strings (normal string where one character uses one byte internally).
So if you want to change a wide char string to multibyte char string you have to use any of the functions like wcstombs/WideCharToMultiByte ...
suhredayan
-- modified at 11:46 Tuesday 15th November, 2005
|
|
|
|
|
but LPCTSTR is compatible to both Unicode as well as ANSI
An LPCWSTR if UNICODE is defined, an LPCSTR otherwise
|
|
|
|
|
sunit5 wrote: but LPCTSTR is compatible to both Unicode as well as ANSI
yes, but not the two ones at the same time...
if UNICODE is not defined, LPCTSTR equals to a LPCSTR (which is a conct char*) and so, writing a wstring in it is a mistake !!
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
sunit5 wrote: but LPCTSTR is compatible to both Unicode as well as ANSI
An LPCWSTR if UNICODE is defined, an LPCSTR otherwise
Sunit5,
You are right. Thanks for correcting.
suhredayan
There is no spoon.
|
|
|
|
|
Unicode is defined, so the methods are expecting LPCWSTR not LPCSTR and the LPCTSTR is typedef of LPCWSTR. So going from wstring to LPCTSTR with unicode defined should be fine, right?
|
|
|
|
|
WNDCLASSEX.lpszMenuName = getSomething().c_str();
in the above line wstring returned is destroyed as soon as the execution passes to the next line. So the pointer to the wstring is invalid after that. But the WNDCLASSEX unaware of this still try to access this pointer.
Also from the function getSomething()use the following syntax to return:
return wstring(L"my wstring");
suhredayan
There is no spoon.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
