PDA

View Full Version : C versus C++



04-23-2001, 04:47 PM
I am hoping to try my hand at OpenGL coding in C using Win32. This is partially because of efficiency and partially because it should be interesting. Anyway, I got to thinking about how C++ does it's OOP stuff. I would think that object-oriented creates a lot of overhead. The only compiler I have right now is Microsoft Visual C++. I was just curious as to whether or not the compiler puts in all the C++ crap when I compile a program that doesn't use OO. If I am going to have to put up with the overhead anyway, I might as well go object-oriented. I know this isn't exactly an OpenGL question, but no one has been able to answer it so far.

Anybody have any ideas on this one? I've heard that many game companies create their products in C, instead of C++.

Will
Gantww@lipscomb.edu

rts
04-23-2001, 06:35 PM
II was just curious as to whether or not the compiler puts in all the C++ crap when I compile a program that doesn't use OO.


If you compile C source with a C++ compiler no "C++ crap" will be thrown in.



I've heard that many game companies create their products in C, instead of C++.


C++ is rapidly gaining ground in the games industry.

DFrey
04-23-2001, 08:16 PM
While it is true that C++ adds some extra overhead, if you are careful in the design and granularity of the objects, this extra overhead can be really quite insignificant.
Even the guys at id Software (who have exclusively used assembly and C) have finally begun using C++ starting with their current project, Doom 3.

Teofuzz
04-24-2001, 12:17 AM
A couple of years ago I coded a DOS engine in C++ from the source of another in C.
C source was compiled with watcom, C++ with djgpp, and the size of the 2nd was bigger.
Ok, but performance was better: maybe using some oop lets you organize efficiently the code? I think yes.
I always preferred C++! http://www.opengl.org/discussion_boards/ubb/biggrin.gif
tFz

04-24-2001, 08:45 AM
I'm glad to know that object-oriented techniques don't impact performance to a large degree if coded properly. I had always assumed that it would have a more severe effect than it apparently does.

Next Question: MFC? Good, bad, or indifferent? I know that it does a lot of abstraction in regards to the message maps, windowing, etc. Should I just stick with STL classes and custom classes I write (if I code them carefully...) instead of using theirs?

Will Gant
gantww@lipscomb.edu

dhoffman
04-24-2001, 10:32 AM
I thumbed through a game programming book recently called "Real-time game programming" that pointed out a number of instances where c++ code ended up actually being faster than equivalent c code. I don't remeber the specific examples but I've always believed that speed is not something to really worry about when comparing equivalent c and c++ code.

DFrey
04-24-2001, 11:35 AM
I would avoid MFC like the plague, unless you are absolutely positive that you will never want or need to port the source code to another platform. I'd stick with STL classes, even those are not 100% compatible yet across platforms, but that just requires a bit of code tweaking so it ain't that bad.

rts
04-24-2001, 11:41 AM
I'll echo what DFrey said. His reason is perfectly good, but I'll add this one (which will undoubtedly start a flame war):

In my experience, people who go hard care with MFC and think that MFC is the end all and be all of C++ design are adversely affected for the rest of their lives. MFC is a terrible example of C++ usage. If you need, only learn what you need, then quickly forget it.

My Cdn$0.02

Deiussum
04-25-2001, 11:19 AM
I actually like MFC for a lot of things, but I wouldn't use it if you are looking for the best possible performance. The things I like about it is that it gives an abstraction from the Win32 API, but you still have the ability to work on a lower level if you need to. It is a lot better than Borland's OWL classes, IMO... those are just ugly. To VBish for my tastes. http://www.opengl.org/discussion_boards/ubb/smile.gif Anyway, for things that don't require high performance and will make a lot of use of Dialog boxes, menus, etc. (like maybe a model viewer) I would definitely go with MFC. For something like a game or demo, where you want to squeeze as much performance as you can get, I'd stay away from it.

Korval
04-25-2001, 12:09 PM
I'll echo Deissum's comments on MFC. It's pretty good stuff, if performance isn't an issue. It is fairly easy to use (and VC++ is willing to give you a hand) and more powerful than GLUT. I use it when I want to test various parts of code (like a landscape engine, or the animation code). Basically, I use it for anything that isn't a full-fledged un-Windows program (by that, I mean a program that has a minimal use of the OS's GUI services, like a game).

[This message has been edited by Korval (edited 04-25-2001).]

