C / C++ / MFC

Joaquín M López Muñoz17-Jan-03 5:11

Joaquín M López Muñoz

17-Jan-03 5:11

No, no difference at all.
The opposite situation, having objects of type A and B pointed to by pointers of type A, usually won't show any difference either, except in complicated situations involving multiple virtual inheritance.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

User 988517-Jan-03 5:34

User 9885

17-Jan-03 5:34

then, would the situation change if class B inherits from another class, class C in addition to class A?

and

what would the difference be if class B did not have any base class at all?

My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers

modified 29-Aug-18 21:01pm.

Tim Smith17-Jan-03 5:41

Tim Smith

17-Jan-03 5:41

There are 3 issues to performance with virtual function:

1. vtable construction and destruction

Each time an instance of the class is constructed or destructed, the vtable pointer must be updated. Thus if the nesting is 2 classes deep, (i.e. B inherits from A), then the vtable pointer is set twice during construction and twice during destruction.

2. Indirect calls

When a call do a vtable is made, instead of a "CALL XYZ", there has to be two instructions. The first is to fetch the address of the vtable (i.e. MOV EAX, [ECX]), and then the actual indirect call (i.e. CALL [EAX+10h] to invoke the 4th routine in the vtable.) (NOTE: I think I'm right on this one...)

3. Thunking for multiple inheritance.

The final thing is if you invoke a virtual method of a base class that is the 2nd or greater base class, then the address of the class instance must be adjusted prior to the call. This is so that the base class routine receives the proper class instance address.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Nemanja Trifunovic17-Jan-03 5:50

Nemanja Trifunovic

17-Jan-03 5:50

Tim Smith wrote:
There are 3 issues to performance with virtual function:

4. (and the most significant IMHO): the compiler cannot optimize virtual functions (which are lete-bound) like non-virtual functions (compile-time bound).

Beer | [beer]

Tim Smith17-Jan-03 6:14

Tim Smith

17-Jan-03 6:14

Oooo. Good addition.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Joaquín M López Muñoz17-Jan-03 5:45

Joaquín M López Muñoz

17-Jan-03 5:45

then, would the situation change if class B inherits from another class, class C in addition to class A?

No, only if virtual multiple inheritance is used.

what would the difference be if class B did not have any base class at all?

If B has no base at all, you can hardly point to a B object with an A pointer. What's the scenario you're thinking about?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

How to add element to the desktop's menu?

User 988517-Jan-03 6:18

User 9885

17-Jan-03 6:18

I think all my questions are answered.

If you have a virtual function, it is a run-time binding or late-binding which requires a vtable lookup- hence slower.

My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers

modified 29-Aug-18 21:01pm.

julych17-Jan-03 3:48

julych

17-Jan-03 3:48

How to add element to desktop's menu and to control this element from my MFC application?

is this VC++ compiler bug, or my bug ? :)

rrrado17-Jan-03 3:48

rrrado

17-Jan-03 3:48

I have this piece of code :

CString tmp;
int x = 1;

tmp.Format("%d,%d,%d",++x,++x,++x);
AfxMessageBox(tmp);

x = 1;
tmp.Format("%d,%d,%d",x++,x++,x++);
AfxMessageBox(tmp);

I always thought that output of this will look like this :
4,3,2 and 3,2,1.

But when i compile that in debug mode (no optimalisations) :
4,3,2 and 1,1,1

Release mode :
4,4,4 and 1,1,1

What's wrong ? Even if my assumptions was incorrect, i think that such trivial code should work by the same way in debug and release version.
Who knows the answer ? Smile | :)

