|
The line between failure and success is so thin... 
|
|
|
|
|
I have this solution, does it help? You should try explaining your problem otherwise noone will be able to tell you if they can help or not, not to mention being willing to...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
i have problem with file sql someone can help me please
|
|
|
|
|
Would you be willing to give us a hint as to what the problem might be? Or are we supposed to guess?
I apologize, but my psychic powers aren't 100% right now.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
|
can anybody let me how to postpone implementation of abstract class methods
#include<iostream>
using namespace std;
class abstrs
{
public:
virtual int add(int i,int j)=0;
virtual int Substract(int i,int j)=0;
};
class derieved : public abstrs
{
public :
virtual int add(int i,int c)
{
return 100;
}
};
int main()
{
derieved dr;
int count=dr.add(12,34);
cout<<g;
}
vikas da
|
|
|
|
|
If you don't, you won't be able to create an instance of derived. Derived will still be abstract. You'll have to derive another layer and define Subtract there.
Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.
|
|
|
|
|
Thanks Tim,
so we need to have implementation of all methods defined in abstract class to the single derived class to instantiate the class.
am i right..?
vikas da
|
|
|
|
|
Yep - every pure virtual function in an abstract class needs to be implemented in a derived class or you won't be able to instantiate the derived class.
Cheers,
Ash
|
|
|
|
|
The best way of avoiding the need to implement member functions (C++ doesn't have methods) is to avoid deriving a class from an abstract class.
So the first thing to ask is... why are you writing code like you have in your main? Derived doesn't actually need to implement any abstract classes so just implement what you need to get your code compiling:
class adder
{
public:
int add( int i, int j ) const { return i + j; }
};
int main()
{
std::cout << adder().add( 12, 34 ) << std::endl;
}
You only need abstract classes as your code gets bigger and you want to start cutting down on the dependencies between lumps of code. You use abstract classes as a design tool to avoid most of your code needing to know what concrete types they're dealing with.
If on the other hand you've got an interface you need to implement to use a particular lump of code then you haven't got a lot of choice but to implement the member functions. You could take the Java route and implement a minimal class and then derive from that:
class adder
{
public:
virtual int add( int i, int j ) = 0;
};
class minimal_adder
{
public:
virtual int add( int, int ) { return 0; }
};
But that can turn into a maintenance nightmare (you have to look at two implementations to find out where a member function is implemented, not just one. It gets worse when some wit adds another level, then another...).
So the points here are:
- Don't use an abstract class until you need to, never do it "just in case" [1]
- When you create abstract classes try and create them from the existing interface of a concrete class. You'll at least know there's client code (and unit tests) ready to use your new abstract class against
- Only use Java style stub implementations as a last resort (some chunk of client code is expecting an interface with 30 member functions, half of which you have no idea what the contracts are)
Cheers,
Ash
[1] Needing to includes using one as a firewall between code you're writing and code your colleagues are writing. If you sit down with a co-worker that needs a service from code you're writing hack out a quick interface together, stub implement it for them and then take your time implementing it properly.
|
|
|
|
|
In addition to the replies here, even though you have to implement all abstract functions, there is still a chance you can get a 'Pure virtual function call' runtime error.
You can find an example here[^] and some additional info.
|
|
|
|
|
Thanks for all your replies
i got my answer...
have a nice time ...
vikas da
|
|
|
|
|
Can be prevented CD copy by intercepting the systen copy function?
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
I don't think so, but does ICopyHook work for you?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thanks! I'll work around it...
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
If you want illegally mess up the user system yes.
Remember what the US court say to Sony because of their rootkit: It is your software, but that's not your computer.
Intercepting a call inside an application for the use of that application is not an issue. Intercepting a call to globally modify the system behavior disabling system functionality the user payed (copy a CD is part of the OS functionality that have its license as well) it not legal nor moral.
If you want to prevent your software to be used illegally, use hardware dongul, license numbers, internet registration ... but don't alter the user's system behavior. It does not belong to you.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I yhink you're right, man ... Thanks!
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
Is it possible to support doc/view in MFC dll (regular/extension)
If i create a SDI application (container type) then can i do the same in mfc dll?
|
|
|
|
|
Of course,
an MFC DLL can export for example the main frame for an application
(with all needed classes inside)...
virtual void BeHappy() = 0;
|
|
|
|
|
Too fast for me
|
|
|
|
|
There is a trick (used by me)  :
1) typing "hello world" as an answer
2) editing of the answer
virtual void BeHappy() = 0;
|
|
|
|
|
Nice!  
|
|
|
|
|
If MFC dll exports mainframe then it can export a form dialog (CFormView) where this form dialog contains container data(coleclientitem,coledocument)
is there any example available?
|
|
|
|
|
Here[^] is an article from 1999 that is mainly still valid. Read through it. It's really not a difficult topic just to get it going.
|
|
|
|
|
Since you can export MFC classes from an extension dll, you can have your CDocument and CView derived classes in one and use them in your SDI/MDI application.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