Psyche
04-25-2001, 01:10 PM
Ok, I'll echo someones opinions too. I choose Dfrey and rts. MFC is very easy and very quick to program, but it just isn't the best choice for gl applications in my opinion. Go with Win32 if you wanna get more polygons at a time outta your GPU. Don't forget; the farther you get from your CPU native instructions, the slower your applications will get. Avoid high-level classes and libraries as much as you can but not necessarily all the time.

MrShoe
04-25-2001, 02:22 PM
Personally, so far I prefer C, mainly because C++ is the same except for OOP. All the other differenses are non-consequential. OOP is useful, but I have not had a need for it so far. Unless you specifically are going to use OOP, I suggest you stick with C instead of C++. I also prefer GLUT, for 2 reasons, 1 is that it is much easier to set up a program in GLUT, 2 is that it is totally cross platform. I use a win98/Linux rig, dual boot. If I am going to create a program, Id want everyone to be able to use it, not onle Win32 PCs. Maybe GLUT is slower (im not sure thought), however, GLUT is only used for a tiny bit of a program (initialisation and keyboard control), this tiny part of the program, even if a little slower, will hardly have any impact at all on the total speed of the whole program. I think it is worth trading a LITTLE performance, for ALOT of ease of use.

john
04-25-2001, 04:06 PM
Hmm. I don't want to launch into the whole imperative / object orientated debate. However, I will say this: OOP isn't a tricky feature which is nice to have but is frivilous in all other repsects. It ins't like having a funky LCD display on your cd player that looks pretty but is ultimately useless. OOP is a methology of programming; It is, no less, an important prorgamming paradaigm.

There are other programming models: C/Pascal/BASIC are imperative; C++/Java/SmallTalk are object-oriented; Miranda/NESL/Lisp are functional; Prolog (and precious little else=) are Logical. My point: OOP isn't just a funky addition, its a way of coding.

.... i could say more, but i won't. FEH.

cheers,
John

harsman
04-25-2001, 10:28 PM
Originally posted by Psyche:
Ok, I'll echo someones opinions too. I choose Dfrey and rts. MFC is very easy and very quick to program, but it just isn't the best choice for gl applications in my opinion. Go with Win32 if you wanna get more polygons at a time outta your GPU. Don't forget; the farther you get from your CPU native instructions, the slower your applications will get. Avoid high-level classes and libraries as much as you can but not necessarily all the time.


If you want to code optimized GUI/message handling routines, go ahead. I'd however recommend spending time on optimizing stuff that takes time to execute, like rendering and math intensive stuff like collision detection. If you're spending more than a couple percent of your execution time initializing GUI classes and handling messages then optimize all you want, however this has never happened to me yet, so I optimize other stuff. Don't worry about whether it's optimized or not if it isn't slow, go with what's gets the job done fast. If that happens to be MFC or some other high level GUI library, so what? It's not like the GUI is a performance bottleneck anyway.

04-25-2001, 10:52 PM
instead of thinking whether to use C or C++ it's better to get used to say Ocaml 3.00... nothing better released so far... simple, functional and fast language....

Psyche
04-26-2001, 08:57 AM
Harsman, I agree with what you're saying mostly but don't forget that you're rendering on a Winbloze device context and if that device context is lagging or not optimized, it will slow your rendering context down along with it. But of course, depending on your projects size and complexity, this might not be the case at all and whether using Win32 or MFC would not make a difference in that case.

04-26-2001, 03:25 PM
So you can use ML to make OpenGL programs. Usually is it good to hear that you can do GL programs with some other language... but ML?
ML is the elites own little toy that they use to make little toy programs.
No hesitation - ML is the only alternative for the "real" people the other is for the half-monkeys.
No hesitation about how they behave and what rights they have.

All that is just stupid, sick and disgusting.
You should not look up to dirt like that!

MrShoe
04-26-2001, 09:03 PM
Well, surfing the web i found this interesting fact on Gamedev (i think, not sure thought). It says that the id software team has been using C as their language of choice, and only recently moved to OOP. The first game they are going to do not in C is Doom3, that means that Quake3 was dont in C, and not C++. I find this rather interesting.

zed
04-27-2001, 01:10 AM
ive been using c++ for ages but mostly avoiding certain c++ things templates/multiple inheritence

why? heres a nice example of doing the dotproduct with templates.

// Vector dot product
//
// Specialized for Nx1 matrices (i.e. vectors)

