|
Richard
look at what happens When I turn optimazation off and check for an error no code is generated
for the if (hercgui_addr = NULL) one wierd complier
On aonther issue my assignment at work I was able to resolve the 800A30EC I think thats it
by Doing app.GetActiveWorkBook however txt file wasn't displayed in the workbook in fact
a worksheet wasn't loaded I was under the impression that OpenText loads a worksheet as well
Thanks
hercgui_addr = GetProcAddress(hutil_module,"hercgui_proc");
00000000013FD44B lea rdx,[string "hercgui_proc" (14D42B0h)]
00000000013FD452 mov rcx,rax
00000000013FD455 call qword ptr [__imp_GetProcAddress (14B7050h)]
if (hercgui_addr = NULL)
errcd = GetLastError();
|
|
|
|
|
if (hercgui_addr = NULL)
This sets the value of hercgui_addr to NULL, so it is little wonder that the generated code does not look correct.
|
|
|
|
|
Thanks once I referenced hercgui eith "=="
the optimized version genereted the "mov hercgui,rax"
Thanks again
|
|
|
|
|
I'm just trying to understand the Microsoft specific modifier __interface.
According to the MSDN, "__interface implies the novtable __declspec modifier."
However, when I try to mock up code to try an verify this, Visual Studio 2008 still suggests the vtable pointer is present?
__interface ISample
{
bool Next();
bool Prev();
};
class CSample : public ISample
{
public:
bool Next()
{
return false;
}
bool Prev()
{
return false;
}
};
Am I misunderstanding what MSDN is trying to convey or am I just doing something wrong. In a nutshell, just trying to see if it's possible to enforce interface rules without needing the vtable overhead if only deriving from __interface declarations. I understand that this would not be portable code.
|
|
|
|
|
I have to think hard about this every time I look at this type of problem. I think the answer is that ISample is never concrete so it doesn't need a vtable. There is a vtable in CSample. When you call either of the 2 methods through a pointer (either CSample* or ISample*), the vtable needs are met by the concrete class.
--
Harvey
|
|
|
|
|
Thanks for responding. I guess my confusion is if __interface hints to the compiler that the base class will never be instantiated, even though __interface supposedly makes the methods pure virtual, I was hoping that the interface rules were being enforced at compile time and the virtualness of the base class declarations would not propagate up to the derived class, unless of course the derived class explicitly declared something virtual. I know that kinda flies in the face of the normal rules for virtual but I was hoping there was a way to get interface rules enforcement without literally applying the virtual rules unless explicit outside of the interface.
I was hoping that CSample, in this case, would be treated at runtime like it did not have a base class and did not have any virtual methods, and thus the compiler would discard the vtable for it as well.
Is the vtable really needed (in this scenario)?
|
|
|
|
|
novtable is used in case of hardcore optimizations with "abstract" base classes are never instantiated. An interface is always abstract by definition.
To understande novtable first you have to understand a bit more about how a derived class is instantiated and initialized. Let me explain this with a simple example:
A
/ \
B C
/ \
D E
The above drawing is a class hierarchy and we will examine the instantiation of the D class. Lets assume that A already has at least one virtual method so it has a vtable as well. What you have learnt about C++ is that "new D;" calls constructors A, C and D in this order. Now we delve into the implementation details and check out some interesting stuff. The simple truth is that the only thing that the compiler calls in case of "new D;" is the constructor of D. BUT every constructor starts with some auto generated stuff by the compiler that is followed by the "user defined constructor code".
Let's see some pseudo code:
constructor_D()
{
auto-generated: call constructor_C()
auto-generated: init the vtable to vtable-D
user-defined constructor code of D
}
constructor_C()
{
auto-generated: call constructor_A()
auto-generated: init the vtable to vtable-C
user-defined constructor code of C
}
constructor_A()
{
auto-generated: init the vtable to vtable-A
user-defined constructor code of A
}
So if we consider only the "user defined constructor code" then the order of constructor calls is indeed A C D, but if we look at the whole stuff then its D C A. Its obvious that initializing the vtable more than once for an instance is superfluous, in the above example its initialzed 3 times, first in A, then in C and finially in D. We need the initialization only in D because we created a D instance so we need the virtual methods for the D class. Unfortunately sometimes the compiler can not find out whether the vtable initialization in A and C are superfluous or not so it generates the vtable init code there, but you can add the novtable to class A and C as an optimization if you know that they will never be instantiated. In case of an interface we know that it will never be instantiated so an automatic novtable optimization is obvious, an interface will have at least one descendant to init the final vtable pointer.
In your example the ISample interface simply doesn't have a constructor and your CSample constructor looks like this:
constructor_CSample()
{
auto-generated: init the vtable to vtable-CSample
user-defined constructor code of CSample
}
This is why you have the vtable there.
There is a golden rule that calling a virtual function from a constructor directly or indirectly is a bad practice. Direct calls can be caught by the compiler, but indirect ones silently cause bugs and headaches. On indirect virtual function call I mean: you call a non-virtual function from the constructor and then that non-virtual function calls a virtual one. Why is this a problem? Lets say you call a virtual function from the constructor of C. When the constructor of C runs the vtable is initialized to the vtable of class C. This means that even if class D overrides the virtual function, the virtual function of C executes because we have only the vtable of C when constructor C runs!!! This causes a hard to find bug without crash!!! If you use the novtable with class C then the vtable is not initialized when constructor C runs so there are 3 possible scenarios:
1. The vtable pointer might be uninitialized because C and its base classes left it uninitialized so the virtual function call causes a crash.
2. One of the base classes of C doesn't have the novtable directive so it filled in the vtable. In this case if the vtable of this particular base class has an entry for the called virtual function then this virtual function will be executed (A), otherwise a crash occurs (B).
In my opinion a crash is always better and easier to find than unwanted behavior.
So, you can use novtable with any "abstract" class as an optimization. In case of novtable we can treat any classes "abstract" that won't be instantiated at runtime - for example we can use novtable relatively safely with a class whos constructor is has protected access modifier but care must be taken not to call a virtual function from the constructor directly or indirectly. Note that I worked on performance critical programs but I never reached a point where I started to use novtable to optimize. My humble opinion is that if your performance problems come from vtable initializations then you are doing something wrong. Performance problems are rather the consequences of algorithmic problems and cache-unfriendly memory access.
EDIT: you can't enforce interface rules with other mayor C++ compilers. Even if you define the __interface keyword to nothing with other compilers, you have to put there the virtual keyword for functions and either a dummy implementation or "= 0".
|
|
|
|
|
Thanks for taking the time for such a detailed response. It got me thinking about it some more and I believe I now understand why it's there. I was just hoping that the vtable wasn't even needed if the instantiated classes didn't explicitly declare anything virtual. I was hoping the __interface rules and requirements could all be enforced at compile time and the need for the vtable in the derived class could be discarded in my scenario.
Do you think if a true interface keyword existed in the C++ standard, that the virtualness of the interface would not be implied in the classes that "implement" the interfaces. Do "deriving from the interface" and "implementing the interface" mean the same thing?
|
|
|
|
|
"deriving from the interface" and "implementing the interface" are basically the same, the only subtle difference is that you usually say "implement" (but "derive" or "extend" are also okay) when the base class is an interface - the only exception is when both the subclass and the base class are interfaces because in this case documentations use "extend" or "derive". This because evident after reading some documentation about C# or java where there is sharp distinction between classes and interfaces, the VS __interface keyword is also something that mimics the behavior of C# interfaces.
What do you mean on "virtualness" of the class that implements the interface?
|
|
|
|
|
pasztorpisti wrote: What do you mean on "virtualness" of the class that implements the interface?
Sorry, just meaning that once declared virtual in base class, a method is virtual for all "derived" classes.
|
|
|
|
|
Excellent answer, better than mine. +5 for yours...
--
Harvey
|
|
|
|
|
|
Hi to all,
I am trying to implement Brian Gladman's AES Encryption in my program. But as i am new to Encryption, please guide which mode is good to use.
AES_RETURN aes_ecb_encrypt(const unsigned char *ibuf, unsigned char *obuf,
int len, const aes_encrypt_ctx cx[1]);
AES_RETURN aes_cbc_encrypt(const unsigned char *ibuf, unsigned char *obuf,
int len, unsigned char *iv, const aes_encrypt_ctx cx[1]);
AES_RETURN aes_mode_reset(aes_encrypt_ctx cx[1]);
AES_RETURN aes_cfb_encrypt(const unsigned char *ibuf, unsigned char *obuf,
int len, unsigned char *iv, aes_encrypt_ctx cx[1]);
#define aes_ofb_encrypt aes_ofb_crypt
AES_RETURN aes_ofb_crypt(const unsigned char *ibuf, unsigned char *obuf,
and i am confused on *iv what is this? I had to encrypt files as well as strings.  
Regards,
Vishal
|
|
|
|
|
Try asking Brian Gladman, we cannot guess which of the above is the right choice.
|
|
|
|
|
perhaps you had not understand my question, my question was related to modes and iv. Anyways thanks. 
Regards,
Vishal
|
|
|
|
|
vishalgpt wrote: perhaps you had not understand my question, my question was related to modes and iv.
I understand your question perfectly well. The problem is that you are referring to someone else's code and we do not have access to it, so how can we tell you which function to use? Those function definitions on their own provide no useful information. All I can tell you is that iv is a pointer to a character string, but how that fits in with these functions is anyone's guess.
|
|
|
|
|
well first hello :
i would like to know how to learn kernel programming ?
Does any one know where should i start what books should i read ,if any one know books , websites,forums ,let me know them ,and i know C++ ,Java ,i have been programming since 1 year and half
|
|
|
|
|
|
well i tried google but i wish if i could learn from members experience
|
|
|
|
|
This is a technical forum, you cannot expect to get full tutorials on something as wide and complex as this subject. You have not even stated which platform you are planning to work on.
|
|
|
|
|
linux platform,well i'm not asking for tutorial i know that this forum is full of programmers , well anyway Thank you.
|
|
|
|
|
OmarSH wrote: linux platform
Then I suggest you do a Google search and you will find lots of useful references.
|
|
|
|
|
OSR online is a very good resource.
Book wise you need Walter Oneys book on kernel programming.
Other than that you need 2 machines, the WDK, windbg, a firewire or serial x over cable and start putting code into the kernel.
PS, I have been doing windows kernel for about 16 years. It is fun, but complex, very very complex, but if you can stick at it for about 2 years you should know enough to be able to write useful code. (And use Verifier, a lot)
==============================
Nothing to say.
modified 8-Feb-13 8:24am.
|
|
|
|
|
|
You'll probably want to get really familiar and comfortable with C. It may also be helpful to experiment with Linux drivers since you can browse all the existent code to see what other people are doing (although that may confuse you at first, specially if you're not comfortable with C). A lot of people try to dive right in without reading documentation, I'd recommend going over the documentation first, it might not make sense while you're reading it but when you finally dive in, things will start to make sense.
One thing you can do is take an existent driver from Linux and see if you can modify it to do something different. That should get you comfortable with it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
