Object-oriented programming: Objective-C or C++? 5

[WebDrake]

Hello all,

For my code work up until now (scientific number-crunching) I have used C, but there are a handful of cases where it would be useful to have some object-oriented programming (e.g. for simulation of traders bidding on a stock market, or similar multi-agent work).

I've dealt with this kind of thing before by using structs, but it would be nice to be more elegant, and I suspect that it's not the fastest way to implement what I'm doing anyway.

So, I'm wondering if anyone can advise me on pros and cons of Objective-C versus C++. In principle I think I'd favour ObjC as it's a strict superset of C---right?---meaning I don't have to worry about minor code incompatibilities.

I also care a lot about code speed, so the question of which has the better libraries/compiler performance etc. is important.

Thanks in advance,

-- Joe

 

[xwb]

There are more C++ compiers about than Objective-C libraries. Not necessarily better like VHS versus Betamax: just a lot more about to choose from.

Re employment: more employers looking for C++ than objective-c programmers.

 

[WebDrake]

Thanks for the suggestions.

I have to say that employment isn't really an issue here since I don't make a living from programming. The main thing for me is what might be preferable from a number-crunching speed point of view.

 

[Salem]

For any reasonably competent person writing the code, I'd say that the performance of each language is pretty much on a par with one another.

It's certainly not something I'd overly worry about in terms of choosing a language. One good design decision as to how to approach the problem can have vastly larger consequences on the performance of the resulting program.

--

 

[WebDrake]

For any reasonably competent person writing the code, I'd say that the performance of each language is pretty much on a par with one another.

Great. In that case I'm tempted to go with ObjC since it's a strict superset of C, meaning C code can be cut-and-paste without any worries. I'm thinking of code like this:

{
   int *a, *b, *c;

   a = malloc(5*sizeof(*a));
   b = malloc(5*sizeof(*b));
   c = malloc(5*sizeof(*c));
}

... Also, because Stephen Kochan has written a book on Objective C, and if it's anything like his book on C, it will be great fun to learn from. :-D

 

[xwb]

Hope you can find a good ObjC forum for your questions. There isn't a lot of activity on the Tek-tips ObjC forum.

 

[WebDrake]

Hope you can find a good ObjC forum for your questions. There isn't a lot of activity on the Tek-tips ObjC forum.

I noticed... ::sigh::

Thanks very much for helpful advice!

 

[ArkM]

It's interesting: the code

{
   int *a, *b, *c;

   a = malloc(5*sizeof(*a));
   b = malloc(5*sizeof(*b));
   c = malloc(5*sizeof(*c));
}

is legal and senseless in C: allocate memory then discard local pointers (declared in a block scope) - classical memory leak case...
Is it a farsighted policy - using of non-standardized language after high portable C?...
The performance of each (common) language is defined chiefly by its compilers quality. The performance of each (especially number-cranching) program is defined chiefly by math/comp method(s) and programmer's skill...

 

[Salem]

Maybe this?

http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html

--

 

[WebDrake]

is legal and senseless in C: allocate memory then discard local pointers (declared in a block scope) - classical memory leak case...

AAARRRGHHHHH!

You know I wouldn't actually use it like that, right?

 

[WebDrake]

Is it a farsighted policy - using of non-standardized language after high portable C?...

Good point. Does ObjC have an ANSI standard? I recall that C++ does.

As for portability, I'm unlikely to be using my code on any systems where gcc will not run.

 

[ArkM]