inline const T dot(const matrix<N, 1, T> &m) const
{
T result = (T) 0;
for (unsigned int i = 0; i < N; i++) result += _data[i] * m.data()[i];
return result;
}

Unormal
04-29-2001, 05:13 PM
Hey, with the discussion of glut and mfc and the rest, I thought I might offer my dinky little wrapper modules (called MonkeyLib..) I wrote for Win32 games using OpenGL & DirectX... Dosen't do much but the core window setup and exposing some simple functions like PlaySound and LoadTexture; but it's a spiffy little transparent wrapper, just add the core files to your project and start your MonkeyLibMain() main loop...
http://www.areth.com/monkeylib.htm

Very, very free and hacky but perhaps useful...

Pauly
05-01-2001, 06:37 AM
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 http://www.opengl.org/discussion_boards/ubb/wink.gif

<Takes his compiler hat off>

Benjy
05-01-2001, 06:42 AM
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?

Pauly
05-01-2001, 06:47 AM
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? http://www.opengl.org/discussion_boards/ubb/wink.gif

05-01-2001, 09:25 AM
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

pixio
05-01-2001, 10:12 AM
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.

Deiussum
05-02-2001, 10:59 AM
Originally posted by pixio:
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.



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.

05-03-2001, 06:33 AM
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

Pauly
05-03-2001, 06:46 AM
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

Deiussum
05-03-2001, 07:19 AM
Originally posted by Pauly:
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

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.

HFAFiend
05-03-2001, 05:30 PM
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

Malevolent
05-06-2001, 12:21 PM
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...

DFrey
05-06-2001, 01:17 PM
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 (http://www.voodooextreme.com/shot.taf?image=apache/shots/doom3/jimdose.jpg&desc=id's+DOOM3&link=http://www.ua-corp.com/) , and there opened up in plain view is MSVC++ with the DOOM3 project loaded, and what is visible is C++ source code.

D'Agostini
05-06-2001, 02:45 PM
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.

Mamba
05-06-2001, 10:43 PM
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... :-)

Mamba
05-06-2001, 10:47 PM
****, I'm sorry Pauly, that second quote was not from you, it was from D'Agostini. All this cutting and pasting...

05-06-2001, 11:30 PM
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...

Mamba
05-07-2001, 04:17 AM
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.

05-07-2001, 04:39 AM
I have to say that I always thought that pointers were routine (as in mundane) and never considered them a trick of any sort http://www.opengl.org/discussion_boards/ubb/redface.gif

Mamba
05-07-2001, 06:43 AM
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 http://www.opengl.org/discussion_boards/ubb/redface.gif

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.

Benjy
05-08-2001, 04:14 PM
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.

2
05-08-2001, 08:28 PM
Can you have operators or inlines in C? (I never learned C... just skipped to C++). Hehe... here's vector stuff that I'm pretty sure is fairly impossible in C.

class vector2d
{
public:
float x, y;
virtual float Length( void ) const { return sqrt(x*x + y*y); }
};

class vector : public vector2d
{
public:
inline vector( void ) { }
inline vector( float X, float Y, float Z ) { x = X; y = Y; z = Z; }
inline vector operator +( const vector &v ) const { return vector( x+v.x, y+v.y, z+v.z ); }
float z;
float Length( void ) const { return sqrt( x*x + y*y + z*z ); }
};

ffish
05-09-2001, 12:08 AM
You can have everything in C that you can have in C++ (apparently). I've heard early C++ compilers would actually compile C++ into C first, then into machine code. You can even do everything in assembly language that you can do in C++ (don't try that at home). Try compiling your programs to output assembly (MSVC++6 help says use the /FA switch).

Although what I've said above is true, there is no way I could rewrite some of my C++ code into C - like you say operator() calls and so on. You can have the same effect as inlining using macros though - #defines. This is pretty much exactly the same effect as an inline function except it's done by the preprocessor instead of by the compiler.

harsman
05-09-2001, 01:28 AM
Yes you can do every C++ feature in C, and every C feature in assembler and every feature in assembler you can do by directly hacking machine code. The point is no one actually does it, beacause you loose the whole point of higher level languages, abstraction. With abstraction you generally lose some performance but gain a lot in high level design and flexibility.

ffish
05-09-2001, 03:01 AM
I agree totally, Harsman, I was just saying it's possible in response to 2's question.

One more point 2: if you have Scott Meyers' excellent book "Effective C++", read item 33 on the dangers of inlining constructors & destructors.

