|
Dear group,
I have to load all the dependent libraries of an ELF output file while it is loading.
SO for this i decided to write ELF parser to load the dependent libraries.
Please suggest me with a sample.
Thanks in advance,
Ravinder Are
Are
|
|
|
|
|
You need a Unix-oriented forum.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Google for readelf and then look at the source for it
Judy
|
|
|
|
|
There are large number of gamers who play lan based games using GG-framework. Even I play Warcraft with other guys on internet.
But GG (Now Garena) client software does not seem to add any adapter or
driver for creating the virtual lan. I used netstat to find out, there
are two 'ESTABLISHED' TCP connections when I log in to GG.
When one logs in to GG, one has to start the game through this client and viola! one can see all the game servers and one can play as if the other guys are on lan with him.
How this is possible? Anyone got ideas?
|
|
|
|
|
Hello everyone,
About the virtual function design pattern mentioned,
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4
I do not quite understand what does this statement mean "Assuming they're protected, they probably shouldn't be virtual: if the derived class doesn't like the behavior in one of them, it doesn't have to call that method." Any ideas?
I quote the whole paragraph here,
--------------------
Suppose you have the exact opposite situation from the previous FAQ, where you have a method whose overall structure is different in each derived class, yet it has little pieces that are the same in most (if not all) derived classes. In this case you'd put the overall algorithm in a public virtual that's ultimately defined in the derived classes, and the little pieces of common code can be written once (to avoid code duplication) and stashed somewhere (anywhere!). A common place to stash the little pieces is in the protected part of the base class, but that's not necessary and it might not even be best. Just find a place to stash them and you'll be fine. Note that if you do stash them in the base class, you should normally make them protected, since normally they do things that public users don't need/want to do. Assuming they're protected, they probably shouldn't be virtual: if the derived class doesn't like the behavior in one of them, it doesn't have to call that method.
--------------------
thanks in advance,
George
|
|
|
|
|
I think it means that if a function is not designed to be over-ridden by its derived classes, it should not be virtual.
|
|
|
|
|
Thanks followait,
From what I quoted, which part indicates "a function is not designed to be over-ridden", which type of functions mentioned in the quoted parts indicates "a function is not designed to be over-ridden"?
regards,
George
|
|
|
|
|
Yes. They represent (in class hierarchy designer mind) simple unit of common behaviour, for instance:
class Base
{
public:
virtual void do_things();
protected:
void do_common1();
void do_common2();
bool test_common();
};
class Derived: public Base
{
public:
virtual void do_things();
};
Base::do_things()
{
}
Derived::do_things()
{
do_something_specific();
do_common1();
do_something_else_specific();
if ( test_common() )
{
do_common2();
}
else
{
do_something_specific3();
}
}
If Derived class designer doesn't like do_common1 behaviour, he (or she) can replace it with another piece of code, specific of do_things implementation of Derived class. This help to keep the overall project architecture cleaner, because common behaviours remain unchanged through class hierachy, while changes happen inside methods deliberately designed for the purpose. Roughly speaking it is a granularity problem: keep little common behaviours invariant.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
What harm will be if we make the following 3 methods virtual? I think the design architecure is still clean as your sample without code change, right?
void do_common1();
void do_common2();
bool test_common();
regards,
George
|
|
|
|
|
George_George wrote: What harm will be if we make the following 3 methods virtual?
Actually no harm.
George_George wrote: I think the design architecure is still clean as your sample without code change, right?
Nope. In original design there is a (conventional) clean distinction between invariant pieces of (common used) code and methods designed to exploit polymorphism.
If you make the above methods virtual (and even if you don't change the remaining code) then you imply that polymorphism may happen on these little pieces of (common used) code. The developer examining Derived::do_things() method then should be aware that changes may are not only inside the method logic itself but also inside its 'elementary' commonly used blocks. This double-layered kind of polymorphism is not a mistake but doesn't contribute to project neatness.
BTW: As usual, this is going on my arrogant assumptions 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
So, you mean for the 3 non-virtual "common" methods, it means derived class and base class should share common code? So, making the 3 non-virtual "common" methods virtual will make developer confused about potential efforts to override and provide differences (polymorphism)?
regards,
George
|
|
|
|
|
George_George wrote: So, you mean for the 3 non-virtual "common" methods, it means derived class and base class should share common code?
They are made for that purpose.
George_George wrote: So, making the 3 non-virtual "common" methods virtual will make developer confused about potential efforts to override and provide differences (polymorphism)?
It makes more difficult to interpretate do_thing() actual behaviour.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
So, your answer and pattern to this question is, if code are common in both base and derived class, and derived class has no need to override it, do not make it virtual?
regards,
George
|
|
|
|
|
My answer to the question is slighty different: if small pieces of code are common in the hierarchy of classes (it applies mainly to complex class hierachies) then make those methods available to the whole class hierarchy (hence the base class is a good place for them) but don't make them virtual (if you don't need them, don't use them), leaving polymorphism be done in the right places, i.e. bigger methods (of course small and big tradeoff is subjective).
The above is, IMHO, the substance of the original text.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
A small confusion. I think whether or not making a method virtual is dependent on whether derived class needs to override it, and has nothing to do with whether the method is big or small.
Why do you making decision whether a method is virtual or not also based on whether the method is big or small? what is your trade-off?
regards,
George
|
|
|
|
|
George_George wrote: A small confusion. I think whether or not making a method virtual is dependent on whether derived class needs to override it, and has nothing to do with whether the method is big or small.
Well this is true. Neverthless whenever we're talking about little pieces of common code, IMHO we have two points to consider:
(1) such methods have little functionality, i.e. if you don't need it you can replace the call with few lines of code.
(2) such methods are shared by a relevant number of other methods, i.e. you can find calls to such methods here and there.
From this viewpoint, IMHO, the design is cleaner if such pieces of code remains unchanged.
But, I know, at the end, it is matter of taste.
George_George wrote: Why do you making decision whether a method is virtual or not also based on whether the method is big or small? what is your trade-off?
No. I make my decision based on the overall structure of the project and provided the points (1) and (2) hold for such 'helper' methods.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
Looks cool! You have made me clear about your points.
regards,
George
|
|
|
|
|
For mechanism, it's more flexible with an efficency tradeoff.
For semantics, the design will not be so clear.
Using virtual only when necessary will be a good choice considering efficiency and flexibility.
|
|
|
|
|
Thanks followait,
What is your trade-off? I think for the "little piece" common part, derived class can utilize it and overrides it, so why not make it virtual and protected?
regards,
George
|
|
|
|
|
In my opinion, a design would be better if it can guide the using of it, for example, it should prevent coders from overriding the functions that should not be overridden.
modified on Wednesday, March 19, 2008 8:57 AM
|
|
|
|
|
Thanks followait,
I think your points and answers to this question are, if code are common in both base and derived class, and derived class has no need to override it, do not make it virtual?
regards,
George
|
|
|
|
|
Simply, virtual function is invented for polymorphism.
In essence, a virtual function is an indirect call to a non-virtual function, so it can always replace a non-virtual function, with more flexibility and less efficiency.
|
|
|
|
|
Thanks followait,
1.
followait wrote: a virtual function is an indirect call to a non-virtual function
You mean through vtable?
2.
followait wrote: so it can always replace a non-virtual function
You mean virtual function has all the functions of a non-virtual function?
regards,
George
|
|
|
|
|
1.
Yes.
2.
Yes, but more.
|
|
|
|
|
Thanks followait,
Question answered.
regards,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
