>I only subscribed to this group 2 days ago, so I was luck to see the
>posting of the FAQ. It answered an important question for me, which I
>list below to provoke discussion. I do this because, until I read the
>FAQ, I thought a NeXT might be nice to have. But if programming in
>NeXT is "best" using objective C (which it must be, if NeXT encourages
>it), and if programming my science is worse in objective C than in
>C++, then NeXT won't help me.
NeXTstep itself is in Objective, and you'll have to use Objective
dispatch to get to it. But, that doesn't mean you can't use C++. In
fact, you can do all of your app. in C++ but use Objective wrappers to
talk to NeXTstep. This would allow using all of the nifty (and often-
abused) aspects of C++ to do your computational work (for an example of
this, take a look at Next's Calculator Lab from the Developer's demos).
Oh, and it all compiles with the SAME compiler (g++).
Quote:> Q: Is objective C useful for my work?
> A: No, since it does no operator overloading. The best thing about
> these new variants of C is operator overloading, as far as I can
> see. I like the idea that I can define a class to store my data,
> and within it define how to add data-sets, or input/output data
> sets, using the same notation for my data as for an int. If I
> have to do these things with function calls, then I'm back to the
> old C (or even FORTRAN) philosophy, and I'm not willing to dig
> that far back into the past.
Yes, overloading is one of the best new things about this new variant of C
(C++, I mean), operator overloading in particular is NOT one of the best
new things, because it tempts people to use overloaded operators where
they are not applicable, they are confusing (now, let's see, is this
particular 'plus' here in my code calling some routine or is it just a
normal plus), and, this person has made the classical mistake of assuming
that he's somehow avoiding function call overhead. It's pretty obvious that
if a routine is virtual, then the compiler cannot simply plug the proper code
in where necessary; the run-time system must deal with dispatch. Thus,
all those nifty little operators are function calls anyways (and virtuals
at that). I am fairly convinced that there are FEW places where one would
benefit from overloading an arithmetical operator. It is almost always
better to define something as A.SomeAdditiveOperation(B) than A + B, even
if it makes for uglier, albeit very easy to figure out, code. Besides,
you avoid the one true evil: THINKING ABOUT PRECEDENCE :o)!
Tim McClarren | "I see the pestilence outside my window
(217)244-0015 | I face the morning with my customary sigh" -- Fishbone