C and C++ should be pretty similar for speed UNLESS you start using templates and other polymorphic type stuff - still being able to write ‘generic’ functions is much more elegant is it not?
Why aren’t we all programming this in Eiffel 
<Takes his compiler hat off>
I thought the point of templates was that their performance was similar to coding the algorithm or whatever for the specific data type, as the compiler generates the specific code for each data type you use anyway.
Or am I missing something?
Yeah it depends what you do with them doesn’t it? The compiler does static type checking to determine what kind of types the function will be parameterised by and does its stuff.
If it can’t make the determination then it does dynamic binding at runtime doesn’t it?
Or have I made C++ out to be more intelligent than it really is?
It’s quit unimportant if you program in C or C++, fact is C++ is “C2” so more power and more possibilities to program great stuff, I usually program in “mmy own language”, a mix of C and C++, but C mostly does it
Originally posted by Deiussum:
abstraction from the Win32 API
Yeah, yeah.
Like CWindow::GetWindowText() or
CWindow::CheckRadioButton( int nIDFirstButton, int nIDLastButton, int nIDCheckButton );
nIDFirstButton? Are we talking about OOP or not?
This is not a real abstraciton!. Is just hiding the handle, and implementing all the Win32 API in monhotlitic classes. Even the name of the methods are the same than those on Win32 API!
I agree with rts:
“MFC is a terrible example of C++ usage”
In my experience, you cannot succed in mastering MFC if you don’t have previous experience with the old-plain Win32 API.
Period.
Originally posted by pixio:
[b] Yeah, yeah.
Like CWindow::GetWindowText() or
CWindow::CheckRadioButton( int nIDFirstButton, int nIDLastButton, int nIDCheckButton );
nIDFirstButton? Are we talking about OOP or not?
This is not a real abstraciton!. Is just hiding the handle, and implementing all the Win32 API in monhotlitic classes. Even the name of the methods are the same than those on Win32 API!
I agree with rts:
“MFC is a terrible example of C++ usage”
In my experience, you cannot succed in mastering MFC if you don’t have previous experience with the old-plain Win32 API.
Period.
[/b]
That might not be a huge abstraction, but it is an abstraction. You are using those functions on the current object that you call them from, and don’t need to know that the window is actually represented by a handle underneath.
You seem to be ignoring the abstraction of the CDialog class. You don’t need to know that there is a procedure underneath. Dialogs are one area that MFC is great with, IMO.
Personally, I like that it is so close to the actual API calls. If you look at something further abstracted, like OWL, you lose a lot of control you might otherwise have with MFC.
Sure, knowing the Win32 API will help your MFC skills greatly, but it is not a requirement. I personally learned MFC first, and then later picked up Win32. It gave me greater insight into MFC so that I coudl use it more efficiently, but it certainly wasn’t something I NEEDED to know first.
It’s all a matter of opinion. I use MFC for windowed apps that I have no intention to port, don’t require blazingly fast performance, and need to have dialogs and menu options . I use Win32 for things that I want to be faster, aren’t as reliant on dialogs, and I don’t care about portablilty. I use glut for writing quick little apps that I want to be able to run under both Win32 and Linux.
Just my tu’pence worth, MFC is incredibly handy for ‘utility’ projects which are unlikely to be ported and speed is not a requirement…eg a current project I am doing that (hopefully) allow stress analysis on 3d space frames (MFC is providing a simple modeller) because it has allowed me to quickly implement huge ammounts of GUI related code very quickly & easilly, and with all due respect it would have taken me ages to have written all the GUI code myself, allowing me to concentrate on the more interlectually difficult bits of the project. Equally something where I want fast, clean, portable or readable code I wouldn’t be caught dead using MFC
If a GUI heavy RAD project that wasn’t too speed critical is required why not use Borland C++ Builder? Its far ‘quicker’ to get working code out and much more logical than MFC…
Why more people don’t use it is beyond me…
paul
Originally posted by Pauly:
[b]If a GUI heavy RAD project that wasn’t too speed critical is required why not use Borland C++ Builder? Its far ‘quicker’ to get working code out and much more logical than MFC…
Why more people don’t use it is beyond me…
paul[/b]
I really didn’t want to turn this into a VC++ vs Borland thread. Personally, I found Borland code to be ugly. About on par with using VB. That’s just my opinion, though. I like having the ease of MFC, but not taking too much of the flexibility away that comes from using the Win32 API.
It’s just me, but there are many OOP project’s I’ve seen that making it object oriented has actually complicated things, made it less intuitive, and generally hurt the project…my point, use what’s best for your needs, not what everyone else is
Originally posted by gantww:
Anybody have any ideas on this one? I’ve heard that many game companies create their products in C, instead of C++.
id Software has been making games using C. They made Quake 3 using C. In the new DOOM game they are going to use C++ though. I think…
id Software has been making games using C. They made Quake 3 using C. In the new DOOM game they are going to use C++ though. I think…
That’s affirmitive, Jim Dose’ posted a screenshot of his desktop , and there opened up in plain view is MSVC++ with the DOOM3 project loaded, and what is visible is C++ source code.
OOP doesn’t create much overhead. But can make the cach hit ratio drop. If you use virtual functions, each call of a function will need to be checked about what class is exactly instanced. If the definition of the upper class function and the actual class function are distant in the memory, it may cause an extra load of the cach what implies in a buble in the pipeline.
Originally posted by Pauly:
C and C++ should be pretty similar for speed UNLESS you start using templates and other polymorphic type stuff - still being able to write ‘generic’ functions is much more elegant is it not?
Using templates is zero overhead. They are treated much like precompiler macros - completely expanded in compile-time. Templates are actually used for certain optimizations, e.g to avoid the creation of temporary objects.
Originally posted by Pauly:
If you use virtual functions, each call of a function will need to be checked about what class is exactly instanced. If the definition of the upper class function and the actual class function are distant in the memory, it may cause an extra load of the cach
That’s not really true. The “upper” or abstract function/method is never touched. Virtual methods are implemented using a lookup-table, so the only memory touched is the lookup-table and the actual method.
I don’t know how virtual methods and polymorphism could have any faster implementation than that. It’s faster than a switch-statement and it’s faster than a series of if-else-statements, which is used for polymorphism in C.
A bigger source of speed-loss in C++ is all the temporary objects created. Any function not returning a pointer or reference, will create and destroy one “useless” object each time it’s called:
Vector
sum(Vector& a, Vector& b)
{
Vector v;
v = a;
v.x += b.x; v.y += b.y; v.z += b.z;
return v;
}
…
x = sum(a, b);
…
It may not be the best example, but just to show what I mean. Vector v is created temporarily just to copy the result to x. If sum() is called often, or if Vector were a big class, like a list, the overhead would be substantial. Then there are tricks to get around this, but they all cause problems. At the end of the day, you have a big hairy unreadable mess. So if you plan to use C++, expect a great deal of ugly tricks - just like in C… 
****, I’m sorry Pauly, that second quote was not from you, it was from D’Agostini. All this cutting and pasting…
Mamba: Just a small point, in simular C code (for your vector example) a temporary (ie local) object for Vector v would have to be created…ultimately for both you are better off using pointers for all of the vectors including the result - ie:
void vector::sum( Vector *a, Vector *b, Vector *sum )
{
sum->x = a->x + b->x;
sum->y = a->y + b->y;
sum->z = a->z + b->z;
}
Of course you could add an extra redundant member to your vector & use some SIMD insts…
Originally posted by Anon:
Mamba: Just a small point, in simular C code (for your vector example) a temporary (ie local) object for Vector v would have to be created…ultimately for both you are better off using pointers for all of the vectors including the result
Yes, that’s one of the tricks I had in mind. You end up with a cluttered and therefore more error-prone program though. But you’re right.
I have to say that I always thought that pointers were routine (as in mundane) and never considered them a trick of any sort 
Originally posted by Anon:
I have to say that I always thought that pointers were routine (as in mundane) and never considered them a trick of any sort
Syntactically, Vector sum(Vector, Vector) is closer to how one think of a function. Making the result a parameter instead is a trick. Explicitly pre-allocating the result is also not how you think of a normal function. Anyway, some are happy once they have an efficient solution, others (like me) also want a logical, consistent way of writing code. In my experience, you make fewer errors that way.
It’s hardly an ‘ugly trick’ returning a pointer to an object rather than a copy of it. If anything, it seems the most logical way to do things, especially once you get into deep vs shallow copying.
C++ just requires a slightly different mindset from non-OOP languages. Personally, I can’t program non-OO anymore. Objects just seem to make sense in some kind of low-level brain way.
