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.
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.
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:
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:
auto-generated: call constructor_C()
auto-generated: init the vtable to vtable-D
user-defined constructor code of D
auto-generated: call constructor_A()
auto-generated: init the vtable to vtable-C
user-defined constructor code of C
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:
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?
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
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)
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.
That's understandable, i tried googling around some too but didn't really find anything readymade either. I can think of two alternatives to writing your own source filter:
1. Extract your videos into some temporary files and play those from the file system, this can be a bit costy in both time and resource wise (you need time to extract the videos to temp files and you will need extra disk space for the videos) but i supose this is quite a straightforward solution. Alternatively you might try using a named pipe and specifying that as the source for the file reader filter, no idea if that would work or not, never tried, but i kinda suspect it wouldn't work.
2. Implement a "small" HTTP server in your application that can stream the video from your big file and try to render the stream with DirectShow like "http:\\localhost:12345\a.avi" or somesuch. This might be more work than just writing the filter though.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
I already thought both of your solutions you suggest. The 1st is abandoned from the very beggining since the archive file is delivered in retail-DVD and as you can imagine the time needed to extract it in the hard disk is critical. The 2nd solution is also rejected, since this is a retail product and the configuration of end computer is unknown, any anti-virus or general other protection software may block my application to work as it expected. So I think a custom filter in my case is more than imperative.
Yes, the same as I told you before. You are not checking that you have read all the data from the client so you have no way of being sure that you have a valid image. You are using sizeof and lstrlen to find the length of the data, neither of which will give you a valid answer.
I suspect the error 87 should be ignored as you have not checked if the previous function was successful or not. You can validate that by calling SetLastError(0) before the SetIcon() call. You also say that when you set icon style to FALSE it does not display the icon; isn't that what it should do?