Last code point while I'm on my bandwagon http://www.opengl.org/discussion_boards/ubb/smile.gif: do you know about member initialisation lists 2? I'd probably change your second vector constructor to:




// I might even make the parameters const float&amp;
vector(float X, float Y, float Z) : vector2d(X, Y), z(Z) {}


It's just a little bit more efficient and cleaner. Don't take this the wrong way 2 - there's nothing wrong with your code - but I've read a lot of good books on C++ and sometimes I think I'm too clever for my own good http://www.opengl.org/discussion_boards/ubb/smile.gif Point is, I wish I had more people to help me with my coding, so I try to offer what I know when I can. You can never stop learning http://www.opengl.org/discussion_boards/ubb/smile.gif

[This message has been edited by ffish (edited 05-09-2001).]

evil
05-09-2001, 03:06 AM
You people who are looking for a non-MFC GUI class library may find www.wxwindows.org (http://www.wxwindows.org) very interesting. Cross-platform, works on most
compilers and even has a built-in OpenGL canvas http://www.opengl.org/discussion_boards/ubb/smile.gif

reign_bow
05-09-2001, 11:24 AM
Now I'm not gonna echo anybody's opinion, people, so bear with me.

In the discussion of C++ vs. C I have to say that C++ has some VERY nice features to offer for very little overhead(function overload, OOP,templates). Especially templates are useful, because when you want a vector of your personal class Met, all you need is "vector<Met> v;".

As for MFC, I think they're evil, and you should use GLUT, if you're going for portability. Programming WINAPI has a serious performance advantage:By calling InvalidateRect() at the end of your drawing function, you can hack Winblows to pump a large part of the system resources into your program, something that GLUT doesn't, to my knowledge. You'll love it when your fps hits 200!

Where

2
05-10-2001, 12:08 PM
GLUT does has "Game mode". I got like 600 fps with that. Kilgard just neglected to mention it in his manual. Here's a site that has some good info on it:
http://www.fatech.com/tech/opengl/glut/index.php3?gameglut

SPAAARKY21
05-10-2001, 01:10 PM
Originally posted by john:
Hmm. I don't want to launch into the whole imperative / object orientated debate. However, I will say this: OOP isn't a tricky feature which is nice to have but is frivilous in all other repsects. It ins't like having a funky LCD display on your cd player that looks pretty but is ultimately useless. OOP is a methology of programming; It is, no less, an important prorgamming paradaigm.

This all depends on what you're doing. For me, in my 3D engine, OOP is absolutely essential. It's allowed me to write code that is very clean, organized, and easy to understand. It just makes sense - I'm creating a fake world in 3D so I have a world class. The world has different objects in it so I have various object classes. They load themselves, they move themselves if needed, they draw themselves, and they delete themselves when your done with them. They do everything. And if I need to have another world ready while another is already loaded, I can just create another instance of my world class. I can't imagine writing anything without OOP anymore.

05-11-2001, 01:05 AM
About Caml:

i don't see anything interresting in this language.

MrShoe
05-11-2001, 03:21 AM
Hehe, this is a popular topic. I would like to restate my opinion. You should use C, and when you are a REALLY good programmer, then move on to OOP. This is because OOP will only confuse you when you arent experienced enough. Some people might say it is easy, in some ways it is, but if you want to utilise it properly, it is quite complicated.

ffish
05-11-2001, 03:38 AM
I _sort of_ agree, but only insomuch as learning C is much easier than learning C++. There are plenty of other OO languages that are a hell of a lot easier to learn than C++. Java seems to be a popular one for undergrads these days. Python is very clean and very simple, though supposedly quite powerful. C++ though, is not a beginners language. I have been using it for 3 years and I've read some very good (and very difficult) texts on it. There are so many features and so many quirks that I feel I'll never finish learning, despite having 10s of thousands of lines of code under my belt. If you're really serious about learning C++, here's a list of my favourite texts:
The C++ Programming Language by Bjarne himself - a must have (read it 3 times).
The ANSI/ISO C++ Professional Programmer's Handbook by Danny Kalev (from the standards committee) (read it twice).
Effective C++ and More Effective C++, both by Scott Meyers (read 3 times or more).

I would say C++ is worthwhile learning. As the OO proponents say, OO is a natural way to conceptualise the world. It lends itself well to 3D graphics since we can all identify the objects used easily (vectors, vertices, triangles, etc through to houses, people and other composite objects). It also is so much more valuable to me than C ever was in terms of reuse of old classes. That alone was worth the investment in reading those books.

05-11-2001, 05:34 AM
Well I'd go for Objective-C. The gcc compiler of about any *nix system should compile it. It's an extension of ANSI C and it's extremely easy to learn compared to C++. Knowing C, the rest should take less then 5 days to learn (I did it in less then one day). The plusses of Objective-C is that it contains no multiple inheritance and it has a descriptive method syntax, dynamic binding etc.

They stole some SmallTalk syntax when inventing the language unfortunaly not the garbage collection... oh well we can't have everything!

CYA

tfpsly
05-11-2001, 05:34 AM
The beauty of OOP/C++ is that you can easily develop and alter an application, adding features you didnt thought about before, while keeping your code clean and readable.
In C adding new stuff can make your code become unreadable.

Mamba
05-12-2001, 08:05 AM
Originally posted by Benjy:
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.

By "logical" you must mean "efficient".
"a=b+c" is logical, "sum(&b, &c, &a)" is efficient but not logical.

Just try implementing a vector-class supporting the arithmetic operators, using pointers instead of copying. Your vector calculations will be as ugly as in Java: "sum(mul(a, b, t1), mul(c, d, t2), e)" instead of "e=a*b+c*d". What's the point of operator overloading if it's not efficient and noone wants to use it?

The point of OO is to be able to extend the typesystem and to be able to use all types in a generic way. Using Vector or any other class should be as straight forward as using int or float.

For me, this is the end of this discussion. Just read the classic "A Critique of C++" (http://burks.bton.ac.uk/burks/pcinfo/progdocs/cppcrit/index.htm) and maybe you'll realize how many flaws there are in C++.

Benjy
05-12-2001, 08:45 AM
I'm not quite sure I understand you properly Mamba - I'm not a proper programmer, just a chemical engineer who likes computers.

Surely a logical *and* efficient way to implement operator overloading in, for example, vertex classes would be something like:

class vertex
{
public:
float x,y,z;
vertex* operator +(const vertex& rhs);
};

vertex* vertex: http://www.opengl.org/discussion_boards/ubb/redface.gifperator+ (const vertex & rhs)
{
vertex*temp=new vertex();
temp->x=x+rhs.x;
temp->y=y+rhs.y;
temp->z=z+rhs.z;
return (temp);
}

By returning a pointer to a vertex, you only have to create one new vertex object and don't have to copy it at all.

I realise it's a bit odd writing vert1=*vert2+*vert3, and that you can't do vert1=*vert2+*vert3+*vert4 without writing the nasty line vert1=*(*vert1+*vert2)+*vert4, but at least it's better than nothing

[This message has been edited by Benjy (edited 05-12-2001).]

ffish
05-12-2001, 10:11 PM
Benjy, that code has a few problems. For starters, you shouldn't allocate memory in a function like that unless you really know what you're doing. What if you gave that code's interface to another programmer and they wrote something like this:



vertex v1;
vertex v2;
for (int i(0); i<1000000; ++i) {
vertex *v3 = v1 + v2;
}
Where does the memory go that has been allocated by the new function inside operator+ ? It's a memory leak which would be at least sizeof(3*float)*1000000 - 1 bytes. The way to write the functions you need is like this:



class vertex
{
public:
float x,y,z;
const vertex&amp; operator+=(const vertex&amp; rhs);
};

const vertex&amp; vertex: http://www.opengl.org/discussion_boards/ubb/redface.gifperator+=(const vertex&amp; rhs)
{
x+=rhs.x;
y+=rhs.y;
z+=rhs.z;
}

const vertex operator+(const vertex&amp; lhs, const vertex&amp; rhs)
{
vertex temp(lhs);
return temp+=rhs;
}
This code is efficient, easy to use and natural. You can call it as v3 = v1 + v2 or v2 += v1 without pointer dereferencing. The operator+= returns a const reference, like it should, which is for all purposes just a const pointer to a const object so you get pointer efficiency, plus you don't have to create an object since it's a member function. The operator+ pretty much has to create an object and return it by value, for reasons that I won't go into here.


[This message has been edited by ffish (edited 05-13-2001).]

Benjy
05-13-2001, 12:30 AM
Thanks for the advice. I've been a casual programmer for years, but next academic year I start a phd that's going to require a lot of coding, so I'm trying to learn as much as possible.