2 WebDrake: I know (you need not worry.

I have seen tons of number-crunching codes in Fortran, C and C++. I prefer C++ but I saw (and wrote) quite a well-organized pure C math codes in this area.

Take into account: more than 90% of these (real, not academic) codes source lines are interfaces, not a number-crunching (prepare data then sync processes then present results). This is the C++ OOP natural habitat (hunting area...

 

[Salem]

Something else to ponder.

If C++ takes a week to write and debug, but C takes a month to write and debug, then that buy's you 3 weeks of run-time before you start losing out.

How long are you estimating the program will take to run, and how many times are you planning to run it?

It it takes 60 minutes, and you're trying to save 5 minutes, people won't care because they'll still be at lunch.

http://www.prism.uvsq.fr/~cedb/local_copies/lee.html

Especially

1. Programmers tend to over-estimate the usefulness of the programs they write. The approximate value of an optimization is:
number of runs × number of users × time savings × user's salary
- time spent optimizing × programmer's salary

Also, each week you delay buys you a few extra MHz on the average clock speed of processors ;-)
So buying real hardware at the end rather than at the start can have a much greater performance impact than anything you do inside the code.

--

 

[ArkM]

Good formula. Now let's suppose: the application runs in scientific research or industrial environment, so 1000 collaborators (number of users) take part in the project, number of runs = 20000/year, time saving/run = 10 min on 1024-CPU cluster. It's not a speculative example.

Another case: if you may cut down typical time expences from 1 min to 10 sec, you may embed the module in a very efficient interactive environment (compare your salaries before and after that...

If your application runs 20 min, it's a batch job (by the site rules) but if it runs 15 min, it's high priority debugging job (feel a difference) - and so on...

There is a room for true fast codes in the word of number-crunching...

 

[robk3]

I really like Objective C a lot, and I used Kochans book to learn it. I liked his book so much, I bought his C book to add to my library.

I have also taught Myself C++ in 24 hours. I prefer ObjC to C from an aethetic point of view. I compile with GCC as well.

rob

 

[Walid]

One of the design objectives of C++ (Which proved to be a very very bad idea) was backward compatibility with C. This means that, any C++ compiler is by default and definition a C compiler as well. If your C code didn’t compile by a good C++ compiler that means it was compiled before by a mediocre C compiler that allows bad programming constructs. If you are going to learn any thing new, my advice is to make it C++. Not only for the great support you can get form the communities and the availability of free very well written libraries, but also for the good and solid programming skills you will gain by writing code for these very well designed compilers that was designed to minimize that chance of allowing you to shoot yourself in the foot.

After you done studying the object oriented feature of the language, you will feel right at home since all C style constructs and run time libraries still alive. If you don’t like the new STL:: vector for instance, which is a “smart, first class citizen array” you still can and welcome to use C style arrays. Invest your time in something worth it. That is my advice. Hope God will guide your way



Walid Magd (MCP)

The primary challenge of every software development team is to engineer the illusion of simplicity in the face of essential complexity.
-Grady Booch

 

[WebDrake]

If your C code didn’t compile by a good C++ compiler that means it was compiled before by a mediocre C compiler that allows bad programming constructs.

Not really true. A statement like

[tt]a = malloc(10*sizeof(*a));[/tt]

is good code and makes sense in C, but won't work in C++. The code that will work in C++, such as,

[tt]a = (int *)malloc(10*sizeof(int));[/tt]

is problematic from a C point of view, because the cast prevents the C compiler from recognising possible errors. But then, malloc is rather frowned on in C++ from what I've seen.

[N.B. Yes, I know that for really good code there will be added stuff to catch the case where the memory doesn't allocate. ;-) ]

My typical compile spec is to use [tt]gcc -ansi -pedantic -Wall[/tt], which isn't too tolerant of bad programming constructs.

BTW things like the C++ STL:: vector can be problematic for number-crunching because they are too slow for really extensive work. "Don't like" doesn't come into it. It's great for what it's designed for, but that often conflicts with what I'm interested in achieving.

This probably sounds like an ungrateful rejection of your comments, but it's not meant to be, and I'm very grateful for your good wishes.

-- Joe

 

[WebDrake]

I really like Objective C a lot, and I used Kochans book to learn it. I liked his book so much, I bought his C book to add to my library.

I really loved Kochan's C book; it's a fantastic resource and getting it made some major improvements to my skills and understanding. I wish he'd written one for C++, since in the short term that's the language I've decided to go with, but I'll keep ObjC in mind for the future.

 

[Salem]

> If your C code didn’t compile by a good C++ compiler that means it was compiled before by a mediocre C compiler
Not so - C++ is not a syntactic superset of C, therefore not all valid C programs are immediately valid C++ programs (poor or otherwise).

There are many more reserved words in C++ (eg. class), which are perfectly valid C identifiers.

$ cat bar.cpp
int main ( ) {
  int class;
}
$ g++ -c bar.cpp
bar.cpp: In function `int main()':
bar.cpp:2: error: expected primary-expression before "int"
bar.cpp:2: error: expected `;' before "int"
$ g++ -xc -c bar.cpp
$

I quite often use the identifier 'new' when allocating a new block of memory.

Also, some constructs have different meanings in C and C++. So assuming that you got a clean compile, you could get different answers (eg. sizeof('a') is different).

http://david.tribble.com/text/cdiffs.htm

C99 introduces yet more features (like restrict) which are not in C++ at all.

Like English and American, two languages diverging from a common heritage, but now somewhat different.

--