|
oh , the example I have is more tricky:
D should call "the next M() of any parent above the child class C1"
Its vice versa to the virtual inheritance when you call the last one in the hierarchy ...
if I call
C1::anytest ()
{
B::M();
}
it goes "up" the hierarchy an calls the next found M();
in this case A::M()
But in class D´s DoSomething where I get a ptr to C1, or C2 ...
how can do it there?
|
|
|
|
|
Sorry, this was not clear from your initial question:
Quote: But now I wanna have that D calls the M() of C1´s base A
But you can do the same:
Implement a non-virtual function B::BM() which is called by the virtual function B::M() and so on. Then you can call the non-virtual functions AM(), BM(), and so on or the virtual M() function.
If you want to call the <code>M() function of the next upper class in the hierarchy, you need to know the real class of the passed argument during run-time. This requires that your classes support some kind of Run-time type information - Wikipedia, the free encyclopedia[^].
|
|
|
|
|
I think that here[^] you will find a solution, in fact, the same solution like Jochen said.
modified 11-Jul-16 8:10am.
|
|
|
|
|
Ah the joys of deep class hierarchy in C++ and OOP coding circa 1980-1990 
Probably too much danger in doing what should be done with that old code and using modern Composition over inheritance style.
It isn't going to be fun and C++ is going to fight you all the way as it will try to discourage that style.
Working with old code I feel your pain ... good luck.
In vino veritas
|
|
|
|
|
Hi,
i want develop one application which required the fast printing on dot matrix i saw one dos application it it's giving the printing very fast compared to windows
please suggest which technology should i prefer.
|
|
|
|
|
Print speed is a feature of the printer, not the operating system or programming language.
|
|
|
|
|
This is very general question 
Think about following topics:
- printer connection via: direct connection on parellel Centronics, ... WLAN network
- communication: whats between printer and programm code? direct commnication, printer driver, spooler, LAN network...
- how does operation system drivers communicate? do you use "Windows" printsystem which does Scaling, function mapping from window->draw to printer->draw?
the more comfortable you can code the slower the speed.
fastestway: use ASM and direct code the 8x8 bitmaps, send them to the printer, as we did in 1985
but think of: paper size, drawing, filling, fonts etc etc.
|
|
|
|
|
Sounds like you have the windows print driver sending the text out to the dot matrix printer in graphics form ... that means it will be printing the truetype fonts from windows. The old matrix printers are much faster if you just send the text in raw form and the printer uses it's internal font.
There is probably a setting on the windows print driver for the printer to turn the truetype font and print graphics output off.
You can also probably do it in code when you get the printer DC you should be able to set the printer capabilities before you start the print cycle in your code.
In vino veritas
|
|
|
|
|
Simple.
When printing, Windows transforms what you want to print into a graphic bitmap and then send the graphic to the dot matrix printer which can be very slow to process. This technique is used because anything that can be showed on screen can be printed.
With DOS, the app is directly sending commands to the printer, but is limited to printer internal fonts (Arial may be not available in the printer), sizes and other settings.
Another problem is that the app must know the commands of the printer.
So DOS os faster because it takes advantage of the printer internal capabilities. On windows, you can print in raw mode, but you are responsible of everything.
You can make windows print in the DOS fashion by installing the driver for for a Generic/Text Only printer. It will be fast but ugly.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Following problem:
I have a base class "B" in which there are some methods M1(),M2... Mn().
class B {
public
virtual void M1();
virtual void M2();
virtual void Mn();
};
now I have multiple derived classes:
class Ca1 : public B { .... };
class Ca2 : public B { .... };
class Can : public B { .... };
and again derived each from above
class Cb1 : public Ca1 { .... };
class Cb2 : public Ca2 { .... };
class Cbn : public Can { .... };
And at last another deriving step by
class Cc1 : public Cb1 { .... };
class Cc2 : public Cb2 { .... };
class Ccn : public Cb3 { .... };
Now the Question:
each of the derived last classes will override the methods M1, M2, M3 ...Mn... with the same functional content!
class Cc1 : public Cb1 {
virtual void M1() { } override;
virtual void M2() { } override;
...
virtual void M3() { } override;
};
class Cc2 : public Cb2 {
virtual void M1() { } override;
virtual void M2() { } override;
...
virtual void M3() { } override;
};
... this identical with identical code m1, m2 ... forall classes derived
Cc1, Cc2, ... Ccn!
How to best avoid to copy this M1, ... Mn block for method overriding into each derived class?
The existing code packed everthing into a macro and copied this into the classes
like
#define DRIVED_METHODS \
virtual void M1 { } \
and so on which results in horrible undebugable code!
Using multiple inheritance does not work:
class Cc1 : public Cb1, public CMpack
{};
class Mpack { void M1 {}; ... };
The only idea was to "map" each method to a class that collects these common methods
class Mcommon {
virtual void m_M1() { };
virtual void m_M2() {};
}
class Cc1 : public Mcommon
{
virtual void M1() { Mcommon::m_M1() ; } override
};I know that there must be a mistake in the whole design
but Im not allowed to change much because nobody knows why the anchestor did such a design and sideeffects on changing code may happen.
Have searched the web but best solution I got is the "Mapping"
parameters, return types in M1...Mn have been simplyfied to void, empty in the text above
|
|
|
|
|
Quote: each of the derived last classes will override the methods M1, M2, M3 ...Mn... with the same functional content!
What's the purpose of that?
|
|
|
|
|
some history I found out:
they had a collection of B*
typedef vector<B*> arrayB
then they stored Ca1* ... Can* in such a collection later they stored Cc1* ... Ccn* in such a collection because all derived from B ...
arrayB1 my_collection;
my_collection.push_back(Cc1* ... )
this is valid because the Cc´s are derived from B
B<--Cc1 , ...
if it is a B* the B::M1() was called
if it is a Ca1*, ...Can* the B::M1() was called
if it is a Cb1*, ...Cbn* the B::M1() was called
But if it is a Cc1*, ...Ccn* the overloaded Cc1::M1() etc. of the derived classes were called and do something different than the B::M1()
I dont know further what its good for, but its the way it was it was implemented
|
|
|
|
|
OK, I misunderstood your original question.
Could you possibly insert another derivation layer?
Why the 'mapping' solution is not appealing?
|
|
|
|
|
Mapping means:
to copy the same method mapping declaration to each class Cc1 ... Ccn
so
class Cc1:
{ ... list of M1() ...Mn()- mappings }
class Cc2:
{ ... list of M1() ...Mn() mappings }
....
class Ccn:
{ ... list of M1() ...Mn() mappings }
this is lot of code ...
isn´t there any way to say:
class Cc1..n - overload "the punch of M1...Mn defined in a common set"
layer in between does not work because:
- Cc1...Ccn is derived from Cb1...Cbn
- Cc_::M1() used some data of Cc_
|
|
|
|
|
Quote: - Cc1...Ccn is derived from Cb1...Cbn
- Cc_::M1() used some data of Cc_
I don't get that. Either the methods are identical or not. If they are identical then they access variables with identical names.
|
|
|
|
|
sorry its tricky but:
Cc1::M1() is identical to Cc2::M1() ...
the only "data" some Mi() uses is the "this" pointer
Cc1::M1() { code m1 }
Cc2::M1() { code m1 }
... etc..
Cc1::M3() { f_calculate(this); ... }
Cc2::M3() { f_calculate(this); ... }
...
|
|
|
|
|
Since Cc1::M1 is identical to Cc2::M1, both Cc1 and Cc2 could inherit M1 from an intermediate class.
|
|
|
|
|
Problem is inheritance to base of Cc1 Cc2 etc
B<-Ca1<-Cb1<-Cc1
B<-Ca2<-Cb3<-Cc2
if I use an intermediate class e.g D and declare D:M1()
then following problem arises:
class B { virtual M1() };
class Ca1 : public B
class Cb1 : public Ca1
class D : { virtual M1() } ;
class Cc1: public Cb1 , public D
class Cc2 : public Cb2 , public D
...
if I call now x->M1() with x is a Cc1*
which method will be used? Does D::M1() overload B::M1(), what I like to have?
|
|
|
|
|
sorry its tricky but:
Cc1::M1() is identical to Cc2::M1() ...
the only "data" some Mi() uses is the "this" pointer
Cc1::M1() { code m1 }
Cc2::M1() { code m1 }
... etc..
Cc1::M3() { f_calculate(this); ... }
Cc2::M3() { f_calculate(this); ... }
...
modified 5-Jan-17 10:54am.
|
|
|
|
|
The code in that form usually had a function to push/pull the class or object into and back off a stream. You would know the process if you are familiar with C# as serialization.
Microsoft has provided a bit more support and safety doing in C++ with MFC and the DECLARE_SERIAL macro which is the same as your MACRO.
Serialization: Making a Serializable Class[^]
It's still pretty much done the same way, you should have two constructors on the objects one of which has no parameters?
Just look into the code and check if the serialization is still used?
In vino veritas
|
|
|
|
|
?? stream?
don´t understand because I don´t us a stream
but do ou mean, that these horrible MFC macros came up because of th same problem?
|
|
|
|
|
What is written looks very much like the way you do serialization in C++
Serialization - Wikipedia, the free encyclopedia[^]
Read the article there are a number of reasons why you may want to serialize code from transmission thru, time based processing thru to encryption protection of code.
You will note within the article they talk about C and C++ not having serialization but you can do it with a sort of standard form. Your code looks to me like that standard form. MFC has the same setup because it has serialized classes and even that is discussed in the wiki article.
Note MFC's main reason for serialization: "The technique is called differential execution. It is useful in the programming of user interfaces whose contents are time-varying — graphical objects can be created, removed, altered, or made to handle input events without necessarily having to write separate code to do those things."
You were saying you don't know why the original code was written like that and they won't let you change it. If you need the serialization it would indeed break the program if you write it a different way.
So I am suggesting you check if the code is indeed doing serialization. If it is and that serialization is still needed you can not change it even if you wanted to.
In vino veritas
modified 9-Jul-16 0:34am.
|
|
|
|
|
maybe I got now what you talk about
"Changing the class is not possible when transfered via serial... because of reconstruction is dependent of class structure"?
OK, this doesnt happen here, there is an extra struct that holds data to store and load.
What I know is, that the code was extended within years, adding more and more features to the software. The derived classes have more features and do some different calculations
e.g. B::M1() ... used in B, Ca1, Cb1 also Ca2, Cb2 ... ect is different to Cc1::M1(), Cc2::M1() ... etc.
|
|
|
|
|
an example:
We have animals, cats and dogs
class animal()
{
OpenMouth() ;
breath_in();
breath_out();
}
class cat() : public animal
{
play_with_wool();
}
class dog() : public animal
{
hunt_cats();
}
class mops1() : public dog
{
get_fat_and_fart()
}
class mops2() : public dog
{
get_fat()
}
class greyhound1() : public dog
{
run()
}
class specialdog() : public dog
{
run_fast()
}
now we want to extent _some_ dogs to know how to barf()
for barf() we need some unctions of animal() (not all)
barf() { breath_in(); OpenMouth(); dosomething(); }
How can we add barf() to some (eg. 20 different dogs, and also some wolfs) without changing parent class structure?
class greyhound1() : public dog
{
run()
barf();
}
class specialdog() : public dog
{
run_fast()
barf();
}
class greywolf() : public wolf
{
barf();
}
and next step: we have not only barf() we have 20 new extends for these aimals.
It would mean: add these 20 functions to each animal seperately?
|
|
|
|
|
If I understood the question, the best method is using macro at header in derived classes and implementation in those cpp side (these must be different right?).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