(I use VC++ 6.0 with some service pack, i think Unsure | :~

rrrado

jhwurmbach17-Jan-03 4:07

jhwurmbach

17-Jan-03 4:07

rrrado wrote:
What's wrong ? Even if my assumptions was incorrect, i think that such trivial code should work by the same way in debug and release version.

Well, for me it does.
Your Problem is somewhere else, I think.

My opinions may have changed, but not the fact that I am right.

rrrado17-Jan-03 4:11

rrrado

17-Jan-03 4:11

What version do you use ? What are your results ?

rrrado

jhwurmbach17-Jan-03 4:16

jhwurmbach

17-Jan-03 4:16

Both Times what you report for Debug version (4,3,2 and 1,1,1).
And I have VC++6.0 Professional, SP4 (I think, but definetly more than 3).

My opinions may have changed, but not the fact that I am right.

Joaquín M López Muñoz17-Jan-03 4:57

Joaquín M López Muñoz

17-Jan-03 4:57

To the best of my knowledge, this is not a VC++ bug. First of all, the order of evaluation of parameters in a function invocation is unspecified, so hoping for 4,3,2 is as reasonable as 3,4,2 or whatever order. But, as you point out, this does not explain the 1,1,1 output and the difference between release and debug mode. The standard says with respect to the modification of values (¶5.4):

Between the previous and next sequence point a scalar object shall
have its stored value modified at most once by the evaluation of an
expression. Furthermore, the prior value shall be accessed only to
determine the value to be stored. The requirements of this paragraph
shall be met for each allowable ordering of the subexpressions of a
full expression; otherwise the behavior is undefined. [Example: 
i = v[i++];                     //  the behavior is unspecified
i = 7, i++, i++;                //   i  becomes  9

i = ++i + 1;                    //  the behavior is unspecified
i = i + 1;                      //  the value of  i  is incremented


--- end example]

In layman's words, you cannot increment the value of a variable more than once in a single expression: if you do so, any behavior can be expected, and VC++ is free to do different things depending on the debug/relase mode (it could even fail to compile and issue this as an error, which would be the most sensible thing to do).

If you're curious as to what's the reason behind this restriction, it probably helps compilers a great deal in optimizing scalar expressions.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Tim Smith17-Jan-03 5:02

Tim Smith

17-Jan-03 5:02

IMHO, it is probably a legacy issue where they can't agree on how it should work. Compiler vendor A says "X" while compiler vendor B says "Y". Both want to avoid having to modify their compiler.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Window positon when maxed

Mike Nordell17-Jan-03 23:43

Mike Nordell

17-Jan-03 23:43

Tim Smith wrote:
IMHO, it is probably a legacy issue

No offence, but your opinion and facts are disagreeing. The facts carry more weight.

Both C and C++ have the concept of sequence points. These are well-defined. If you modify something twice or more with no sequence point(s) inbetween those modifications, you are invoking implementation-defined behaviour. I.e. there's no way to tell what the outcome will be.

I believe the stated reason it's specified like this (or not specified, depending on how you look at it) is to allow optimizers to do their job by restructuring the code. And, indeed, non-optimized builds often just evaluates the expressions as-is, while an agressive optimizer generates machine code that bears little or no resemblance to the original source code.

S O S17-Jan-03 2:18

S O S

17-Jan-03 2:18

I am doing an MFC program that needs to position some other windows during startup.
But the program starts maximized, however GetWindowRect() returns the non-maximized rect during the processing of WM_CREATE in OnCreate().
I know that SystemParametersInfo() can return the work area, but unfortunately that is not the same as the maximized window rect. Cry | :((

Is there a way to get that rectangle?

Or can you tell me what value(s) are the maximized windows offset by? Some borders on the sides? Which ones?

peterchen17-Jan-03 3:03

peterchen

17-Jan-03 3:03

If you have no menu, or know that youe menu fits one line (yuck), you can use

GetClientRect
ClientToScreen
AdjustWindowRectEx

You can also use GetWindowPlacement to get the origin of the frame of the maximized window (it will be off-screen for a top level window!) But heed the "Remarks" section of the GetWindowPlacement documentation, and check your app with the taskbar moved to the left, or top!

Those who not hear the music think the dancers are mad. [sighist] [Agile Programming]

S O S17-Jan-03 3:41

S O S

17-Jan-03 3:41

Thanks, but GetWindowPlacement() says that the maximized top-left corner coords are the same as normal position top-left coords Frown | :(

The MSDN page for it also says that the flags member retrieved is always 0, but it's 2 after I call it.. ???

peterchen17-Jan-03 4:40

peterchen

17-Jan-03 4:40

?? I get sth. like
ptMinPosition = { -6, -25 }
rcNormalPosition = { 241, 417, ... }

(It's an MDI child, and I set wndplacement.flags = WPF_SETMINPOSITION; before I call, but that should not make a difference...)

WINDOWPLACEMENT wpabs;
wpabs.length = sizeof(wpabs);
wpabs.flags  = WPF_SETMINPOSITION;
wnd.GetWindowPlacement(&wpabs);

Those who not hear the music think the dancers are mad. [sighist] [Agile Programming]

S O S18-Jan-03 0:19

S O S

18-Jan-03 0:19

Ehh... ptMinPosition is the minimized position(whatever that would be for...), I need the ptMaxPosition, which is the same as rcNormalPositon's topleft corner for me.