f



Why Objective-C?


I understand Objective-C is a heritage from the NextStep time (correct me if
I'm wrong)

But why should we use it now in 2004?

Objective-C seems dead (whas is ever alive?) on every platform except OS X

We live in a world were Apple struggles for it's life and the last thing we
needed was a dead language
(Apple did get rid of it's Pascal heritage just to do it over again)

What I mean is that developers wants to write software on their favorite
platform but not to any price.

With C++ you can do anything that Objective-C does and more and it exists on
every existing platform:
Mac, Windows, UNIX, etc

We don't need:
Objective-C
C#
Visual Basic
Java
Db

It just a way to lock programers to a specific platform (well maybe not Java
and alike but you get the idea)

Most of us (Mac addicts) write software for severall platforms and it need
to be as platform independent
as possible.

Tell me I'm wrong

R


0
Rolf
5/14/2004 9:03:07 PM
comp.sys.mac.programmer.help 4653 articles. 2 followers. Post Follow

126 Replies
767 Views

Similar Articles

[PageSpeed] 25

In article <fuapc.59108$mU6.238465@newsb.telia.net>,
 "Rolf Nilsson" <nospam@nowaynomail.nu> wrote:

> Tell me I'm wrong

You are neither right nor wrong. You have, however, start a thread that is bound 
to become a pointless religious war. Enjoy... I hope you can find some useful 
information by the time the dust settles.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/14/2004 9:12:42 PM
On Fri, 14 May 2004, Rolf Nilsson wrote:

[snip]
> With C++ you can do anything that Objective-C does and more and it exists on
> every existing platform:
> Mac, Windows, UNIX, etc
>
> We don't need:
> Objective-C
> C#
> Visual Basic
> Java
> Db
[snip]
> Tell me I'm wrong

This is such an obvious troll. Try harder next time! If anybody actually
wants to know about the issues raised, search Google Groups; it's been
done to death.
0
Michael
5/14/2004 10:08:08 PM
Rolf Nilsson wrote:
> I understand Objective-C is a heritage from the NextStep time (correct me if
> I'm wrong)
> 

This could be a troll, but I'll try to answer without fueling the flames.

> But why should we use it now in 2004?

Because it enables very rapid development on Mac OS X.

> 
> Objective-C seems dead (whas is ever alive?) on every platform except OS X
> 
> We live in a world were Apple struggles for it's life and the last thing we
> needed was a dead language
> (Apple did get rid of it's Pascal heritage just to do it over again)
> 
> What I mean is that developers wants to write software on their favorite
> platform but not to any price.

I don't think there's many developers who left the Mac solely because 
the Mac started supporting Objective-C.

> 
> With C++ you can do anything that Objective-C does and more

This isn't true.  But if you think it is, please go ahead and expose the 
Cocoa libraries to C++.  A lot of people would be happy should you succeed.

> and it exists on
> every existing platform:
> Mac, Windows, UNIX, etc
> 
> We don't need:
> Objective-C
> C#
> Visual Basic
> Java
> Db

We don't strictly need anything except a way to enter machine code. 
Each of the languages you mentioned has its strengths and is a good 
choice for certain programs.

> 
> It just a way to lock programers to a specific platform (well maybe not Java
> and alike but you get the idea)
> 
> Most of us (Mac addicts) write software for severall platforms and it need
> to be as platform independent
> as possible.

It's quite possible to use Objective-C as your front end and any of a 
host of other languages as your back end.  But if Objective-C doesn't 
fit your needs, you don't have to use it.

> 
> Tell me I'm wrong
> 
> R



0
Peter
5/15/2004 1:08:12 AM
seems like these discussions get polemic pretty quickly.  this
particular one doesn't appear to have gotten out of hand yet, so let's
see if i can keep from making it worse ...

Rolf Nilsson wrote:
> Objective-C seems dead (whas is ever alive?) on every platform
> except OS X

apple makes lots of decisions that other companies wouldn't.  i'd say
that, most of the time, that's a GOOD thing, and that most mac users
consider that sort of daring to be why they are in this camp.

> With C++ you can do anything that Objective-C does and more and
> it exists on every existing platform:

there's always stuff on every platform that exists on no other.  you
can't write windows programs on unix, because it doesn't have the same
apis.  you wouldn't be able to use windows api c++ code unchanged on a
mac anyway.  you're going to have to re-write it, so the fact that the
new code is in a different language is not all that important.

also, there really *are* things you can do in obj-c that you can't do in
c++, at least not without jumping through fiery hoops.  obj-c is
runtime-dynamic, and cocoa takes great advantage of that to facilitate
inter-object communication.  i am not a great fan of the language, but
it does have many advantages.  it emphasizes a very different set of
priorities than does c++.

Peter Ammon wrote:
> Because it enables very rapid development on Mac OS X.

i wouldn't say it's obj-c doing that, but rather the cocoa frameworks
themselves.  they are very comprehensive, provide lots of useful default
behaviors that can be overridden when you need to, and its constituent
pieces interoperate and cooperate to a much greater degree than in most
OSes.  i don't see how any of this is particular to obj-c, though.
could have been done in another language.
0
ISO
5/15/2004 2:00:49 AM
In article <fuapc.59108$mU6.238465@newsb.telia.net>,
 "Rolf Nilsson" <nospam@nowaynomail.nu> wrote:

> With C++ you can do anything that Objective-C does and more

Yet more evidence to support my contention that developing with C++ 
damages people from an OO perspective.  Merely being Turing Complete is 
not a sufficient language feature.  Just for fun, give me the C++ for 
this 4-liner:

NSSet *myValues = [NSSet set];
[myValues addObject: [NSNumber numberWithInt: 42]];
[myValues addObject: @"1337"];
NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);

> Tell me I'm wrong

Hell, I'll tell you you're a complete idiot.
0
Doc
5/15/2004 1:39:18 PM
In article <fuapc.59108$mU6.238465@newsb.telia.net>,
 "Rolf Nilsson" <nospam@nowaynomail.nu> wrote:

> I understand Objective-C is a heritage from the NextStep time (correct me if
> I'm wrong)
> 
> But why should we use it now in 2004?

Because it's good. It's a tool, right? And you pick tools based on their 
suitability for the task, right? Well, Objective-C, in conjunction with 
Cocoa, is a tool that is _highly_ suitable for mainstream desktop 
development.

> Objective-C seems dead (whas is ever alive?) on every platform except OS X
> 
> We live in a world were Apple struggles for it's life and the last thing we
> needed was a dead language

Happily, what "seems" to be the case to you isn't reality.

> (Apple did get rid of it's Pascal heritage just to do it over again)
> 
> What I mean is that developers wants to write software on their favorite
> platform but not to any price.
> 
> With C++ you can do anything that Objective-C does and more

False. Dead false.

> and it exists on every existing platform:
> Mac, Windows, UNIX, etc

So does Objective-C.

> We don't need:
> Objective-C
> C#
> Visual Basic
> Java
> Db

But they all have different strengths.

> It just a way to lock programers to a specific platform (well maybe not Java
> and alike but you get the idea)
> 
> Most of us (Mac addicts) write software for severall platforms and it need
> to be as platform independent as possible.

Objective-C is not a problem there.

> Tell me I'm wrong

You're wrong. HTH.

G

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/15/2004 6:58:28 PM
In article <PM0003DA6CF6142351@minion.nashville.comcast.net>,
 J�hnny F�v�r�t� (it means "halo, then resonate") <this.is@fake.com> 
 wrote:

> Peter Ammon wrote:
> > Because it enables very rapid development on Mac OS X.
> 
> i wouldn't say it's obj-c doing that, but rather the cocoa frameworks
> themselves.

It's both, largely because the Cocoa frameworks a so reliant on 
Objective-C.

> they are very comprehensive, provide lots of useful default
> behaviors that can be overridden when you need to, and its constituent
> pieces interoperate and cooperate to a much greater degree than in most
> OSes.  i don't see how any of this is particular to obj-c, though.
> could have been done in another language.

Not well. You could get close in Java, but not dead on.

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/15/2004 7:01:12 PM
In article <droleary.usenet-89B24E.08391715052004@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <fuapc.59108$mU6.238465@newsb.telia.net>,
>  "Rolf Nilsson" <nospam@nowaynomail.nu> wrote:
> 
> > With C++ you can do anything that Objective-C does and more
> 
> Yet more evidence to support my contention that developing with C++ 
> damages people from an OO perspective.  Merely being Turing Complete is 
> not a sufficient language feature.  Just for fun, give me the C++ for 
> this 4-liner:
> 
> NSSet *myValues = [NSSet set];
> [myValues addObject: [NSNumber numberWithInt: 42]];
> [myValues addObject: @"1337"];
> NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);

Cruel, Doc.

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/15/2004 7:01:55 PM
In article <gwestonREMOVE-F8196E.15015615052004@netnews.comcast.net>,
 Gregory Weston <gwestonREMOVE@CAPSattbi.com> wrote:

> In article <droleary.usenet-89B24E.08391715052004@corp.supernews.com>,
>  Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > In article <fuapc.59108$mU6.238465@newsb.telia.net>,
> >  "Rolf Nilsson" <nospam@nowaynomail.nu> wrote:
> > 
> > > With C++ you can do anything that Objective-C does and more
> > 
> > Yet more evidence to support my contention that developing with C++ 
> > damages people from an OO perspective.  Merely being Turing Complete is 
> > not a sufficient language feature.  Just for fun, give me the C++ for 
> > this 4-liner:
> > 
> > NSSet *myValues = [NSSet set];
> > [myValues addObject: [NSNumber numberWithInt: 42]];
> > [myValues addObject: @"1337"];
> > NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);
> 
> Cruel, Doc.

Without commenting on the relevant value of C++ vs Obj-C the example is 
not a fair comparison of the two languages. 

Were it not for the Cocoa framework there would be significantly more 
lines of code than the 4 shown.

Perhaps someone would like to make an example using PPX- I have been 
living in cocoa for the last year so havn't even looked at PPX.

Anyway language wars are futile. Use whatever you like.

respect...

Peter
0
Peter
5/15/2004 9:48:54 PM
In article <gwestonREMOVE-A1C750.14582915052004@netnews.comcast.net>,
 Gregory Weston <gwestonREMOVE@CAPSattbi.com> wrote:
<snip>
> > and it exists on every existing platform:
> > Mac, Windows, UNIX, etc
> 
> So does Objective-C.
> 
Unfortunately the Cocoa framework does not exist on every platform as 
far as I know. And trying to develop without it is just as difficult as 
using C++ without PPX or MacApp or (shudder) MFC (or whatever they use 
over there these days) <puts on peril sunglasses>.

I certainly find Obj-C + Cocoa a powerful tool set and it's a lot of fun 
to develop in as well. But at this point in time it's a Mac only 
combination as far as I know.

respect...

Peter
0
Peter
5/15/2004 9:55:18 PM
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <fuapc.59108$mU6.238465@newsb.telia.net>,
>  "Rolf Nilsson" <nospam@nowaynomail.nu> wrote:
> 
> > With C++ you can do anything that Objective-C does and more
> 
> Yet more evidence to support my contention that developing with C++
> damages people from an OO perspective.  Merely being Turing Complete is
> not a sufficient language feature.  Just for fun, give me the C++ for this
> 4-liner:
> 
> NSSet *myValues = [NSSet set];
> [myValues addObject: [NSNumber numberWithInt: 42]];
> [myValues addObject: @"1337"];
> NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);

That's unfair, because it's not really a 4-liner. Someone wrote the NS
framework that lets you use only 4 lines to do what you've done. The
question then becomes one of whether you're comparing the languages or
the framework.

Here's a more purely language-oriented challenge (the one -intValue
relies on, so it's not that different from yours in spirit):

id tellTheObjectToDoTheMethod (id anObject, SEL aMethod)
  {
  // substitute 'perform:' as needed.
  return [anObject performSelector:aMethod];
  }
0
usenet
5/16/2004 2:59:23 AM
Peter Teeson <noone@nowhere.com> wrote:

> Unfortunately the Cocoa framework does not exist on every platform as
> far as I know. [..]

You're not exactly wrong, but you're not exactly right, either.

<http://www.gnustep.org/information/aboutGNUstep.html>
0
usenet
5/16/2004 2:59:23 AM
In article 
<noone-8D8168.17492315052004@nntp.bloor.is.net.cable.rogers.com>,
 Peter Teeson <noone@nowhere.com> wrote:

> Without commenting on the relevant value of C++ vs Obj-C the example is 
> not a fair comparison of the two languages. 

It's perfectly fair.

> Were it not for the Cocoa framework there would be significantly more 
> lines of code than the 4 shown.

Use the STL all you like.  Nothing about the code I gave has to do with 
object libraries, but rather language fundamentals.  Templates do not a 
container make, and user defined types are not the same as objects.  The 
core things to take away from my example is that you can use untyped 
containers, and you can call methods polymorphically on its contents.

> Anyway language wars are futile. Use whatever you like.

Indeed, there truly is no accounting for taste.
0
Doc
5/16/2004 1:38:43 PM
In article <1gdud8a.1tb6zgo1ju7nr4N%usenet@mile23.com.r3m0v3>,
 usenet@mile23.com.r3m0v3 (Paul Mitchum) wrote:

> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > NSSet *myValues = [NSSet set];
> > [myValues addObject: [NSNumber numberWithInt: 42]];
> > [myValues addObject: @"1337"];
> > NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);
> 
> That's unfair, because it's not really a 4-liner. Someone wrote the NS
> framework that lets you use only 4 lines to do what you've done. The
> question then becomes one of whether you're comparing the languages or
> the framework.

As I noted in another post, it's perfectly fair.  Use whatever string, 
number, and container objects you like with C++ and the above is still a 
bitch.  The STL is a demonstration of just how flawed C++ is when 
compared to what you can get by actually supporting *objects* in an OO 
language.  Any C++ advocate is welcome to hand-wave whatever class 
library they want, just show me some code that matches the above.
0
Doc
5/16/2004 1:45:24 PM
In article 
<noone-76A44B.17554715052004@nntp.bloor.is.net.cable.rogers.com>,
 Peter Teeson <noone@nowhere.com> wrote:

> In article <gwestonREMOVE-A1C750.14582915052004@netnews.comcast.net>,
>  Gregory Weston <gwestonREMOVE@CAPSattbi.com> wrote:
> <snip>
> > > and it exists on every existing platform:
> > > Mac, Windows, UNIX, etc
> > 
> > So does Objective-C.
> > 
> Unfortunately the Cocoa framework does not exist on every platform as 
> far as I know.

Cocoa doesn't, but GNUstep - modeled on it - is highly portable. As a 
result, Foundation code is actually more portable that PowerPlant or MFC 
or MacApp.

G

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/16/2004 6:41:19 PM
In article <droleary.usenet-743B3E.08384316052004@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> It's perfectly fair.

Based on the terms of your example, can be my complete c++
implementation of Adobe Photoshop:

int main()
{
   CPhotoshopApp theApp;
   theApp.Run();
   return 0;
}

Wow, c++  must be a superior language!!!!!!!!!

Congratulation on proving you don't have a clue.  :)
0
Chris
5/16/2004 7:36:14 PM
In article <droleary.usenet-5FAA7C.08452416052004@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> As I noted in another post, it's perfectly fair.  Use whatever string, 
> number, and container objects you like with C++ and the above is still a 
> bitch.  The STL is a demonstration of just how flawed C++ is when 
> compared to what you can get by actually supporting *objects* in an OO 
> language.

Here's free clue:  The STL is part of the c++ language. Cocoa is not
part of the Obj-C language.  If you think the STL is the only set
containers in c++ apps, you need to get out of the house.  If you're
serious about educating yourself, check out boost.org.
0
Chris
5/16/2004 7:44:42 PM
In article <droleary.usenet-5FAA7C.08452416052004@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <1gdud8a.1tb6zgo1ju7nr4N%usenet@mile23.com.r3m0v3>,
>  usenet@mile23.com.r3m0v3 (Paul Mitchum) wrote:
> 
> > Doc O'Leary <droleary.usenet@subsume.com> wrote:
> > 
> > > NSSet *myValues = [NSSet set];
> > > [myValues addObject: [NSNumber numberWithInt: 42]];
> > > [myValues addObject: @"1337"];
> > > NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);
> > 
> > That's unfair, because it's not really a 4-liner. Someone wrote the NS
> > framework that lets you use only 4 lines to do what you've done. The
> > question then becomes one of whether you're comparing the languages or
> > the framework.
> 
> As I noted in another post, it's perfectly fair.  Use whatever string, 
> number, and container objects you like with C++ and the above is still a 
> bitch.  The STL is a demonstration of just how flawed C++ is when 
> compared to what you can get by actually supporting *objects* in an OO 
> language.  Any C++ advocate is welcome to hand-wave whatever class 
> library they want, just show me some code that matches the above.

The code you wrote above is trivial in C++ if you have a Number class and a 
String class that are derived from the same base and the base has an intValue 
abstract member function. As a result, the advantage of your code is not in C++, 
but in the ready availability of suitable NSNumber and NSString classes in the 
Cocoa framework.

The other example (perform with selector) provided as a challenge was far more 
appropriate.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/16/2004 7:45:22 PM
Cuz it's awesome!  Having used many other languages (C, C++, Java,
REALBasic, Fortran, perl, etc.), Objective C is by far my favorite.  

Old doesn't always mean bad - even in the computer world.


0
heliosnorf
5/16/2004 9:45:08 PM
Here's my impression of Objective-C and Cocoa, after having actually
used them (see http://www.ed.com/osx/vipc.html).

I am already familiar with the general concept behind the dynamic
approach used by Objective-C, so obviously will disagree that it is
interchangeable with C++.  But to compare the two is to compare apples
and oranges.

The syntax added to C is quite small, as is often mentioned, but
learning the syntax of Objective-C means absolutely nothing.
Objective-C, like Smalltalk and even Java, is defined more by the
accompanying class library than the language itself.

One good thing about Objective-C is that it is completely integrated
with C.  Another is that the hybrid Objective-C++ compiler works as
expected for the most part.

What this means to a C++ programmer is that, to the extent that you
are programming in C when you use Objective-C, and to the extent C++
allows you to bring more coherence and order to large programs, you
can use C++ to achieve the same benefits with Objective-C by simply
considering Cocoa to be a C library around which you can wrap C++
code.  I think this approach works very well, although you can't get
around having to learn Objective-C itself.
0
rhsu
5/17/2004 1:43:54 AM


On 5/16/04 2:36 PM, in article 160520041436141288%cbaum981@atlantic.net,
"Chris Baum" <cbaum981@atlantic.net> wrote:

> In article <droleary.usenet-743B3E.08384316052004@corp.supernews.com>,
> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
>> It's perfectly fair.
> 
> Based on the terms of your example, can be my complete c++
> implementation of Adobe Photoshop:
> 
> int main()
> {
>    CPhotoshopApp theApp;
>    theApp.Run();
>    return 0;
> }
> 
> Wow, c++  must be a superior language!!!!!!!!!
> 
> Congratulation on proving you don't have a clue.  :)

....and in which library or framework did you find the CPhotoshopApp class?
 

Jim Spencer
Rochester, MN

"Badges?  Badges?  We don't need no stinkin badges!"
While I would agree that the original comparison wasn't a fair comparison of
the LANGUAGES, at least it used a real framework for the example and the
criticism of the lack of ease of use of C++'s collection classes as compared
to Objective C is valid too.

0
James
5/17/2004 1:58:12 AM
In article <BCCD8664.17E9%jspencer78@mac.com>,
 James Spencer <jspencer78@mac.com> wrote:

> the criticism of the lack of ease of use of C++'s collection classes as 
> compared to Objective C is valid too

No, it's not. It entirely depends on what you are trying to accomplish. Cocoa 
collection classes are only superior if you dismiss the possibility of someone 
actually wanting to know that the members of a collection satisfy a particular 
constraint. Objective-C provides no linguistic mechanism to guarantee the 
compliance of the members of a collection with a particular interface. The best 
you get is an exception when you fail to adhere to a constraint that can't be 
expressed in the language.

C++, on the other hand, allows you to do this, but it lacks in other areas, 
which also should not be dismissed.

In my personal opinion, there are important areas in which Objective-C is 
inferior to C++ as well as important ones in which it is superior. However, I 
also observed:

 - When I point out to the C++ community that C++ needs to support a particular 
feature that I consider it lacking compared to, for example, Objective-C, the 
response that I generally get is that I am right and that such a feature can be 
obtained using a language feature that I was unaware of, a library that I was 
not familiar with, or that it will be provided in the future after the proposal 
for addition of a relevant language or library feature is ratified by the 
committee. For example, full reflection and introspection, already available in 
Objective-C and Java, are works in progress by none other than Stroustrup. As a 
result, I conclude that the C++ committee is interested in understanding the 
needs of the user community, and is responsive, but is (sometimes severely) 
hampered by the history of C++ or some questionable compatibility constraints.

 - When I point out to the Objective-C community that Objective-C needs to offer 
better support for a development paradigm that C++ supports right now, people 
tell me that I must be doing something wrong if I came to believe that. For 
example, the above example of constrained collections is one that is typically 
met with "you only think you need that because you come from C++ background", if 
the person I am talking to is feeling particularly patient and polite. I rarely, 
if ever, find that anyone actually wants to seriously understand why I believe I 
want what I believe I want, much less consider it as a language or library 
feature. I therefore conclude that the Objective-C community is comprised mainly 
of proselytizing wankers with theirs head firmly implanted up their asses. Of 
course, Objective-C makes the process of getting your head up your ass very 
efficient. You just have to drag a line from your head to your ass in Interface 
Builder.

As a result, I feel that my long-term needs are better served by bringing the 
useful features of Objective-C over to C++, and also contributing to making C++, 
STL, and boost a better environment to work in, than by trying to bring a 
semblance of rationality to the Objective-C community.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/17/2004 8:17:02 AM
On Mon, 17 May 2004, Miro Jurisic wrote:

> In my personal opinion, there are important areas in which Objective-C is
> inferior to C++ as well as important ones in which it is superior. However, I
> also observed:
>
>  - When I point out to the C++ community that C++ needs to support a particular
> feature that I consider it lacking compared to, for example, Objective-C, the
> response that I generally get is that I am right and that such a feature can be
> obtained using a language feature that I was unaware of, a library that I was
> not familiar with, or that it will be provided in the future after the proposal
> for addition of a relevant language or library feature is ratified by the
> committee. For example, full reflection and introspection, already available in
> Objective-C and Java, are works in progress by none other than Stroustrup. As a
> result, I conclude that the C++ committee is interested in understanding the
> needs of the user community, and is responsive, but is (sometimes severely)
> hampered by the history of C++ or some questionable compatibility constraints.

Some people believe that a language shouldn't simply contain every single
idea or construct, but that a language should be based around one good,
central idea, and additions should be accepted or rejected based on that.
I make no claim (here) as to whether this is a good idea or not, but it is
a legitimate point of view; people holding it tend to dislike C++ exactly
*because* of this extreme flexibility on the part of the creators. Whether
this attitude reflects reality, I'll leave to the following flamewar to
sort out.
0
Michael
5/17/2004 9:54:13 AM
I started this thread (sorry?)

I was never arguing about or mentioning Cocoa (which is great) but "Why
Objective-C?" (at least that was the header,
maybe not the content of my posting).

And I know it's kind of stupid but I was frustrated (we are when things
don't work out as "it" should)

I'm a C++ addict coming from the Windows world, being a musician converted
to writing music software,
finding out "the" platform (Mac) in year 2000 (yes, before OS X), finding a
mish/mash of technologies,
interrupts/deferred tasks (happy I started out with 68000 assembler on the
Atari in the middle 80's knowing how
to deal with interrupts etc), Pascal examples and more, sigh...

But I finished my project/goal, then OS X came out, what a relief: protected
memory, real multitasking, threads etc.
Just to find out it was as much "greek" as before, looking for examples,
hints, advises, Obj-C examples, Cocoa, etc


I managed to convert a couple of Obj-C example classes to C++ classes
(big plus for Obj-C that being possible without knowing Obj-C), modifying
and extending the classes and made them cross platform
(QuickTime examples which have the same API under both Windows and Mac), and
that suits my programming style.


Really, new languages are a good thing, without that C++ would not exist ;-)
Right now I'm studying Obj-C (I've always been fond of the Smalltalk MVC
(Model/View/Controller) stuff) to be able to more easily
convert Obj-C code to C++, maybe to use the Cocoa for GUI interface if I can
mix that with my existing C++ classes without too
much problems.


So my frustration was a fruit of rewriting Obj-C examples to C++ for the nth
time, which if you know the Obj-C syntax is
no big deal, just time consuming and that was when I just felt, "Why
Objective-C?"

I have nothing against Cocoa, it's a beautiful class library/framework. One
of the problems seems to be the that people uses
the terms "Obj-C" and  "Cocoa" as it's the same thing. Even the Apple
document I'm just studying named "The Objective-C Programming Language", is
actually mentioning Cocoa over and over.

So my question still is:
Why did NextStep choose Objective-C?
Or was it the people with NextStep that created Objective-C?

Still curious

Rolf


0
RN
5/17/2004 9:58:04 AM
In article <160520041444421748%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> In article <droleary.usenet-5FAA7C.08452416052004@corp.supernews.com>,
> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > As I noted in another post, it's perfectly fair.  Use whatever string, 
> > number, and container objects you like with C++ and the above is still a 
> > bitch.  The STL is a demonstration of just how flawed C++ is when 
> > compared to what you can get by actually supporting *objects* in an OO 
> > language.
> 
> Here's free clue:  The STL is part of the c++ language.

No, it's not. Libraries are never "part of" the language.

> Cocoa is not
> part of the Obj-C language.  If you think the STL is the only set
> containers in c++ apps, you need to get out of the house.  If you're
> serious about educating yourself, check out boost.org.

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/17/2004 11:04:42 AM
In article <gwestonREMOVE-0993A7.07044117052004@netnews.comcast.net>,
Gregory Weston <gwestonREMOVE@CAPSattbi.com> wrote:

> No, it's not. Libraries are never "part of" the language.

Yes, the STL, or "Standard Library" as it is now referred is a
ratified/adopted part of the C++ specification.  If you are a
compiler-developer, you are not c++ compliant if you do not support
100% of the adopted Standard Library.  The formal (initial) adoption
into the standard took place in 1998.

boost.org is more akin to Cocoa (though parts of boost are up for
ratification into the next c++ standard).  Also, prior to 1998 the STL
was a 3rd party (AT&T Labs) library as you've described.

Does obj-c even have a standard?  Maybe that's why you're confused. . .
0
Chris
5/17/2004 2:41:24 PM
On Mon, 17 May 2004, Chris Baum wrote:

> Does obj-c even have a standard?

No, unless you count "implementation as standard". And since all of the
serious ObjC players either use gcc or copy it, it's not likely to ever
change.
0
Michael
5/17/2004 6:49:58 PM
In article <160520041444421748%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> In article <droleary.usenet-5FAA7C.08452416052004@corp.supernews.com>,
> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > As I noted in another post, it's perfectly fair.  Use whatever string, 
> > number, and container objects you like with C++ and the above is still a 
> > bitch.  The STL is a demonstration of just how flawed C++ is when 
> > compared to what you can get by actually supporting *objects* in an OO 
> > language.
> 
> Here's free clue:  The STL is part of the c++ language. Cocoa is not
> part of the Obj-C language.  If you think the STL is the only set
> containers in c++ apps, you need to get out of the house.  If you're
> serious about educating yourself, check out boost.org.

Way to not read my post.  As I said, you can use whatever class library 
you want.  Now show me the code.  Surely this toy example cannot be so 
very hard for this ultimate language you call C++!  When you've cranked 
it out, you might also want to note that nothing I did requires Cocoa, 
and the very next thing I'd do is ask you to maintain your code by 
adding in a model class like Employee that returns their ID for 
-intValue.  Feel free to get a jump on integrating that code for when I 
eventually ask for it.  Here it is on my part:

[myValues addObject: [Employee employeeWithID: 1234]];

My objects' behavior can be completely independent of the Cocoa class 
hierarchy, can yours function decoupled from your class library?  If you 
don't see the benefits of the ObjC runtime, C++ has damaged you.  It's 
OK; it has damaged a lot of people.  Now wake up, or you're just useless 
going forward as an OO developer.
0
Doc
5/17/2004 7:07:22 PM
In article <macdev-98D3A9.15452216052004@senator-bedfellow.mit.edu>,
 Miro Jurisic <macdev@meeroh.org> wrote:

> The code you wrote above is trivial in C++ if you have a Number class and a 
> String class that are derived from the same base and the base has an intValue 
> abstract member function.

So what you're saying is that the "trivial" solution is to tie all your 
classes together just to get minimal polymorphism?  Doesn't sound like 
much of an OO language, does it?  The toy example was only two classes, 
too.  It would be (is, in fact) a nightmare trying to maintain a large 
code base across multiple libraries in C++.

> As a result, the advantage of your code is not in 
> C++, 
> but in the ready availability of suitable NSNumber and NSString classes in 
> the 
> Cocoa framework.

So you say, but yet you show no code.  I'm really interested in seeing 
how you stick both the number and the string into a single (likely STL) 
collection such that you can extract one at random and call the member 
function.  Stop yacking on and on about how "trivial" it will be and 
show me.
0
Doc
5/17/2004 7:14:06 PM
In article <macdev-4EFFD2.04170217052004@senator-bedfellow.mit.edu>,
 Miro Jurisic <macdev@meeroh.org> wrote:

> No, it's not. It entirely depends on what you are trying to accomplish. Cocoa 
> collection classes are only superior if you dismiss the possibility of 
> someone 
> actually wanting to know that the members of a collection satisfy a 
> particular 
> constraint.

That is so funny, mostly because it is the exact *opposite* of reality.  
It is the C++ STL that limits you to how collection can be constrained.  
You're stuck with type.  With ObjC, there are any number of ways you can 
constrain a collection, and the mechanisms for doing so can involve 
adding category methods, subclasses (to the extent you can pose as the 
parent class), or simply defining your own collection that is 
specifically designed to act a certain way.

With C++, you are restricted out of the gate.  It must have really 
twisted your mind terribly for you to see that as a language feature.

> Objective-C provides no linguistic mechanism to guarantee the 
> compliance of the members of a collection with a particular interface. The 
> best 
> you get is an exception when you fail to adhere to a constraint that can't be 
> expressed in the language.

Simply not true.  You can easily create a class like NSNumberArray and 
define

- (void) addObject: (NSNumber *) aNumber;

and get the same level if compile time checking that a crappy C++ 
developer is so in love with.  The difference is that you *need* to do 
that in C++, whereas in ObjC the OO developer is only concerned with 
objects, as they should be.  The tradeoff is that ObjC doesn't have a 
mechanism to generate NS<type>Array for arbitrary types.  Why not?  
Because 99% of the time actually having objects makes that kind of 
hackery as required for C++ unnecessary for ObjC.
 
> For example, full reflection and introspection, already available 
> in 
> Objective-C and Java, are works in progress by none other than Stroustrup.

He puts out a crap language and you say "none other"?  I have zero 
respect for Bjarne.  Maybe he was steamrolled by an industry looking for 
a silver bullet, but he's have ample time to step back, do a language 
survey, and admit that C++ is junk compared to the alternatives.

> For 
> example, the above example of constrained collections is one that is 
> typically 
> met with "you only think you need that because you come from C++ background", 
> if 
> the person I am talking to is feeling particularly patient and polite. I 
> rarely, 
> if ever, find that anyone actually wants to seriously understand why I 
> believe I 
> want what I believe I want, much less consider it as a language or library 
> feature.

We already know why you believe what you believe; you're damaged goods.  
You're in a dysfunctional relationship with C++, and you're still 
staying with it and sticking up for its bad behavior.  As I said above, 
you can have typed containers (minus auto-generation hackery) as well as 
containers that can be constrained by increasingly advanced criteria.

> I therefore conclude that the Objective-C community is comprised 
> mainly 
> of proselytizing wankers with theirs head firmly implanted up their asses. Of 
> course, Objective-C makes the process of getting your head up your ass very 
> efficient. You just have to drag a line from your head to your ass in 
> Interface 
> Builder.

Heh.  It's equally as easy to remove that "connection".  To be sure, I 
still take issue with the way ObjC does some things.  My solution, 
however, is not to regress to a crap language like C++, but rather to 
look at more advanced language designs like Self and Io.  So as much as 
ObjC wankers have done wrong, what they have done right is to not 
believe the hype of the languages that got a big push in marketing.  
Both C++ and Java got huge industry support for some reason despite the 
fact that they offered nothing interesting compared to alternatives that 
were available (often decades) before them.

> As a result, I feel that my long-term needs are better served by bringing the 
> useful features of Objective-C over to C++, and also contributing to making 
> C++, 
> STL, and boost a better environment to work in, than by trying to bring a 
> semblance of rationality to the Objective-C community.

Stop wasting your life.  C++ is an abusive partner.  You need to seek 
counseling to end your codependent nightmare.
0
Doc
5/17/2004 7:52:16 PM
In article <droleary.usenet-8CA881.14140617052004@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> So you say, but yet you show no code.  I'm really interested in seeing 
> how you stick both the number and the string into a single (likely STL) 
> collection such that you can extract one at random and call the member 
> function.  Stop yacking on and on about how "trivial" it will be and 
> show me.

Here you go. First we'll whip up some counterparts to your framework:

#include <string>
using std::string;

#include <vector>
using std::vector;

#include <iostream>
using std::cout;

#include <boost/lexical_cast.hpp>
using boost::lexical_cast;

template <typename RandomAccessIterator>
typename RandomAccessIterator::value_type
RandomItem(
   RandomAccessIterator    inBegin,
   RandomAccessIterator    inEnd)
{
   return *(inBegin + drand48() * (inEnd - inBegin));
}

class IntConvertibleBase {
   public:
      virtual int ConvertToInt() const = 0;
};

template <typename T>
class IntConvertible:
   public IntConvertibleBase {

   public:
      explicit IntConvertible(
         const T&    inData):
         mData(inData)
      {
      }

      virtual int ConvertToInt() const 
      {
         return lexical_cast<int>(mData);
      }

   private:
      T  mData;   
};


Then a little bit of syntactic sugar to make the code below easier to write:


template <typename T>
IntConvertible<T>*
MakeIntConvertible(const T& inData)
{
   return new IntConvertible<T>(inData);
}




And then you get your four-liner.


int main()
{
   vector<IntConvertibleBase*>   items;
   items.push_back(MakeIntConvertible(1));
   items.push_back(MakeIntConvertible(string("13")));

   cout << RandomItem(items.begin(), items.end())->ConvertToInt();
}


You should note how I was able to accomplish the amazing feat without any 
changes to existing classes (int and string, which I can't change anyway). You 
should also note how I was able to provide a default implementation for 
ConvertToInt while allowing myself to provide a more specific one (with a 
template specialization) in those cases when lexical_cast doesn't do what I want.

Whop te doo.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/17/2004 8:01:00 PM
In article <droleary.usenet-15F0E5.14521617052004@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <macdev-4EFFD2.04170217052004@senator-bedfellow.mit.edu>,
>  Miro Jurisic <macdev@meeroh.org> wrote:
> 
> > No, it's not. It entirely depends on what you are trying to accomplish. 
> > Cocoa collection classes are only superior if you dismiss the possibility 
> > of someone actually wanting to know that the members of a collection 
> > satisfy a particular constraint.
> 
> That is so funny, mostly because it is the exact *opposite* of reality.  It 
> is the C++ STL that limits you to how collection can be constrained.  You're 
> stuck with type.  

You are not. Look at boost::any and boost:variant.

> With ObjC, there are any number of ways you can constrain a 
> collection, 

None of which work at compile time, except writing your own...

> and the mechanisms for doing so can involve adding category methods, 
> subclasses (to the extent you can pose as the parent class), or simply 
> defining your own collection that is specifically designed to act a certain 
> way.

If you start throwing around the argument that you can always just write your 
own, then you will have to concede that both languages are Turing-complete. As 
long as I am allowed to write everything I need completely from scratch, they 
are equivalent.

> With C++, you are restricted out of the gate.  It must have really twisted 
> your mind terribly for you to see that as a language feature.

I see you made it to the Objective-C wanker mark faster than you usually do. 
Congratulations.

> Stop wasting your life.  C++ is an abusive partner.  You need to seek 
> counseling to end your codependent nightmare.

You are right, you and others like you make for much better company.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/17/2004 8:05:44 PM
Miro Jurisic wrote:
[...]
>  - When I point out to the C++ community that C++ needs to support a particular 
> feature that I consider it lacking compared to, for example, Objective-C, the 
> response that I generally get is that I am right and that such a feature can be 
> obtained using a language feature that I was unaware of,

Doesn't it bother you that there are language features you aren't aware 
of?  I've been using C++ off and on for five years, trying to learn as 
much about it as I can, and I still run into things I don't know. 
http://www.gotw.ca/gotw/ leaves me gasping.

[...]

-Peter

0
Peter
5/17/2004 9:57:32 PM
Miro Jurisic <macdev@meeroh.org> wrote in message news:<macdev-98D3A9.15452216052004@senator-bedfellow.mit.edu>...
> In article <droleary.usenet-5FAA7C.08452416052004@corp.supernews.com>,
>  Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > In article <1gdud8a.1tb6zgo1ju7nr4N%usenet@mile23.com.r3m0v3>,
> >  usenet@mile23.com.r3m0v3 (Paul Mitchum) wrote:
> > 
> > > Doc O'Leary <droleary.usenet@subsume.com> wrote:
> > > 
> > > > NSSet *myValues = [NSSet set];
> > > > [myValues addObject: [NSNumber numberWithInt: 42]];
> > > > [myValues addObject: @"1337"];
> > > > NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);
> > > 
> > > That's unfair, because it's not really a 4-liner. Someone wrote the NS
> > > framework that lets you use only 4 lines to do what you've done. The
> > > question then becomes one of whether you're comparing the languages or
> > > the framework.
> > 
> > As I noted in another post, it's perfectly fair.  Use whatever string, 
> > number, and container objects you like with C++ and the above is still a 
> > bitch.  The STL is a demonstration of just how flawed C++ is when 
> > compared to what you can get by actually supporting *objects* in an OO 
> > language.  Any C++ advocate is welcome to hand-wave whatever class 
> > library they want, just show me some code that matches the above.
> 
> The code you wrote above is trivial in C++ if you have a Number class and a 
> String class that are derived from the same base and the base has an intValue 
> abstract member function. 

Yes, but the point is that you don't need such conditions in
Objective-C in order to achieve polymorphic method invocations. This
makes a real difference with C++. The example also illustrates the
fact that Objective-C support heterogeneous collections while C++
don't. This is why I think the example is perfectly appropriate, and,
actually, brilliant.
Remember that the goal was only to refute the original assertion that
"With C++ you can do anything that Objective-C does".

Best,

Philippe Mougin
--
F-Script: the open-source scripting language for Cocoa.
http://www.fscript.org
0
pmougin
5/17/2004 10:42:00 PM
In article <c8bcga$dgb$1@news.apple.com>,
 Peter Ammon <peter_ammon@rocketmail.com> wrote:

> Miro Jurisic wrote: [...]
> >  - When I point out to the C++ community that C++ needs to support a 
> >  particular 
> > feature that I consider it lacking compared to, for example, Objective-C, 
> > the response that I generally get is that I am right and that such a 
> > feature can be obtained using a language feature that I was unaware of,
> 
> Doesn't it bother you that there are language features you aren't aware of?  
> I've been using C++ off and on for five years, trying to learn as much about 
> it as I can, and I still run into things I don't know. 
> http://www.gotw.ca/gotw/ leaves me gasping.

No. Even if the language were a stationary target and I learn all its features, 
there would always be practices, libraries, methodologies, etc to learn. The 
fact that the language is evolving and I need to keep up with it as much as I 
have to to keep up with every other aspect of my professional expertise does not 
bother me.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/17/2004 10:43:22 PM
"RN" <nospam@nowaynomail.nu> wrote in message news:<M00qc.92699$dP1.292844@newsc.telia.net>...

[...]

> So my question still is:
> Why did NextStep choose Objective-C?

From the book "The Objective-C Programming Language", published by
Apple:

"The Objective-C language was chosen for the Cocoa framework for a
variety of reasons. First and foremost, it's an object-oriented
language. The kind of functionality that's packaged in the Cocoa
frameworks can only be delivered through object-oriented techniques.
This document explains the operation of the frameworks and how you can
take advantage of them.

Second, because Objective-C is an extension of standard ANSI C,
existing C programs can be adapted to use the software frameworks
without losing any of the work that went into their original
development. Since Objective-C incorporates C, you get all the
benefits of C when working within Objective-C. You can choose when to
do something in an object-oriented way (define a new class, for
example) and when to stick to procedural programming techniques
(define a structure and some functions instead of a class).

Moreover, Objective-C is a simple language. Its syntax is small,
unambiguous, and easy to learn. Object-oriented programming, with its
self-conscious terminology and emphasis on abstract design, often
presents a steep learning curve to new recruits. A well-organized
language like Objective-C can make becoming a proficient
object-oriented programmer that much less difficult. The size of this
book is a testament to the simplicity of Objective-C. It's not a big
book.

Compared to other object oriented languages based on C, Objective-C is
very dynamic. The compiler preserves a great deal of information about
the objects themselves for use at runtime. Decisions that otherwise
might be made at compile time can be postponed until the program is
running. This gives Objective-C programs unusual flexibility and
power. For example, Objective-C's dynamism yields two big benefits
that are hard to get with other nominally object-oriented languages:

Objective-C supports an open style of dynamic binding, a style that
can accommodate a simple architecture for interactive user interfaces.
Messages are not necessarily constrained by either the class of the
receiver or the method selector, so a software framework can allow for
user choices at runtime and permit developers freedom of expression in
their design. (Terminology like "dynamic binding," "message," "class,"
"receiver," and "selector" are explained in due course in this
document.)

Objective-C's dynamism enables the construction of sophisticated
development tools. An interface to the runtime system provides access
to information about running applications, so it's possible to develop
tools that monitor, intervene, and reveal the underlying structure and
activity of Objective-C applications. "

Best,

Philippe Mougin
--
F-Script: the open-source scripting language for Cocoa
http://www.fscript.org
0
pmougin
5/17/2004 11:06:17 PM
On 14/05/2004 5:03 PM, Rolf Nilsson wrote:

> I understand Objective-C is a heritage from the NextStep time (correct me if
> I'm wrong)
> 
> But why should we use it now in 2004?
> 
> Objective-C seems dead (whas is ever alive?) on every platform except OS X
> 
> We live in a world were Apple struggles for it's life and the last thing we
> needed was a dead language
> (Apple did get rid of it's Pascal heritage just to do it over again)
>
[...]

.... and nobody is really sure who fired the first shot in the Great 
Language Wars, but we do know that we all lost.

As a result, all coders were jailed and forced to hand-code in 4-bit 
chunks using a sticky keypad and an 7-segment display with segments missing.
0
clvrmnky
5/17/2004 11:16:16 PM
On Mon, 17 May 2004 14:52:16 -0500, Doc O'Leary
<droleary.usenet@subsume.com> wrote:
> > ... works in progress by none other than Stroustrup.
> 
> He puts out a crap language and you say "none other"?  I have zero 
> respect for Bjarne.  

I have a lot of respect for him. He was aware of much of the
compromise that went into C++ and chose to do it as a means of
popularising a paradigm that he felt was worthwhile but largely
ignored in the early '80s. In that aim he succeeded beyond his
expectations, without C++ OO would not have taken off and become
the pre-eminent paradigm that it is today.

I say that as someone who was using Smalltalk and Lisp for OO
before hitting C++ in '89, and my first formal training in OOD
used Objective C as the language, long before NeXTStep etc
appeared. But the bulk of our developers at the time could not be
persuaded that dynamic typing was safe - it was too much of a
culture shift, so we adopted C++. Most shops were the same, C++
seemed like a safer more manageable shift. Stroustrup understood
that and built C++ to make the migration easy.

> Maybe he was steamrolled by an industry looking for 
> a silver bullet, but he's have ample time to step back, do a language 
> survey, and admit that C++ is junk compared to the alternatives.

He has admitted that C++ is not the language he would have built
if starting with a clean sheet. Whether he should start again to
design a new language now that OO has become the standard
paradigm is a more interesting question. The designers of Unix
went on to design Plan 9 - hands up the Plan 9 users? 
C++ has largely achieved his objective for it, and maybe it 
is time to kill the monster it has grown into, but I suspect
inertia will keep it rolling for some time yet.

Certainly in our own company most of the C++ programmers have
switched to more dynamic languages like Smalltalk, Python, 
and Java(?!), even VB.NET. (Obj C isn't really on the table 
since we don't service the Mac market)
 
> Both C++ and Java got huge industry support for some reason despite the 
> fact that they offered nothing interesting compared to alternatives that 
> were available (often decades) before them.

And in both cases it was their very familiarity that made them
accessible in a way Obj-C could not.

Obj-C is a different approach to OO and a more pure approach
that's for sure, but as you said their are even better languages
around from a purist OO point of view, but in practice they aint.
There was a project at one point to produce Objective-C++, I
don;t know if its still running, but that too seemed to be an
approach based in futility. Each language has its own strengths
and weaknesses, to try to force all of the features of one into
the other is pointless IMHO. But recognising the strengths and
weaknesses (not all of which are technical) is a valuable piece
of understanding.

Just my 2 cents,

Alan G.


Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
0
Alan
5/17/2004 11:24:38 PM
In article <ec86ca0a.0405171442.7c6a61ba@posting.google.com>,
 pmougin@acm.org (Philippe Mougin) wrote:

> Yes, but the point is that you don't need such conditions in
> Objective-C in order to achieve polymorphic method invocations. This
> makes a real difference with C++. The example also illustrates the
> fact that Objective-C support heterogeneous collections while C++
> don't. This is why I think the example is perfectly appropriate, and,
> actually, brilliant.

I encourage you to review the code I posted in this thread. I understand its 
weaknesses, but I don't think you do.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/17/2004 11:30:00 PM
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <macdev-98D3A9.15452216052004@senator-bedfellow.mit.edu>,
>  Miro Jurisic <macdev@meeroh.org> wrote:
> 
> > The code you wrote above is trivial in C++ if you have a Number class
> > and a String class that are derived from the same base and the base has
> > an intValue abstract member function.
> 
> So what you're saying is that the "trivial" solution is to tie all your
> classes together just to get minimal polymorphism? [..]

That's how your ObjC example works, too. It's just that the framework
(from the NSObject base class and categories/protocols all the way up to
the containers) does all that work for you, so you don't have to code it
for your example.
0
usenet
5/18/2004 1:21:33 AM
In article <170520040941246460%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> In article <gwestonREMOVE-0993A7.07044117052004@netnews.comcast.net>,
> Gregory Weston <gwestonREMOVE@CAPSattbi.com> wrote:
> 
> > No, it's not. Libraries are never "part of" the language.
> 
> Yes, the STL, or "Standard Library" as it is now referred is a
> ratified/adopted part of the C++ specification.

That's a different statement.

> Does obj-c even have a standard?  Maybe that's why you're confused. . .

No it doesn't. I'm not confused, and your suggestion as to the cause of 
my alleged confusion is nonsensical. I'm actually fluent in nearly 3 
dozen programming languages and my C++ experience outstrips my 
Objective-C experience by a decade.

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/18/2004 1:38:58 AM
In article <1gdxy14.nu6121d8swvcN%usenet@mile23.com.r3m0v3>,
 usenet@mile23.com.r3m0v3 (Paul Mitchum) wrote:

> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > In article <macdev-98D3A9.15452216052004@senator-bedfellow.mit.edu>,
> >  Miro Jurisic <macdev@meeroh.org> wrote:
> > 
> > > The code you wrote above is trivial in C++ if you have a Number class
> > > and a String class that are derived from the same base and the base has
> > > an intValue abstract member function.
> > 
> > So what you're saying is that the "trivial" solution is to tie all your
> > classes together just to get minimal polymorphism? [..]
> 
> That's how your ObjC example works, too.

It's not, though. The common ancestor of NSNumber and NSString doesn't 
have an intValue method. They each get it separately, yet you can send 
the identical message to either one.

G

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/18/2004 1:45:49 AM
Gregory Weston <gwestonREMOVE@CAPSattbi.com> wrote:

> In article <1gdxy14.nu6121d8swvcN%usenet@mile23.com.r3m0v3>,
>  usenet@mile23.com.r3m0v3 (Paul Mitchum) wrote:
[..]
> > > So what you're saying is that the "trivial" solution is to tie all
> > > your classes together just to get minimal polymorphism? [..]
> > 
> > That's how your ObjC example works, too.
> 
> It's not, though. The common ancestor of NSNumber and NSString doesn't
> have an intValue method. They each get it separately, yet you can send the
> identical message to either one.

I was remembering that they shared NSObject which had a category that
implements -intValue (much like -description), but you're right.
0
usenet
5/18/2004 4:34:41 AM
In article <gwestonREMOVE-61BCB7.21454917052004@netnews.comcast.net>,
 Gregory Weston <gwestonREMOVE@CAPSattbi.com> wrote:

> It's not, though. The common ancestor of NSNumber and NSString doesn't 
> have an intValue method. They each get it separately, yet you can send 
> the identical message to either one.

In the counter-example I posted, int and string don't have an intValue method at 
all. The scaffolding I built on the spot to write the 4-liner provides that 
functionality. You can argue that I had to build scaffolding and in Obj-C I get 
it for free; you can also argue that in a larger class hierarchy I would have to 
do more work. However, the scaffolding is based on the fundamentally the same 
idea as message dispatching -- adorning each object with messages that it can 
receive. In my particular case, such adornment was done with a quick template, 
in a more complex case you would have to use something more similar to Obj-C 
selectors, but it is not impossible. It would probably be harder to use than 
similar functionality in Obj-C, but then you could say the same of the way many 
C++ features would look in Obj-C.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/18/2004 4:39:18 AM
In article <droleary.usenet-75E0D1.14072217052004@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> When you've cranked 
> it out, you might also want to note that nothing I did requires Cocoa

Sure it did.  You need pre-written objects like NSNumber and NSString
which have the intValue method to make that a 4 liner.  If you're
asking for the same in c++ assuming we already have an NSNumber and
NSString like class, both with GetInt() methods (though not descending
from a common base), then yes it is very simple in c++ using
boost::variant:

#include <iostream>
#include <vector>
#include <boost/variant.hpp>

using namespace std;
using namespace boost;

// Here are 3 unlreated classes

class CStudent {
   public:     CStudent(int id)  {mID=id;}
            int   GetInt()    {return mID;}
   private: int mID;
};

class CBook {
   public:     CBook(int isdn)   {mID=isdn;}
            int   GetInt()    {return mID;}
   private: int mID;
};

class CIPod {
   public:     CIPod(int gigs)   {mID=gigs;}
            int   GetInt()    {return mID;}
   private: int mID;
};

// Here's the vistor

class CShowInt : public static_visitor <> {
   public: template <typename T>
      void operator()(T& inObj) const  
         {cout << inObj.GetInt() << endl;}
};

// Here's the program

int main()
{
   vector<variant <CStudent, CBook, CIPod> > theVec;
   theVec.push_back( CStudent(10) );
   theVec.push_back( CBook(20) );
   theVec.push_back( CIPod(40) );
   
   for (int i=0; i<10; i++)
      apply_visitor(CShowInt(), theVec[rand() % 3]);
}

Note there's no common base class, no inheritence, no tinkering with
the original objects.

This code has several significant advantages over yours.  It is 100%
type-safe, checked at compile time.  There is no way to accidentally
invoke a method (message) at runtime on an object that does not support
GetInt. 

It's also faster than your code as there is absolutely no dynamic
lookup/vtables involved.  I can use apply_visitor(CShowInt(),
theVec[rand() % 3] is a time-sensitive loop.  I'd hate to use yours.

I can also easily modify this to work on objects without a GetInt mehod
by adding a spec to the visitor.  EG if a new class CXServe comes along
and only has a GetGigahertz() method, I'd add a s spec to the visitor
class:
void operator()(CXServe& inObj) const  
         {cout <<GetGigahertz() << endl;}

There is also boost::any which holds any object and offers some
additional features and ease of use but does not provide the
compile-time type checking of boost::variant.
0
Chris
5/18/2004 6:36:36 AM
In article <180520040136367251%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> This code has several significant advantages over yours.  It is 100%
> type-safe, checked at compile time.  There is no way to accidentally
> invoke a method (message) at runtime on an object that does not support
> GetInt. 

HA! I scoff at your puny compile-time. You only think this is a feature because 
your brain has been rotted away by the disease that is C++. Repent, sinner. 

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/18/2004 7:45:23 AM
Miro Jurisic <macdev@meeroh.org> wrote:

> In article <180520040136367251%cbaum981@atlantic.net>, Chris Baum
> <cbaum981@atlantic.net> wrote:
> 
> > This code has several significant advantages over yours.  It is 100%
> > type-safe, checked at compile time.  There is no way to accidentally
> > invoke a method (message) at runtime on an object that does not support
> > GetInt.
> 
> HA! I scoff at your puny compile-time. You only think this is a feature
> because your brain has been rotted away by the disease that is C++.
> Repent, sinner.

:-)
0
usenet
5/18/2004 9:03:26 AM
On Tue, 18 May 2004, Alan Gauld wrote:

> Obj-C is a different approach to OO and a more pure approach
> that's for sure, but as you said their are even better languages
> around from a purist OO point of view, but in practice they aint.
> There was a project at one point to produce Objective-C++, I
> don;t know if its still running, but that too seemed to be an
> approach based in futility. Each language has its own strengths
> and weaknesses, to try to force all of the features of one into
> the other is pointless IMHO. But recognising the strengths and
> weaknesses (not all of which are technical) is a valuable piece
> of understanding.

Objective-C++ exists and works fine. You can get it by creating/renaming a
file to have an extension of .mm, although it's still only in Apple's
branch of gcc for now. It's not really a very complicated concept.
Objective-C is a small set of extensions on top of "C", where "C" is a
language that's sufficiently C-like. It started out on top of whatever C
dialect was around in the 80s, then got stuck on top of C89, then C99.
Putting those extensions on top of C++ is a bit harder due to more
interesting syntax and type rules, but apparently not too hard. It's not
really an unholy marriage, just something that lets you use what you want
when you want, and mix them with a few gotchas. I haven't really used it,
but some people swear by it.
0
Michael
5/18/2004 10:23:04 AM
On Mon, 17 May 2004, Peter Ammon wrote:

> Miro Jurisic wrote:
> [...]
> >  - When I point out to the C++ community that C++ needs to support a particular
> > feature that I consider it lacking compared to, for example, Objective-C, the
> > response that I generally get is that I am right and that such a feature can be
> > obtained using a language feature that I was unaware of,
>
> Doesn't it bother you that there are language features you aren't aware
> of?  I've been using C++ off and on for five years, trying to learn as
> much about it as I can, and I still run into things I don't know.
> http://www.gotw.ca/gotw/ leaves me gasping.

Wow, what a site. I really get the impression from reading through those
articles, than a lot of C++ users equate bizarreness and complexity with
power. Of course, a lot of computer users in general equate bizarreness
and complexity with power.
0
Michael
5/18/2004 10:31:56 AM
Peter Ammon wrote:
> Doesn't it bother you that there are language features you aren't
> aware of?  I've been using C++ off and on for five years, trying to
> learn as much about it as I can, and I still run into things I don't
> know.  http://www.gotw.ca/gotw/ leaves me gasping.

join the club!  i've been using the language since 1995 and, although i
think i'm aware of all the big paradigms, i'd say i'm only really good
at maybe 35 percent of them.

i still pick up new things all the time.  i recently started using
c++-style casts when i read an article about the dangers of c-style
casts.  i went through a phase of teaching myself stl, because i got
tired of the type-unsafe methods i've been using since i was mostly a c
programmer.  there's a lot of good stuff in the stl that keeps me from
having to reinvent wheels.  i also recently started adding private
declarations for a copy constructor and assignment operator for all my
classes that don't have them, when i discovered all the situations where
the compiler might surprise you by generating default methods that don't
do what you want.  currently, i know enough about templates to use them,
but not enough to write my own.  i've got a module or two that i think
would be greatly simplified by being templatized, but i only allow
myself so much time for experimentation and growth, otherwise i'd never
get done with anything.

i'm not at all upset by there being so much undiscovered territory in
the language.  you call it bug, i call it a feature.  i'll probably find
a use for most of it, one of these days.  i've already used a lot more
of it than i ever thought i would back when i was just starting out.
0
ISO
5/18/2004 10:50:52 AM
Michael Ash wrote:
> Objective-C++ exists and works fine. You can get it by
> creating/renaming a file to have an extension of .mm, although it's
> still only in Apple's branch of gcc for now. [...] I haven't really
> used it, but some people swear by it.

one of those people would be me.  i consider c++ to be my implementation
language, but i need obj-c to access the cocoa frameworks.  obj-c++
works surprisingly well.  i haven't discovered any potholes that you can
twist your ankle in, and i've been using it for quite awhile now.
0
ISO
5/18/2004 10:58:18 AM
In article <macdev-C9D0FE.03452118052004@senator-bedfellow.mit.edu>,
Miro Jurisic <macdev@meeroh.org> wrote:

> your brain has been rotted away by the disease that is C++. Repent, sinner. 

Ah, I always assumed it was the cheap beer. :)
0
Chris
5/18/2004 1:51:05 PM
dans l'article 180520040851051329%cbaum981@atlantic.net, Chris Baum �
cbaum981@atlantic.net a �crit le 18/05/04 15:51�:

> In article <macdev-C9D0FE.03452118052004@senator-bedfellow.mit.edu>,
> Miro Jurisic <macdev@meeroh.org> wrote:
> 
>> your brain has been rotted away by the disease that is C++. Repent, sinner.
> 
> Ah, I always assumed it was the cheap beer. :)

Maybe it's also because you need to make a living out of your programming. I
guess the 'unrotten' on this list have found a way to live from something
not related to the development market.

Welcome.

Eric

0
Eric
5/18/2004 2:09:48 PM
In article <PM0003DAB0B72ACCB8@minion.nashville.comcast.net>,
 J�hnny F�v�r�t� (it means "halo, then resonate") <this.is@fake.com> wrote:

> i also recently started adding private declarations for a copy constructor 
> and assignment operator for all my classes that don't have them

By the way, if you use boost, a simpler way to do that is to do

class MyClass:
   private boost::noncopyable

boost::noncopyable provides the private declarations which subsequently cause 
compiler errors if you try to copy/assign MyClass.

hth

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/18/2004 5:58:09 PM
On Tue, 18 May 2004, Eric VERGNAUD wrote:

> dans l'article 180520040851051329%cbaum981@atlantic.net, Chris Baum =E0
> cbaum981@atlantic.net a =E9crit le 18/05/04 15:51=A0:
>
> > In article <macdev-C9D0FE.03452118052004@senator-bedfellow.mit.edu>,
> > Miro Jurisic <macdev@meeroh.org> wrote:
> >
> >> your brain has been rotted away by the disease that is C++. Repent, si=
nner.
> >
> > Ah, I always assumed it was the cheap beer. :)
>
> Maybe it's also because you need to make a living out of your programming=
=2E I
> guess the 'unrotten' on this list have found a way to live from something
> not related to the development market.

What a ridiculous thing to say; it's just like the tired old "Nobody ever
got fired for buying IBM (or Microsoft or...)" argument. You don't have to
be using the most popular language on the most popular system to make a
living programming.
0
Michael
5/18/2004 6:38:02 PM
Miro Jurisic wrote:

> In article <ec86ca0a.0405171442.7c6a61ba@posting.google.com>,
>  pmougin@acm.org (Philippe Mougin) wrote:
> 
> 
>>Yes, but the point is that you don't need such conditions in
>>Objective-C in order to achieve polymorphic method invocations. This
>>makes a real difference with C++. The example also illustrates the
>>fact that Objective-C support heterogeneous collections while C++
>>don't. This is why I think the example is perfectly appropriate, and,
>>actually, brilliant.
> 
> 
> I encourage you to review the code I posted in this thread. I understand its 
> weaknesses, but I don't think you do.
> 
> meeroh

I'd say this post just exposed its largest weakness: you cannot write, 
maintain, or even understand that code without tremendous C++ 
proficiency (which you and several other posters obviously have).

Acquiring that proficiency may just be another aspect of your 
professional development, as you said in another post, but my efforts to 
learn C++ convinced me that it only enhances my C++ development.  That 
is, the time spent learning about C++'s quirks and features is entirely 
inwardly focused, applicable only to C++.  I made myself a better C++ 
programmer without becoming a better programmer, and paid for it with 
frustration and hair pulling.

Was it worth it?  YMMV.

0
Peter
5/18/2004 6:42:01 PM
In article <macdev-FA9E04.16010017052004@senator-bedfellow.mit.edu>,
 Miro Jurisic <macdev@meeroh.org> wrote:

> Here you go. First we'll whip up some counterparts to your framework:

Definite props for the code.  Anyone can talk the talk of 
Turing-complete, but to show it benefits anyone who is still bothering 
to read this thread.  :-)

>    vector<IntConvertibleBase*>   items;
>    items.push_back(MakeIntConvertible(1));
>    items.push_back(MakeIntConvertible(string("13")));
> 
>    cout << RandomItem(items.begin(), items.end())->ConvertToInt();
> 
> You should note how I was able to accomplish the amazing feat without any 
> changes to existing classes (int and string, which I can't change anyway). 
> You 
> should also note how I was able to provide a default implementation for 
> ConvertToInt while allowing myself to provide a more specific one (with a 
> template specialization) in those cases when lexical_cast doesn't do what I 
> want.
> 
> Whop te doo.

Actually, that is something to hoot and holler about, because you *did* 
do an awful lot of work to support my simple toy problem.  Just imagine 
(or, like many of us who have previous used C++ extensively, simply 
remember) how complex things will get for real-world problem.  How much 
more work is in store for you if you want to call a different method?  
Do you now need StringConvertableBase? What about printing both methods?  
StringAndIntConvertableBase?  What about conditionally calling another 
method, like:

if ([someObject intValue] > 999)
   NSLog(@"%@ is a big one!", [someObject name]);

NameReturnableAndIntConvertableBase?  Where does the madness end?  Hint: 
it doesn't.  The better question is when, as a programmer, do you 
realize that you're working in a way the language doesn't support and 
that the best solution is not to hack at the language until it bends 
nearly to breaking, but to use another language?  If you think suffering 
with C++ is good for your soul, more power to you.  I suffered with it 
long enough, though, and having used alternatives to better solve 
real-world problems, I can only count my years with C++ as wasted time.
0
Doc
5/18/2004 9:12:07 PM
In article <180520040136367251%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> In article <droleary.usenet-75E0D1.14072217052004@corp.supernews.com>,
> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > When you've cranked 
> > it out, you might also want to note that nothing I did requires Cocoa
> 
> Sure it did.  You need pre-written objects like NSNumber and NSString
> which have the intValue method to make that a 4 liner.

That has nothing to do with Cocoa.  I simply stated that the initial 
condition was to assume a class library exists for the objects and 
methods in question.  I could just as easily have written it sans-Cocoa 
using DocString, DocNumber, and DocArray.  In that way, other than NS -> 
Doc, no other changes would have to be made to the four lines of code.

> If you're
> asking for the same in c++ assuming we already have an NSNumber and
> NSString like class, both with GetInt() methods (though not descending
> from a common base), then yes it is very simple in c++ using
> boost::variant:

See, now, that supports my point!  You're requiring specific class 
libraries whereas my example is about *language* features.  I can only 
assume this distinction is cloudy in your head because of C++ damage.  
Again, no Cocoa required for mine to work; I merely assume *a* class 
library, not a *specific* class library.  Boost clearly has been able to 
hack around a lot of C++ problems, but make no mistake that it is still 
hackery to address flaws in the language itself.

>    vector<variant <CStudent, CBook, CIPod> > theVec;
>    theVec.push_back( CStudent(10) );
>    theVec.push_back( CBook(20) );
>    theVec.push_back( CIPod(40) );
>    
>    for (int i=0; i<10; i++)
>       apply_visitor(CShowInt(), theVec[rand() % 3]);

Turing-complete wins again!  Thanks for actually showing code.  :-)

> Note there's no common base class, no inheritence, no tinkering with
> the original objects.

True enough, but you are still restricted to pre-defined objects that 
have had templates generated for them.  Why did you not do a parity 
example with strings and numbers like I did?  Clearly trying to reuse 
libraries remains a hassle for you in C++.

> This code has several significant advantages over yours.  It is 100%
> type-safe, checked at compile time.  There is no way to accidentally
> invoke a method (message) at runtime on an object that does not support
> GetInt. 

Yawn; introspection allows me -respondsToSelector: if it really matters.  
If I knew ahead of time, as you clearly must, I could even define a 
protocol to get compile-time checking.  True, your version is enforced 
100% static, but a case can just as easily be made for that being a flaw 
as a feature.  I can load in a bundle that has an Employee object and 
simply drop one into my collection.  The C++ way is not nearly as 
productive.

> It's also faster than your code as there is absolutely no dynamic
> lookup/vtables involved.  I can use apply_visitor(CShowInt(),
> theVec[rand() % 3] is a time-sensitive loop.  I'd hate to use yours.

Ah, the myth of method lookup having an extreme cost.  You see, in both 
cases there is *a lot* of code working in the background you have no 
control over.  To assume what you have is faster than what I have is 
naive.

You clearly have access to both environments.  How's about benchmarking 
my example (and a parity implementation on your part) and showing the 
differences?  To be fair, you should factor in development time and 
executable size, but I'd be willing to start by looking at results 
benchmarking the toy example.

> I can also easily modify this to work on objects without a GetInt mehod
> by adding a spec to the visitor.  EG if a new class CXServe comes along
> and only has a GetGigahertz() method, I'd add a s spec to the visitor
> class:
> void operator()(CXServe& inObj) const  
>          {cout <<GetGigahertz() << endl;}

So you'll have to add code and recompile the library whenever the model 
changes?  And you think that's a feature?  C++ has sure done a number on 
you, buddy!

> There is also boost::any which holds any object and offers some
> additional features and ease of use but does not provide the
> compile-time type checking of boost::variant.

Whatever.  I'm just looking for a parity example.  I think Miro's code 
was closer, but either way it's clear to me that OO development with C++ 
is still a nightmare.  And this is just a toy problem, too!  The 
suffering you (and many businesses) endure implementing complex systems 
in C++ must be horrendous.
0
Doc
5/18/2004 9:54:33 PM
In article <droleary.usenet-5F5738.16543318052004@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> The suffering you (and many businesses) endure implementing complex systems 
> in C++ must be horrendous.

It still beats listening to your blathering.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/18/2004 10:20:29 PM
In article <droleary.usenet-5F5738.16543318052004@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> I simply stated that the initial 
> condition was to assume a class library exists for the objects and 
> methods in question.  I could just as easily have written it sans-Cocoa 
> using DocString, DocNumber, and DocArray.  In that way, other than NS -> 
> Doc, no other changes would have to be made to the four lines of code.

OK good, bc that's exactly the case with the example code I wrote for
you.  A change of underlying objects stored in theVec from say CStudent
& CBook to DStudent & DBook would only require a grep change from C to
D in the main.cp source code file - same as your example.  The boost
library doesn't change, the source and compiled code for CStudent,
CBook, DStudent, DBook classes do not change *at all*.  Get it?

> You're requiring specific class 
> libraries whereas my example is about *language* features.  I can only 
> assume this distinction is cloudy in your head because of C++ damage.  
> Again, no Cocoa required for mine to work; I merely assume *a* class 
> library, not a *specific* class library.

Nope.  I am not requiring any specific class library.  I'm making the
same assumuption you are in your example.  That there are n disparate
classes out there somewhere/anywhere and they have the method(s) you've
delineated.  It could be *any* class or set of classes that meet that
requirement - same as your example.  See?

> Boost clearly has been able to 
> hack around a lot of C++ problems, but make no mistake that it is still 
> hackery to address flaws in the language itself.

Yes, now I do see - you're the type that buys Bang & Olufson bc it
looks good - I buy Mark Levinson bc it performs better.  

As a professional developer, I don't care if boost used rat turds and
peanut butter to make it work.  If I can simply #include a header and
write the same 4-liners + get type-safety and faster code to boot, it's
a big win.

> True enough, but you are still restricted to pre-defined objects that 
> have had templates generated for them.

Adding another object only requires a recompile to the main.cp file. 
boost never gets recompiled, the CStudent, CBook, etc. classes never
get recompiled.  In your example, you'd of course also have to
recompile the translation unit with the 4 liner in it.  Same for your
code and mine.

> Why did you not do a parity 
> example with strings and numbers like I did?  Clearly trying to reuse 
> libraries remains a hassle for you in C++.

Are you serious?  Just change the names of those classes to CInt and
CString.  My example was intended to look 'real world' with those class
names.  I'm sorry it confused the comparison for you and anyone else. 
The program is identical if you assumed an int class and a string class
*of any variety, source, derivation, library* as long as it has GetInt
member.  Sorry to keep repeating, but . . . . same as your example.

>  I could even define a 
> protocol to get compile-time checking

You mean it's not a 4 liner anymore just to get type-safety?  :)

I'd hate to think of Doc writing the mars lander software.  Doc: "Look
I put all the action classes in an NSSet and now I just send the
ExecuteCommand mssg to the entire NSSet - it's a one-liner - I'm a
frickin'  genius!"   5-4-3-2-1-lift-off.  "Oops, what do mean I forgot
to add ExecuteCommand to the Deploy Parachute object?"

I prefer that Codewarrior tells me about such ommissions before I can
even run the program.

> So you'll have to add code and recompile the library whenever the model 
> changes?

No.  See above or go back and look at the code.  boost never changes,
the original objects never change, just the code in the translation
unit with the 4-liner.

> Whatever.  I'm just looking for a parity example.

Whatever.  I gave you an example that actually does more and
additionally provides a small example of how I'd easily add support for
a new object that didn't have a GetInt method.  Maybe you can look at
my responses here and go back to the code and appreciate how simple it
was.  I'm not saying c++ is better here, but you tried to come up with
this an example where obj-c blows away what a c++ coder is stuck with -
and you've been shown the error of your ways. 

// Assuming you throw *ANY* class at me
// of any shape, spec, location, etc.
// As long as they both have a GetInt() method.
// Here I assume you've handed me some classes
// CInt & CString and both have GetInt methods. 
// Could be *any* other classes though - got it? :)

// All code below goes in main.cp so any edits do NOT 
// require any recompiles of CInt, CString, boost, stl.

#include <iostream>
#include <vector>
#include <boost/variant.hpp>

using namespace std;
using namespace boost;

class CLogInt : public static_visitor <>  {
   public: template <typename T>
    void operator()(T& inObj) const
   {cout << "One of my values is" << inObj.GetInt() << endl;}
};

int main()
{
   vector<variant <CInt, CString> > theVec;
   theVec.push_back(CInt(42) );
   theVec.push_back(CString("1337") );
   apply_visitor(CLogInt(), theVec[rand() % theVec.size()]);
}
0
Chris
5/19/2004 1:54:26 AM
In article <180520042054262673%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> Maybe you can look at my responses here and go back to the code and 
> appreciate how simple it was.  I'm not saying c++ is better here, but you 
> tried to come up with this an example where obj-c blows away what a c++ coder 
> is stuck with - and you've been shown the error of your ways. 

Okay, first of all, he hasn't been shown the error of his was because his ways 
have no error even when he's wrong. Second, he can't go look at the code, 
because the code is in C++ and C++ equals brain damage. 

Brain damage bad. Objective-C good.

Get with the program already.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/19/2004 2:10:34 AM
In article <macdev-86D67F.22103418052004@senator-bedfellow.mit.edu>,
Miro Jurisic <macdev@meeroh.org> wrote:

> Brain damage bad. Objective-C good.

Brain damaged from beating my head against the wall.  

You're right of course, but maybe somebody else will read this thread
in deja news.  Thx for posting that source code.
0
Chris
5/19/2004 2:25:56 AM
In article <droleary.usenet-740296.16120518052004@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> Actually, that is something to hoot and holler about, because you *did* 
> do an awful lot of work to support my simple toy problem.  Just imagine 
> (or, like many of us who have previous used C++ extensively, simply 
> remember) how complex things will get for real-world problem.  How much 
> more work is in store for you if you want to call a different method?  
> Do you now need StringConvertableBase? What about printing both methods?  
> StringAndIntConvertableBase?  What about conditionally calling another 
> method, like:
> 
> if ([someObject intValue] > 999)
>    NSLog(@"%@ is a big one!", [someObject name]);
> 

Or even better:

if ([someObject intValue] > 999 && [someObject respondsToSelector: 
@selector(name)])
   NSLog(@"%@ is a big one!", [someObject name]);

Objective-C provides for introspection "for free".  While there are some 
C++ ways to provide introspection, I'm unaware of any that don't require 
either a pre-processor of some sort or manually adding special 
macros/etc...  Even if you have introspection, calling a virtual method 
with the same signature on objects that don't share a common base class 
is difficult at best.
0
Glenn
5/19/2004 1:38:58 PM
In article <droleary.usenet-740296.16120518052004@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> What about conditionally calling another 
> method, like:

> if ([someObject intValue] > 999)
>    NSLog(@"%@ is a big one!", [someObject name]);

Simple.  Take the program I provided for you and change the line:

   const {cout << inObj.GetInt() << endl;}

to: 

   const {if (inObj.GetInt() > 999 cout << inObj.GetName() << endl;}

I'm beginning to think many (most?) Obj-C folks are not familiar with
boost.  It doesn't have as much 'gee whiz' quotient as a when you first 
use a pure OO language ike Obj-C, but it gets the job done in portable
c++ with similar effort, and with the notable advantages I've already
listed.
0
Chris
5/19/2004 8:02:47 PM
In article <gandreas-9E0D07.08385719052004@news.mpls.visi.com>, Glenn
Andreas <gandreas@no.reply> wrote:

> While there are some 
> C++ ways to provide introspection, I'm unaware of any that don't require 
> either a pre-processor of some sort or manually adding special 
> macros/etc...

Well here you go:

#include <iostream>
#include <vector>
#include <string>
#include <boost/any.hpp>

using namespace std;
using namespace boost;

int main()
{
   // 3 unrelated objects:
   
   int            i(10);
   string         s("www.boost.org");
   vector<double> v(5);
   
   // Put all 3 in a vector:
   
   vector<any> theVec;
   theVec.push_back( i );
   theVec.push_back( s );
   theVec.push_back( v );
   
   // Test the vector's elements for int's:

   for (int x=0; x<theVec.size(); x++) {
      if (any_cast <int>(&theVec[x]))
         cout << "Is an int" << endl;
      else cout << "Not an int" << endl;
   }
}

If you don't feel like running the program, here is the output:

Is an int
Not an int
Not an int

Doesn't get much easier. . .

> Even if you have introspection, calling a virtual method 
> with the same signature on objects that don't share a common base class 
> is difficult at best.

Nope.  See my other sample program using boost::variant.
0
Chris
5/19/2004 8:09:56 PM
In article <180520042054262673%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> The boost
> library doesn't change, the source and compiled code for CStudent,
> CBook, DStudent, DBook classes do not change *at all*.  Get it?

But you're still using a feature supplied by the Boost library and not 
the C++ language.  Get it?

> > You're requiring specific class 
> > libraries whereas my example is about *language* features.  I can only 
> > assume this distinction is cloudy in your head because of C++ damage.  
> > Again, no Cocoa required for mine to work; I merely assume *a* class 
> > library, not a *specific* class library.
> 
> Nope.  I am not requiring any specific class library.

OK, let's see the same four lines in a non-Boost example, then.

> As a professional developer, I don't care if boost used rat turds and
> peanut butter to make it work.  If I can simply #include a header and
> write the same 4-liners + get type-safety and faster code to boot, it's
> a big win.

But moot for the purposes of this discussion.  This whole troll-started 
thread was based on the premise that C++ is the best-and-only OO 
language necessary.  To anyone who can objectively evaluate language 
features, it should be clear by now that C++ itself doesn't provide an 
OO developer with much at all.

> Adding another object only requires a recompile to the main.cp file. 
> boost never gets recompiled, the CStudent, CBook, etc. classes never
> get recompiled.  In your example, you'd of course also have to
> recompile the translation unit with the 4 liner in it.  Same for your
> code and mine.

What?  You clearly don't know much about ObjC.  I don't have to compile 
anything because I don't have to generate any templates.  I could load 
classes from plug-in bundles written by a third party and have it all 
just work.  A good example of this is Mail bundles that can do some 
really amazing things with the application completely sans 
recompilation.  For a good starting point see:

http://www.tikouka.net/mailapp/

> > Why did you not do a parity 
> > example with strings and numbers like I did?  Clearly trying to reuse 
> > libraries remains a hassle for you in C++.
> 
> Are you serious?  Just change the names of those classes to CInt and
> CString.  My example was intended to look 'real world' with those class
> names.  I'm sorry it confused the comparison for you and anyone else.

It didn't confuse me at all.  Instead, it left me suspicious that Boost 
could not be used with STL-defined classes or classes supplied in other 
libraries.  If you have to rewrite everything so that you can use Boost, 
it's not so handy, is it?  Again, let me repeat that my example 
highlights features only of ObjC itself, not of Cocoa.
 
> The program is identical if you assumed an int class and a string class
> *of any variety, source, derivation, library* as long as it has GetInt
> member.  Sorry to keep repeating, but . . . . same as your example.

So you say.  Why wouldn't you show it?  Please show it now.

> >  I could even define a 
> > protocol to get compile-time checking
> 
> You mean it's not a 4 liner anymore just to get type-safety?  :)

No, it's still four lines, but NSSet is merely replaced by a container 
class that has a static type/protocol defined for its methods.  Why is 
it so difficult to understand that just because a language allows 
dynamic object typing in the runtime doesn't mean it can't do static 
object typing at compile time?  The reason it isn't done more frequently 
is that it's a pointless exercise 99% of the time.

> I'd hate to think of Doc writing the mars lander software.  Doc: "Look
> I put all the action classes in an NSSet and now I just send the
> ExecuteCommand mssg to the entire NSSet - it's a one-liner - I'm a
> frickin'  genius!"   5-4-3-2-1-lift-off.  "Oops, what do mean I forgot
> to add ExecuteCommand to the Deploy Parachute object?"

This says more about how you program than it does about how I program.  
Action classes?  Deploy Parachute object?  Damn, C++ must have screwed 
you over beyond repair.  Do me a favor and say where you work, because 
I'd like to know whose software to avoid in the future.

> I prefer that Codewarrior tells me about such ommissions before I can
> even run the program.

Need I repeat that you can get compile time checking in ObjC?  If you 
haven't grasped the idea by now, I wager saying it again won't help your 
muddled mind.

> > So you'll have to add code and recompile the library whenever the model 
> > changes?
> 
> No.  See above or go back and look at the code.  boost never changes,
> the original objects never change, just the code in the translation
> unit with the 4-liner.

I read that as a big yes.  Any such "translation unit" is part of a 
library or, worse, cannot be put in a library at all and must be 
included with the four lines of code, making it decidedly *not* a 
4-liner anymore.

You have to add code to add a new model.  Just state it plainly; there 
should be no shame in the truth.  Instead, you try to cover up and dance 
around what needs to be done.  That actually does other C++ developers a 
*disservice* because they are left confused as to what exactly needs to 
be done to use Boost.

> I'm not saying c++ is better here, but you tried to come up with
> this an example where obj-c blows away what a c++ coder is stuck with -
> and you've been shown the error of your ways. 

No, you continue to support my point.  I showcased what were essentially 
two feature of the ObjC language, and all you've been able to show is 
how you have to hack away with a third party to get something that is, 
at best, *similar* in behavior.

> // Assuming you throw *ANY* class at me
> // of any shape, spec, location, etc.
> // As long as they both have a GetInt() method.
> // Here I assume you've handed me some classes
> // CInt & CString and both have GetInt methods. 
> // Could be *any* other classes though - got it? :)
> 
> // All code below goes in main.cp so any edits do NOT 
> // require any recompiles of CInt, CString, boost, stl.
> 
> #include <iostream>
> #include <vector>
> #include <boost/variant.hpp>
> 
> using namespace std;
> using namespace boost;
> 
> class CLogInt : public static_visitor <>  {
>    public: template <typename T>
>     void operator()(T& inObj) const
>    {cout << "One of my values is" << inObj.GetInt() << endl;}
> };
> 
> int main()
> {
>    vector<variant <CInt, CString> > theVec;
>    theVec.push_back(CInt(42) );
>    theVec.push_back(CString("1337") );
>    apply_visitor(CLogInt(), theVec[rand() % theVec.size()]);
> }

Not parity.  You're forced to define the CLogInt "action class".  Not 
only does this not make it a 4-liner, it shifts the logging behavior 
into that code.  That is, in my code I got the int value and just chose 
to print it, but could have done anything with it.  In your case you 
have defined code for the special case that involves printing it, and 
would seemingly have to define classes for each and every operation you 
might want to do on the int value.

I noticed you dropped the topic of how much faster you think your code 
would be.  Can I assume you benchmarked and found that to not be the 
case?  Perhaps you are waiting until such a time that you can actually 
write a parity example (you're sure taking a lot of time to crank out 
what is just 4 good lines of code)?  I still give you props for trying 
to make C++ look good, but I really do think it's time to admit that it 
really isn't a language worthy of that effort.
0
Doc
5/19/2004 8:29:18 PM
In article <gandreas-9E0D07.08385719052004@news.mpls.visi.com>,
 Glenn Andreas <gandreas@no.reply> wrote:

> Or even better:
> 
> if ([someObject intValue] > 999 && [someObject respondsToSelector: 
> @selector(name)])
>    NSLog(@"%@ is a big one!", [someObject name]);

If they're having a hard time with basic support of objects and 
polymorphism, I *really* don't want to hammer them too hard by throwing 
in real introspection.  If I did, I'd feel compelled to beat them up 
with categories, too, and simply *add* that -name method to classes that 
don't implement it.  I'm just too nice of a guy to do that to a C++ 
advocate.  :-)
0
Doc
5/19/2004 8:39:40 PM
Miro Jurisic <macdev@meeroh.org> wrote in message news:<macdev-6FEE9B.19300017052004@senator-bedfellow.mit.edu>...
> In article <ec86ca0a.0405171442.7c6a61ba@posting.google.com>,
>  pmougin@acm.org (Philippe Mougin) wrote:
> 
> > Yes, but the point is that you don't need such conditions in
> > Objective-C in order to achieve polymorphic method invocations. This
> > makes a real difference with C++. The example also illustrates the
> > fact that Objective-C support heterogeneous collections while C++
> > don't. This is why I think the example is perfectly appropriate, and,
> > actually, brilliant.
> 
> I encourage you to review the code I posted in this thread. 

Thanks for posting this code. Quite interesting to look at. The trick
with a template inheriting from a non-template base class seems
powerful for template programing.

However, how am I supposed to relate your code to my previous
statements? I wrote about heterogeneous collections and polymorphic
method invocations on objects without a common base class. But, at
first glance, I see neither in your code. What am I missing ?

> I understand its weaknesses.

Please, go ahead. What are its weaknesses? 

> but I don't think you do.

Again, what makes you think that?

Best,

Philippe Mougin
--
http://www.fscript.org
F-Script: the open-source scripting language for Cocoa
0
pmougin
5/19/2004 8:49:40 PM
Rolf Nilsson wrote:
> 
> I understand Objective-C is a heritage from the NextStep time (correct me if
> I'm wrong)
> 
> But why should we use it now in 2004?

I think the best essay I've seen on the relative merits of Objective-C
and C++ was this post by Ken Dyke:

http://groups.google.com/groups?selm=DCxz5.246037%24i5.3339013%40news1.frmt1.sfba.home.com&output=gplain

-jcr
0
John
5/19/2004 10:01:23 PM
Michael Ash wrote:
> 
> On Tue, 18 May 2004, Eric VERGNAUD wrote:
> 
> > dans l'article 180520040851051329%cbaum981@atlantic.net, Chris Baum �
> > cbaum981@atlantic.net a �crit le 18/05/04 15:51�:
> >
> > > In article <macdev-C9D0FE.03452118052004@senator-bedfellow.mit.edu>,
> > > Miro Jurisic <macdev@meeroh.org> wrote:
> > >
> > >> your brain has been rotted away by the disease that is C++. Repent, sinner.
> > >
> > > Ah, I always assumed it was the cheap beer. :)
> >
> > Maybe it's also because you need to make a living out of your programming. I
> > guess the 'unrotten' on this list have found a way to live from something
> > not related to the development market.
> 
> What a ridiculous thing to say; it's just like the tired old "Nobody ever
> got fired for buying IBM (or Microsoft or...)" argument. You don't have to
> be using the most popular language on the most popular system to make a
> living programming.

As it happens, I found that the going rates for the guys who wrote code
in the most popular languages on the most popular platforms tended to
run about a third to half of what I charged for working on my favorite
niche product.

-jcr
0
John
5/19/2004 10:03:13 PM
John C. Randolph <jcr@nospam.idiom.com> wrote:
> I think the best essay I've seen on the relative merits of Objective-C
> and C++ was this post by Ken Dyke:
> 
> http://groups.google.com/groups?selm=DCxz5.246037%24i5.3339013%40news1.frmt1.sfba.home.com&output=gplain

Thanks jcr, I hadn't seen that particular post. Quite eloquent.

And, for much of the purposes of the comparison, Java sits pretty
squarely on the C++ side of the fence, which is why I prefer Obj-C. Alas,
current projects are mostly in WO, thus Java. Still, I've learned to 
dislike Java less, partly because WO is a very good implementation.

-- 
_Deirdre                                             http://deirdre.net
"Ideally pacing should look like the stock market for the year 1999, up 
and up and up, but with lots of little dips downwards...."
                                     -- Wen Spencer on plotting a novel
0
Deirdre
5/19/2004 10:31:24 PM
In article <droleary.usenet-6635CD.15291819052004@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> OK, let's see the same four lines in a non-Boost example, then.

That's like writing Obj-C osx apps without cocoa - neither of us could
or would bother.  boost is a de facto standard and more so than Cocoa,
highly portable.  In fact a nice chunk of boost is up for adoption into
the standard.

> This whole troll-started 
> thread was based on the premise that C++ is the best-and-only OO 
> language necessary.

Did he say that?  Anyway I agree with you but that's a straw man to
what I'm trying to demonstrate to you.

> A good example of this is Mail bundles that can do some 
> really amazing things with the application completely sans 
> recompilation

Every code resource or plug in I've written (2 or 3) had to publish
it's api as static c calls so if what you're saying is true, I grant
you that Obj-C has nice advantages for plug-ins.  We have to get by
with void* for the amazing things you're talking about.   But I don't
write plug-ins and I think most dev's don't.  

In my example, the template was in the same translation unit as the
code to push_back into the vector so of course if you decide to
push_back new objects into that vector, a recompile is necessary
irrespective of any change I may or may not have to make in the
template.

> If you have to rewrite everything so that you can use Boost, 
> it's not so handy, is it? 

That sounds suspiciously like "If I have rewrite everything to use
Cocoa/Obj-C, it's not as handy is it?".  Remember, a large % of the
universe is already using c++/boost.  The onus is on the Obj-C
community  to demostrate amazing stuff that can't be accomplished
easily in c++.  You whipped out that 'stake in the heart' code snippet
and it turned out to be a limp turd.  

> Can I assume you benchmarked and found that to not be the 
> case?

No.  I've read the difference bw c++ static vs. virtual calls is
generally 5-10% depending of course on how much code is in the called
method.  The Obj-C runtime does more complicated dispatch so I would
guess it is higher.  It's certainly not less.

You have XCode no?  www.boost.org for the headers I #included.  I have
posted several complete programs, not snippets - go ahead and test it.

> In your case you 
> have defined code for the special case that involves printing it

And here is your 'special case' code:

NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);

Mine was a few extra lines of code yes, but that's far from showing c++
can't easily do what your example did.

No doubt Obj-C has many gee-whiz features but much of it, with limits,
can now be easily mimmicked in c++ with template programming as
demonstrated by boost.  See my sample code or better yet check out
www.boost.org.
0
Chris
5/19/2004 11:22:23 PM
In article <40ABD9A1.9C216C00@nospam.idiom.com>, John C. Randolph
<jcr@nospam.idiom.com> wrote:

> As it happens, I found that the going rates for the guys who wrote code
> in the most popular languages on the most popular platforms tended to
> run about a third to half of what I charged for working on my favorite
> niche product.


As long as the niche remains.  

Some would argue it's better to keep your skills sharpened and
state-of-the-art in the areas where work exists and appears likely to
exist in the future.  Obj-C is almost exclusivley used only when
accompanied by a proprietary framework that is owned by a private corp.
with a 1.8% market share and shrinking.
0
Chris
5/19/2004 11:33:00 PM
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <180520042054262673%cbaum981@atlantic.net>,
>  Chris Baum <cbaum981@atlantic.net> wrote:
> 
> > The boost library doesn't change, the source and compiled code for
> > CStudent, CBook, DStudent, DBook classes do not change *at all*.  Get
> > it?
> 
> But you're still using a feature supplied by the Boost library and not the
> C++ language.  Get it?

Much like your 4-liner is using a number of features supplied by Cocoa,
and not the Objective-C language. :-)
0
usenet
5/20/2004 12:46:44 AM
On Mon, 17 May 2004, nospam@nowaynomail.nu wrote:
>  
>  So my question still is:
>  Why did NextStep choose Objective-C?
>  Or was it the people with NextStep that created Objective-C?
>  

One thing I think one needs to remember / consider is that the question
is being asked 10 or 15  years after the choice was made. 

Today it may be that C++ is capable of doing many of the things that
Obj-C does, but at the time the decision was made C++ was not.

I don't know precisely when the choice was made, but it had to have been
before 1990.  I first became aware of Obj-C from Brad Cox's book in
about 1987.  At that time C++ was in wide spread use within AT&T Bell
Labs, where I was working, and I'd done some development in it -- it was
great for some kinds of work, but I realized I really needed to
understand OO programming better.   So I learned Smalltalk, figuring I'd
move from C to C++ via Smalltalk after learning OO programming.
Eventually I realized that was a bad move, as once one learned OO
programming, using C++ was particularly frustrating (unless one wanted
to redefine OO programming to mean what you could do in C++).

Anyway, Obj-C basically provided Smalltalk extensions to C.

Another thing Obj-C promised was the idea of the "Software IC" -- it
actually made it prossible to use object libraries without the source,
something very difficult to do in C++ even 3 years ago (I don't know if
things have improved there,  I walked away from C++).

The time when the decisions were made was long before STL or even
significant Template functionality was available in C++. 

I am aware of projects within AT&T or it's acquisitions / partners where
C++ was tried and Smalltalk or Obj-C were chosen because it was more
effective.

C++ has greatly improved since the decision was made -- you have to look
at the state of the language back then to clearly see the factors that
led to the choice.

joe
0
Joe
5/20/2004 3:59:41 PM
In article <1ge1nuk.pjbu7tvogb9lN%usenet@mile23.commie.r3m0v3>,
 usenet@mile23.commie.r3m0v3 (Paul Mitchum) wrote:

> Much like your 4-liner is using a number of features supplied by Cocoa,
> and not the Objective-C language. :-)

As I have noted numerous times, nothing I did requires Cocoa.  Since you 
have been continually unable to grasp that, I have not choice but to 
consider your damage at the hands of C++ to be beyond repair.
0
Doc
5/20/2004 8:22:41 PM
In article <190520041822235094%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> In article <droleary.usenet-6635CD.15291819052004@corp.supernews.com>,
> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > OK, let's see the same four lines in a non-Boost example, then.
> 
> That's like writing Obj-C osx apps without cocoa - neither of us could
> or would bother.  boost is a de facto standard and more so than Cocoa,
> highly portable.  In fact a nice chunk of boost is up for adoption into
> the standard.

Moot.  Again, the thread was about the languages.  I can easily write a 
program with generic objects and polymorphism because they are features 
of ObjC itself and have nothing to do with a particular library.  I keep 
having to repeat it, but it should not be a particularly difficult 
concept to grasp.  If C++ has not damaged your ability to understand 
basic OO concepts, what has?

> > This whole troll-started 
> > thread was based on the premise that C++ is the best-and-only OO 
> > language necessary.
> 
> Did he say that?  Anyway I agree with you but that's a straw man to
> what I'm trying to demonstrate to you.

Yes, Rolf Nilsson said that.  Can you not even be bothered to simply 
look?  For ease of reference, I quote:

> With C++ you can do anything that Objective-C does and more and it exists on
> every existing platform:
> Mac, Windows, UNIX, etc
> 
> We don't need:
> Objective-C
> C#
> Visual Basic
> Java
> Db

I don't care how much you love Boost or how wonderful its hackery is to 
get around problems inherent in the C++ language itself.  The simple 
fact is that C++ is a poorly designed OO language and it doesn't reflect 
well on developers when they rush to its defense.

> Every code resource or plug in I've written (2 or 3) had to publish
> it's api as static c calls so if what you're saying is true, I grant
> you that Obj-C has nice advantages for plug-ins.  We have to get by
> with void* for the amazing things you're talking about.   But I don't
> write plug-ins and I think most dev's don't.  

Most don't because it is a *bitch* to do well in a lot of languages.  
One of the great ideas behind OO is that you could just grab objects 
from off the shelf and slap them together to get things done.  Instead, 
the industry took a terrible direction by pushing C++ as it's first 
widely hyped OO language.

On Mac OS X, you *do* see massive use of frameworks and bundles.  Like 
screen savers, which are bundles that link with the ScreenSaver 
framework as well as Cocoa.  It all just works so well that its tough 
for us ObjC wankers to understand why anyone still bothers to raise a 
flag for C++.

> In my example, the template was in the same translation unit as the
> code to push_back into the vector so of course if you decide to
> push_back new objects into that vector, a recompile is necessary
> irrespective of any change I may or may not have to make in the
> template.

I know; that's part of why templates suck.  A lot of people have 
convinced themselves they are a feature, but they really don't do much 
for the developer.  To actually be productive, C++ would have to support 
real objects instead of just user-defined types.  That ship has sailed, 
though, because ObjC gave objects to C long ago, and the industry hype 
has moved past C++ to Java, and it looks like Java is loosing some favor 
to the next hype in line (and I hope you know to what I refer).  Forget 
all the pointless effort of following the hype machine and think for 
yourself.

> > If you have to rewrite everything so that you can use Boost, 
> > it's not so handy, is it? 
> 
> That sounds suspiciously like "If I have rewrite everything to use
> Cocoa/Obj-C, it's not as handy is it?".

Then you aren't listening.  Objects have nothing to do with Cocoa/ObjC.  
Polymorphism has nothing to do with Cocoa/ObjC.  They are basic OO 
concepts that ObjC support in-language, which C++ doesn't support 
without a lot of hacking and external libraries.

> Remember, a large % of the
> universe is already using c++/boost.

No, they're not.  It merely looks that way to use because that is the 
community you surround yourself with.  I don't delude myself about the 
mass appeal of ObjC, or even the downright fringe languages like Io that 
I have a serious interest in.  You know what, though?  I don't care!  I 
use what best solves the problem at hand.  It's a stupid business 
decision to mandate everything be in Java (or whatever) when it's 
possible to use Perl (or whatever) to solve an identical problem with 
less code, less programmer time, and less computer time.  The idea that 
one language, let alone C++, is enough is just a dumb stance to defend.

> The onus is on the Obj-C
> community  to demostrate amazing stuff that can't be accomplished
> easily in c++.  You whipped out that 'stake in the heart' code snippet
> and it turned out to be a limp turd. 

What?  I kicked out 4 lines in 30 seconds that most C++ developers here 
didn't have the ability to hack out a solution to.  Hell, most of you 
can't seem to grasp the difference between the language and a framework.  
If you all think *that* effort was a "stake in the heart" effort, it 
again demonstrates the kind of damage that C++ has done to you.  The 
real test is in real programs, and your hackery breaks down more and 
more as your programs get more complex and require more maintenance.

Nobody here that I can tell has claimed that ObjC is the ultimate 
language, with or without Cocoa.  If you think C++ is so great, feel 
free to post a challenge of your own to show it.  ObjC developers are 
not the ones making extraordinary claims, so the real onus is on you.

> No.  I've read the difference bw c++ static vs. virtual calls is
> generally 5-10% depending of course on how much code is in the called
> method.  The Obj-C runtime does more complicated dispatch so I would
> guess it is higher.  It's certainly not less.

Let's me guess, you're one of those developers who optimizes without 
profiling first.  I can tell you flat-out that when I converted a 
program from C++ to ObjC it ran *faster*.  What you have read or what 
you continue to imagine doesn't matter at all.  A C++ advocate merely 
guessing that C++ is faster means nothing to me.

> You have XCode no?  www.boost.org for the headers I #included.  I have
> posted several complete programs, not snippets - go ahead and test it.

But why should I bother when I have not made any bold claims of speed?  
You *already* have Boost, right?  You *already* have Cocoa, right?  What 
more do you need to prove it yourself?

> > In your case you 
> > have defined code for the special case that involves printing it
> 
> And here is your 'special case' code:
> 
> NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);
> 
> Mine was a few extra lines of code yes, but that's far from showing c++
> can't easily do what your example did.

But it does.  You had to define an entire class geared to the particular 
task!  What if I wanted to do an operation before printing it?

NSLog(@"Twice one of my values is %d", 2 * [[myValues anyObject] 
intValue]);

What if I wanted to use it as another part of a print operation?

NSLog(@"Random padding: %*.4s", [[myValues anyObject] intValue], "wow!");

What if I wanted to do something besides print it?

randomSum += [[myValues anyObject] intValue];

My call of [[myValues anyObject] intValue] doesn't change at all, 
whereas your example seems to require you to define class after class 
for complex behavior every time you want to do something useful.  Dance 
around it all you like, but the more you do the more you demonstrate 
that C++, even with Boost, can't actually do a parity example.
0
Doc
5/20/2004 9:54:07 PM
dans l'article droleary.usenet-F9F37A.16540720052004@corp.supernews.com, Doc
O'Leary � droleary.usenet@subsume.com a �crit le 20/05/04 23:54�:

> It all just works so well that its tough
> for us ObjC wankers to understand why anyone still bothers to raise a
> flag for C++.

Well there is at least one huge reason: cross-platform development. I'm
about to ship the Windows version of a Cocoa app. Using C++, the app is
totally written in one single language. The portability is provided by a C++
library which maps to Cocoa on Mac and Win32 on Windows.

Using Obj-C, I would have had to rewrite my entire app, not speaking of
maintenance.

So until a major actor provides an Obj-C UI framework on Windows, and a
valuable IDE, C++ will remain my choice.

By the way, can you answer the following questions:
 - can you use stack objects in Obj-C ?
 - can you use multiple inheritance ?

Being able to use these, IMHO, compensates largely the lack of introspection
inherent to C++.

I'm not saying the intrinsic value of Obj-C is low, but it's market value is
far from that of C++.

Eric



0
Eric
5/20/2004 11:21:13 PM
In article <droleary.usenet-F76962.15224120052004@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <1ge1nuk.pjbu7tvogb9lN%usenet@mile23.commie.r3m0v3>,
>  usenet@mile23.commie.r3m0v3 (Paul Mitchum) wrote:
> 
> > Much like your 4-liner is using a number of features supplied by Cocoa,
> > and not the Objective-C language. :-)
> 
> As I have noted numerous times, nothing I did requires Cocoa.  Since you 
> have been continually unable to grasp that, I have not choice but to 
> consider your damage at the hands of C++ to be beyond repair.

Doc, I am basically on your side but this isn't right.  I don't have
your original example in front of me but my recollection is that you
used both NSNumber and NSString.  These are both part of Cocoa, albeit
Foundation.  I don't think they are inherent in the Objective C
language.

Spence

-- 
James P. Spencer
Rochester, MN

"Badges??  We don't need no stinkin badges!"
0
James
5/21/2004 1:40:36 AM
In article <200520042040367442%jspencer78REMOVE@charter.net>,
 James Spencer <jspencer78REMOVE@charter.net> wrote:

> In article <droleary.usenet-F76962.15224120052004@corp.supernews.com>,
> Doc O'Leary <droleary.usenet@subsume.com> wrote:
> > As I have noted numerous times, nothing I did requires Cocoa.  Since you 
> > have been continually unable to grasp that, I have not choice but to 
> > consider your damage at the hands of C++ to be beyond repair.
> 
> Doc, I am basically on your side but this isn't right.  I don't have
> your original example in front of me but my recollection is that you
> used both NSNumber and NSString.

Stating for the record that I don't agree with the confrontational tone 
that has been expressed in this thread...

Yes, he did use NSNumber and NSString.  He also used, IIRC, NSSet.  
However, none of that is germane to his point of certain advantages to 
runtime typing.  Because C++ requires method invocation to be completely 
determined at compile time, there can be no equivalent to the following 
(for illustrative purposes only) trivial example:

//
// Log the integer value of whatever object is specified.
//

void  logIntegerValue(id   someObject)
{
   NSLog(@"Integer value of %@ is %d",
         someObject,
         [someObject intValue]);
}

unless 'id' (in the case of a C++ example) is the base object type from 
which all objects derive and 'id' declares an 'intValue'.

But, what happens if you are using a third party object library in the 
C++ program which supports 'intValue' but is not derived from 'id'?  You 
can't pass it to the above function unless you coerce its class and, of 
course, nothing good will result from that. In ObjC, however, it will 
work just fine.

-- 
PGP Key (DH/DSS): http://www.shimkus.com/public_key.asc
PGP Fingerprint:  89B4 52DA CF10 EE03 02AD  9134 21C6 2A68 CE52 EE1A

Windows has always aspired to be Mac-like without Microsoft ever really
understanding what that even means.  - Robert Cringely
0
Joe
5/21/2004 2:31:07 AM
Doc, it's hard to have a discussion with you bc you make new straw men
in every post.  You're also hypocrital and never cop to it when
confonted.  Now *that's* brain damage, though i won't attribute it to
Obj-C.

Here is a quote from Doc O' Leary:

> Just for fun, give me the C++ for 
> this 4-liner:
> NSSet *myValues = [NSSet set];
> [myValues addObject: [NSNumber numberWithInt: 42]];
> [myValues addObject: @"1337"];
> NSLog(@"One of my values is %d", [[myValues anyObject] intValue]);

> Use whatever string, number, and container objects you like with 
> C++ and the above is still a bitch.

I did and it was far from a 'bitch'.  I dare say it was a crapload
easier than you thought it would be.  My experience is that most of the
Obj-C crowd haven't clue what is and isn't possible in c++ these days. 


Witness these additional quotes by Obj-C users from this thread (not
attributable to Doc O' Leary):

> While there are some 
> C++ ways to provide introspection, I'm unaware of any that don't require 
> either a pre-processor of some sort or manually adding special 
> macros/etc...

Which was debunked with several lines of executable sample code.

> Even if you have introspection, calling a virtual method 
> with the same signature on objects that don't share a common base class 
> is difficult at best.

More FUD about c++ or just ignorance?  Either way, disproved with
running code no more complex than a HelloWorld program.

I'm not the O.P. who said you can do everything with c++ that you can
with obj-C.   Quite the opposite is true -- and in both directions.  

One thing I've learned in this thread is that obj-c is clearly a
superior choice if you're writing plug-ins AND those plug-ins will need
to handle objects you didn't originally design for AND you can't edit
the plug-in code to accomodate the new objects.  Phew.  Fortunately,
those requirements have never landed on my doorstep.
0
Chris
5/21/2004 2:52:12 AM
In article <joe-90E962.22314620052004@news04.east.earthlink.net>, Joe
Shimkus <joe@shimkus.com> wrote:

> In article <200520042040367442%jspencer78REMOVE@charter.net>,
>  James Spencer <jspencer78REMOVE@charter.net> wrote:
> 
> > In article <droleary.usenet-F76962.15224120052004@corp.supernews.com>,
> > Doc O'Leary <droleary.usenet@subsume.com> wrote:
> > > As I have noted numerous times, nothing I did requires Cocoa.  Since you 
> > > have been continually unable to grasp that, I have not choice but to 
> > > consider your damage at the hands of C++ to be beyond repair.
> > 
> > Doc, I am basically on your side but this isn't right.  I don't have
> > your original example in front of me but my recollection is that you
> > used both NSNumber and NSString.
> 
> Stating for the record that I don't agree with the confrontational tone 
> that has been expressed in this thread...

Amen.

> 
> Yes, he did use NSNumber and NSString.  He also used, IIRC, NSSet.  
> However, none of that is germane to his point of certain advantages to 
> runtime typing.  

Doc went further: he did't just claim the advantages of runtime typing:
he claimed the language itself supported the code he wrote without
using the Cocoa libraries.  This is what I was objecting to.

> Because C++ requires method invocation to be completely 
> determined at compile time, there can be no equivalent to the following 
> (for illustrative purposes only) trivial example:

I agree and I personally LOVE the dynamic nature of Objective C and
dislike C++'s static typing.  However, I really would prefer to write
most system level software including a new Objective C runtime in C++
rather than Objective C.  Granted I don't do that kind of programming
which is why I prefer Objective C.

Whatever, we aren't convincing anyone here of anything.

Spence

-- 
James P. Spencer
Rochester, MN

"Badges??  We don't need no stinkin badges!"
0
James
5/21/2004 3:07:36 AM
In article <200520042207360697%jspencer78REMOVE@charter.net>,
 James Spencer <jspencer78REMOVE@charter.net> wrote:

> I agree and I personally LOVE the dynamic nature of Objective C and
> dislike C++'s static typing.  However, I really would prefer to write
> most system level software including a new Objective C runtime in C++
> rather than Objective C.

I don't think you could do kernel programming using ObjC.  The runtime 
would have to be part of the kernel for that to work.  Or maybe I'm 
wrong (I really haven't delved into the runtime) which would be great as 
I'd love to do kernel programming using ObjC.  Unfortunately, convincing 
the folks at work to use ObjC (if using it would even be 
possible)....it'd probably be easier to trisect an angle with only a 
straight edge and compass.

-- 
PGP Key (DH/DSS): http://www.shimkus.com/public_key.asc
PGP Fingerprint:  89B4 52DA CF10 EE03 02AD  9134 21C6 2A68 CE52 EE1A

Windows has always aspired to be Mac-like without Microsoft ever really
understanding what that even means.  - Robert Cringely
0
Joe
5/21/2004 4:00:48 AM
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> In article <1ge1nuk.pjbu7tvogb9lN%usenet@mile23.commie.r3m0v3>,
> usenet@mile23.commie.r3m0v3 (Paul Mitchum) wrote:
> 
> > > But you're still using a feature supplied by the Boost library and not
> > > the C++ language.  Get it?
> >
> > Much like your 4-liner is using a number of features supplied by Cocoa,
> > and not the Objective-C language. :-)
> 
> As I have noted numerous times, nothing I did requires Cocoa.  Since you
> have been continually unable to grasp that, I have not choice but to
> consider your damage at the hands of C++ to be beyond repair.

If boost is off-limits, and STL is off-limits, then any class name with
NS in front of it is off-limits, too. You can't have it both ways.

Something you can do in plain-vanilla Objective-C that you can't do in
plain-vanilla C++ is send an arbitrary message to an arbitrary object.
You can demonstrate this using only the id and SEL types, which are
intrinsic to Objective-C; no frameworks are involved, not even a root
object class like NSObject.

That's my only point, and I'm done talking about it.

As to the damaged state of my mind: I learned some C++ a while back,
only enough to make REALbasic plugins. Then I learned Objective-C and
since have had no personal desire to learn more C++. If I'm in error,
it's more likely to be in my knowledge of what you can do with C++.

Enjoy! :-)
0
usenet
5/21/2004 4:54:17 AM
In article <joe-62C020.00012921052004@news04.east.earthlink.net>,
 Joe Shimkus <joe@shimkus.com> wrote:

> In article <200520042207360697%jspencer78REMOVE@charter.net>,
>  James Spencer <jspencer78REMOVE@charter.net> wrote:
> 
> > I agree and I personally LOVE the dynamic nature of Objective C and
> > dislike C++'s static typing.  However, I really would prefer to write
> > most system level software including a new Objective C runtime in C++
> > rather than Objective C.
> 
> I don't think you could do kernel programming using ObjC.  The runtime 
> would have to be part of the kernel for that to work.  Or maybe I'm 
> wrong (I really haven't delved into the runtime) which would be great as 
> I'd love to do kernel programming using ObjC.

Nope; you're right.

-Eric

-- 
Eric Albert         ejalbert@cs.stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
5/21/2004 5:10:37 AM
In article <BCD30A09.2194B%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Well there is at least one huge reason: cross-platform development. I'm
> about to ship the Windows version of a Cocoa app. Using C++, the app is
> totally written in one single language. The portability is provided by a C++
> library which maps to Cocoa on Mac and Win32 on Windows.

What's your point?  Apple had (but pulled, the bastards) Yellow Box that 
similarly allowed a developer to check a box and get a Windows binary.  
GNUstep aims to to achieve porting ease for Cocoa using open source.  
There is also nothing that prevents you from writing ObjC to a non-Cocoa 
interface that maps to Cocoa on the Mac side and "whatever" 
(MFC/wxWin/Qt) on the Windows side.
 
> Using Obj-C, I would have had to rewrite my entire app, not speaking of
> maintenance.

What you think is a unique feature is nothing of the sort.  For any 
existing application, you are forced to rewrite to the interface of a 
portable library, and you are forced to maintain that library for your 
application to continue working.

> So until a major actor provides an Obj-C UI framework on Windows, and a
> valuable IDE, C++ will remain my choice.

Yeah, right.  You clearly demonstrate you have no idea what frameworks 
have been or are still offered.  You use C++ not from a position of 
knowledge, but from a position of ignorance.

> By the way, can you answer the following questions:

I can, but I'll preface them with a note that you're asking new-grad 
style questions.  Such yes/no stabs are a sure sign that someone doesn't 
fully grasp programming; that they're doing little more thinking than 
trying to fill in check boxes from some mental marketing brochure. 

>  - can you use stack objects in Obj-C ?

What is the value of stack objects to you?  Is your real question what 
kind of scoped garbage collection mechanism ObjC imposes?  The answer to 
that is that it doesn't impose one, and I think people have successfully 
grafted just about every C-based GC on to some library of ObjC.  For Mac 
OS X programming, assume you cannot put objects on the stack.  Now how 
is that a problem for you?

>  - can you use multiple inheritance ?

What does MI give you that is so important?  ObjC provides true 
interface polymorphism.  If something behaves like both a Car and a Boat 
then, hell, it doesn't even have to inherit from *either* to be used as 
a CarBoat.  As long as the right methods are implemented, the runtime is 
happy.  Any language that makes MI necessary is limping along with a 
*huge* crutch.  For Mac OS X programming, assume you cannot inherit from 
more than one object.  Now how is that a problem for you?

> Being able to use these, IMHO, compensates largely the lack of introspection
> inherent to C++.

You are not *able* to use them with C++, you are *required* to use them 
to come even close to making use of the language.  The fact that you 
think they offer you important features shows just how little exposure 
you have to other OO languages.

> I'm not saying the intrinsic value of Obj-C is low, but it's market value is
> far from that of C++.

What is the market value of C++?  Tons of developers without a sound 
foundation in OO development independent of the language their school 
shoved down their throat?  That's like saying Java has even more of 
market value than C++ now when, in fact, the reality is that it merely 
puts a business on a level playing field.  Where is the competitive 
advantage of hiring just another Java graduate to crank out just another 
Java app?  I would never hire anyone who is only comfortable with 
mainstream languages.  I want someone who can do something *unique* for 
my business; something other businesses are unwilling or unable to do.
0
Doc
5/21/2004 9:31:54 PM
In article <200520042207360697%jspencer78REMOVE@charter.net>,
 James Spencer <jspencer78REMOVE@charter.net> wrote:

> In article <joe-90E962.22314620052004@news04.east.earthlink.net>, Joe
> Shimkus <joe@shimkus.com> wrote:
> 
> > Stating for the record that I don't agree with the confrontational tone 
> > that has been expressed in this thread...
> 
> Amen.

For my part in that, I'm just direct.  That can rub people wrong on 
Usenet where a lot of context gets lost in text, but in the real world I 
find most people I work with prefer direct answers.  They joke that I 
have no tact, but at the end of they day they seem to prefer to know 
where they stand instead of having been blown smoke.

> > Yes, he did use NSNumber and NSString.  He also used, IIRC, NSSet.  
> > However, none of that is germane to his point of certain advantages to 
> > runtime typing.  
> 
> Doc went further: he did't just claim the advantages of runtime typing:
> he claimed the language itself supported the code he wrote without
> using the Cocoa libraries.  This is what I was objecting to.

You objected to the truth?  The language supports the *important* things 
in the code.  If you couldn't pick out what was important, you need to 
study the code harder.  I even said directly that you could simply swap 
NS classes for Doc (or whatever) classes.  Cocoa was used because it is 
easy to read and probably familiar to people in this group.  You didn't 
have to pour though any manuals (I hope! :-) to puzzle out what 
-anyObject or -intValue probably do.  I really don't understand why so 
many are confused by the idea that the classes aren't important, which 
leaves me with the standard line that C++ has damaged their thinking 
somehow.  I can only imagine they'd have complete breakdowns when 
confronted by an OO language that does even *have* a class-instance 
distinction.

> I agree and I personally LOVE the dynamic nature of Objective C and
> dislike C++'s static typing.  However, I really would prefer to write
> most system level software including a new Objective C runtime in C++
> rather than Objective C.  Granted I don't do that kind of programming
> which is why I prefer Objective C.

C++ would be a mess for system-level development.  I often think that 
going C++ "everywhere" is what ultimately killed Be off.  When you're 
just bootstrapping things up to a usable state, I see no reason to reach 
much past C.  ObjC is much closer to C than C++ is, but even then I 
think it goes farther than necessary for that low-level stuff.
0
Doc
5/21/2004 9:52:23 PM
Miro Jurisic <macdev@meeroh.org> wrote in message news:<macdev-4EFFD2.04170217052004@senator-bedfellow.mit.edu>...
 
> course, Objective-C makes the process of getting your head up your ass very 
> efficient. You just have to drag a line from your head to your ass in Interface 
> Builder.

Heh, that made my day. I wonder if I could work that into my next book...

Oh yeah, the rest of your comments are right on too.

Andrew
0
aduncan
5/21/2004 10:37:31 PM
For a reasonably flame-free answer to this question, see for example

  http://www.macdevcenter.com/pub/a/mac/2003/04/28/objective-c.html

Andrew
0
aduncan
5/21/2004 11:00:50 PM
In article <190520041833003329%cbaum981@atlantic.net>,
 Chris Baum <cbaum981@atlantic.net> wrote:

> In article <40ABD9A1.9C216C00@nospam.idiom.com>, John C. Randolph
> <jcr@nospam.idiom.com> wrote:
> 
> > As it happens, I found that the going rates for the guys who wrote code
> > in the most popular languages on the most popular platforms tended to
> > run about a third to half of what I charged for working on my favorite
> > niche product.
> 
> 
> As long as the niche remains.  
> 
> Some would argue it's better to keep your skills sharpened and
> state-of-the-art in the areas where work exists and appears likely to
> exist in the future.  Obj-C is almost exclusivley used only when
> accompanied by a proprietary framework that is owned by a private corp.
> with a 1.8% market share and shrinking.

I wonder if you could provide some support for your assertion about the 
adoption of Objective-C and clarify the relevance of market share to the 
3rd-party developer.

G

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/22/2004 12:05:37 AM
dans l'article droleary.usenet-7644FF.16315421052004@corp.supernews.com, Doc
O'Leary � droleary.usenet@subsume.com a �crit le 21/05/04 23:31�:

> In article <BCD30A09.2194B%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> Well there is at least one huge reason: cross-platform development. I'm
>> about to ship the Windows version of a Cocoa app. Using C++, the app is
>> totally written in one single language. The portability is provided by a C++
>> library which maps to Cocoa on Mac and Win32 on Windows.
> 
> What's your point?  Apple had (but pulled, the bastards) Yellow Box that
> similarly allowed a developer to check a box and get a Windows binary.
> GNUstep aims to to achieve porting ease for Cocoa using open source.
> There is also nothing that prevents you from writing ObjC to a non-Cocoa
> interface that maps to Cocoa on the Mac side and "whatever"
> (MFC/wxWin/Qt) on the Windows side.

Since I don't want a Windows app to behave like a Mac app, I won't complain
about the death of the Yellow Box.

>> Using Obj-C, I would have had to rewrite my entire app, not speaking of
>> maintenance.
> 
> What you think is a unique feature is nothing of the sort.  For any
> existing application, you are forced to rewrite to the interface of a
> portable library, and you are forced to maintain that library for your
> application to continue working.

You don't know what I *think*, only what I write. It's definitely possible,
but truth is it would have required much more rewriting using Obj-C, since I
have so much C++ code already running. Also, it would most certainly slow
down the app on systems for which no System-level Obj-C framework is
available, which unfortunately is the case with Windows. I *did* mention
market value.

>> So until a major actor provides an Obj-C UI framework on Windows, and a
>> valuable IDE, C++ will remain my choice.
> 
> Yeah, right.  You clearly demonstrate you have no idea what frameworks
> have been or are still offered.  You use C++ not from a position of
> knowledge, but from a position of ignorance.

Since you're not providing any answers to the question, you may as well shut
up. Insulting me doesn't make you clever.

>> By the way, can you answer the following questions:
> 
> I can, but I'll preface them with a note that you're asking new-grad
> style questions.  Such yes/no stabs are a sure sign that someone doesn't
> fully grasp programming; that they're doing little more thinking than
> trying to fill in check boxes from some mental marketing brochure.
> 
>>  - can you use stack objects in Obj-C ?
> 
> What is the value of stack objects to you?  Is your real question what
> kind of scoped garbage collection mechanism ObjC imposes?  The answer to
> that is that it doesn't impose one, and I think people have successfully
> grafted just about every C-based GC on to some library of ObjC.  For Mac
> OS X programming, assume you cannot put objects on the stack.  Now how
> is that a problem for you?

No, my real question was: "Can you use stack objects in Obj-C ?" If I cared
that much about GC, I would use Java rather than Obj-C. Stack objects are
very useful not only for garbage collection but also for ensuring consistent
state of objects, for example locks. Say you have a global lock, and a
Locker class that locks a lock in its constructor and unlocks it in its
destructor, with a stack base Locker you can safely throw exceptions within
any scope without worrying about unlocking the lock. Don't tell me you can
do so in the 'finally' statement, there are many cases wher it's simply not
convenient. This is just one example. Stack objects are also very important
for performance. Allocating objects TAKES time, so if you need a small
utility object, for example to read specific bytes in a buffer, a stack
object is definitely faster than a heap object.

>>  - can you use multiple inheritance ?
> 
> What does MI give you that is so important?  ObjC provides true
> interface polymorphism.  If something behaves like both a Car and a Boat
> then, hell, it doesn't even have to inherit from *either* to be used as
> a CarBoat.  As long as the right methods are implemented, the runtime is
> happy.  Any language that makes MI necessary is limping along with a
> *huge* crutch.  For Mac OS X programming, assume you cannot inherit from
> more than one object.  Now how is that a problem for you?

It is because from a Design perspective, separating services is an absolute
need. This is precisely why Obj-C provides protocols, so don't tell me it's
unnecessary. Since you cannot encapsulate data in protocols, nor can you
'append' data to existing classes using poseAsClass, as a result, if the
service requires both methods and data, you cannot simply re-use an
implementation like you do in C++ through MI. You have to re-implement it in
each single class that uses it. Is that a 'feature' of Obj-C ?

>> Being able to use these, IMHO, compensates largely the lack of introspection
>> inherent to C++.
> 
> You are not *able* to use them with C++, you are *required* to use them
> to come even close to making use of the language. The fact that you
> think they offer you important features shows just how little exposure
> you have to other OO languages.

This stupid assertion shows just how little exposure you have to C++. See ?
Easy to insult people without providing ANY argument (not speaking of
valuable ones).

The ONLY features I know that Obj-C provides that I don't have and can't
easily have in C++ are related to introspection. I use introspection in both
Java and Obj-C, and I don't think it's OFTEN useful. I believe in STRONG
typing, not because I'm a C++ programmer, since I'm also an Obj-C, a Java, a
Javascript, a 4D, a VB, a SQL and an assembly programmer. I believe in
STRONG typing because I'd rather let the compiler tell me a method I call is
unknown or called with wrong parameters rather than discover it at runtime.

Maybe YOU are the ignorant. Maybe Obj-C is fine for stupid programmers like
you, and C++ fine for brilliant programmers like me ? Now that sentence
sounds exactly as if Doc O'Leary had written it. Why don't you stop
contributing to this newsgroup ? Everybody is tired of your insults.

>> I'm not saying the intrinsic value of Obj-C is low, but it's market value is
>> far from that of C++.
> 
> What is the market value of C++?  Tons of developers without a sound
> foundation in OO development independent of the language their school
> shoved down their throat?  That's like saying Java has even more of
> market value than C++ now when, in fact, the reality is that it merely
> puts a business on a level playing field.  Where is the competitive
> advantage of hiring just another Java graduate to crank out just another
> Java app?  I would never hire anyone who is only comfortable with
> mainstream languages.  I want someone who can do something *unique* for
> my business; something other businesses are unwilling or unable to do.

What makes an application unique is certainly NOT the language used to write
it, it's the way it is designed.

And from a CEO's perspective, being able to easily enhance, port and
maintain existing code is much more important than implementation details.

Now making this long contribution just to insult me just shows how much of
your energy you spend in useless considerations compared to that required to
create useful applications.

The sad news is that you'll be out of business before you even understand
what I'm talking about.

Eric

0
Eric
5/22/2004 9:07:12 AM
dans l'article c1b18814.0405211500.49343bd9@posting.google.com, Andrew
Duncan � aduncan@expertcity.com a �crit le 22/05/04 1:00�:

> For a reasonably flame-free answer to this question, see for example
> 
> http://www.macdevcenter.com/pub/a/mac/2003/04/28/objective-c.html
> 
> Andrew

Very interesting indeed, but doesn't close the case between supporters of
strong typing and compile time checking and supporters loose design.

Eric

0
Eric
5/22/2004 9:12:38 AM
Eric VERGNAUD wrote:
> Stack objects are very useful not only for garbage collection but also
> for ensuring consistent state of objects, for example locks. Say you
> have a global lock, and a Locker class that locks a lock in its
> constructor and unlocks it in its destructor, with a stack base Locker
> you can safely throw exceptions within any scope without worrying
> about unlocking the lock.

i really agree with this one.  one of my first things i wrote as a
beginning obj-c programmer was to wrap up an NSAutoreleasePool inside a
c++ object.  that way, i can create one on the stack, and ensure that
the pool will be dumped as the function is exited.  one of the cool ways
you can use obj-c++ to get the power of both languages.

as for multiple inheritance: that's one area of c++ that i've personally
deemed too complex to muck with.  the java form of mi, where you can
only multiply-inherit from a mixin that contains no data of its own,
seems a good compromise.  obj-c protocols are a well-restricted form of
mi also, i think.
0
ISO
5/22/2004 9:18:48 PM
In article <BCD4E4E0.21A67%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Since I don't want a Windows app to behave like a Mac app, I won't complain
> about the death of the Yellow Box.

Pure ignorance.  Ever seen a Yellow Box app?  Better, point out anything 
in OpenStep that requires a Mac-like look and feel.  Are you seriously 
in charge of any multi-platform development?  How can you not know how 
to do that sort of thing?  Please let me know what Mac apps you've 
worked on so I can be sure to avoid them.

> It's definitely possible,
> but truth is it would have required much more rewriting using Obj-C, since I
> have so much C++ code already running.

That is about the dumbest argument I have ever heard.  That's like me 
saying C++ makes porting harder because I'd have to rewrite all my ObjC 
code!  So you have *zero* idea about ObjC porting.  All you do is C++ so 
you just assume C++ is more portable.

> Also, it would most certainly slow
> down the app on systems for which no System-level Obj-C framework is
> available, which unfortunately is the case with Windows.

Another ignorant assumption.  You again assume that the layers of 
hackery your porting library goes through must be quick and efficient.  
In reality, an ObjC port can be as simple as linking directly to a 
native Cocoa.framework.  I don't get why you think your wrapper library 
would be any more speedy.

> No, my real question was: "Can you use stack objects in Obj-C ?"

As I noted, that's not a real question.  I guessed wrong that it was 
about GC; instead it was a different issue of scope.  Why not simply ask 
the question you have about object scope instead of dancing around what 
you're interested in?

> Stack objects are
> very useful not only for garbage collection but also for ensuring consistent
> state of objects, for example locks.

That may be how you make use of them for C++, but the issue is entirely 
independent of the feature.  If ObjC seems to be doing OO quite well 
without the things you find *necessary* for C++, doesn't that point more 
to the fact that C++ is a crap language rather than the possibility that 
ObjC is missing something?

> Say you have a global lock, and a
> Locker class that locks a lock in its constructor and unlocks it in its
> destructor, with a stack base Locker you can safely throw exceptions within
> any scope without worrying about unlocking the lock. Don't tell me you can
> do so in the 'finally' statement, there are many cases wher it's simply not
> convenient. This is just one example.

That a pretty poor example.  It has almost nothing to do with scope.  It 
has to do with object deallocation (so, in a way, you *have* asked a GC 
question).  Cocoa could do the same thing in the scope of any 
autorelease pool.

> Stack objects are also very important
> for performance. Allocating objects TAKES time, so if you need a small
> utility object, for example to read specific bytes in a buffer, a stack
> object is definitely faster than a heap object.

Sounds like speculation to me.  Profile me some code to show that 
differences in simple object allocation is a significant time suck.

> It is because from a Design perspective, separating services is an absolute
> need.

That makes zero sense.  Not only are you talking about design here and 
implementation later, I don't see how tying things together via MI 
achieves the separation you claim is necessary.  And what are these 
"services" you're talking about?  More action classes from the C++ 
gallery?

> This is precisely why Obj-C provides protocols, so don't tell me it's
> unnecessary.

Do you know what you're talking about?  A protocol just defines an 
interface.  Do you perhaps mean a category?  If so, you're still 
confused about the features they offer.

> Since you cannot encapsulate data in protocols, nor can you
> 'append' data to existing classes using poseAsClass,

I don't understand what you're saying.  Do you even have any real OO 
background?  What is this "data" you're going on about?  What are 
"encapsulate" and "append" in this context?  Are you talking about 
adding instance variables here?

> as a result, if the
> service requires both methods and data, you cannot simply re-use an
> implementation like you do in C++ through MI. You have to re-implement it in
> each single class that uses it. Is that a 'feature' of Obj-C ?

Yes, but you're just too blind to see it.  ObjC can use composition 
(with transparent forwarding, too) to reuse existing classes without 
inheriting directly from them.  All I'm getting from you is that you 
really only know OO by way of C++.  Color me unimpressed.

> > You are not *able* to use them with C++, you are *required* to use them
> > to come even close to making use of the language. The fact that you
> > think they offer you important features shows just how little exposure
> > you have to other OO languages.
> 
> This stupid assertion shows just how little exposure you have to C++. See ?
> Easy to insult people without providing ANY argument (not speaking of
> valuable ones).

Your own words are ample argument of all that you don't understand.  
When I say ObjC doesn't have MI, I easily argue that what MI offers can 
be had with other OO techniques supported by the language itself.  If 
you think I'm so wrong, all you have to do is argue how you can 
accomplish what you want in C++ *without* MI.  If you can't, that is a 
pretty good case that such things are necessary in C++ but not necessary 
from an OO perspective.  If you really want to talk about code reuse, 
talk about code reuse; MI is neither related nor required.

> I believe in
> STRONG typing because I'd rather let the compiler tell me a method I call is
> unknown or called with wrong parameters rather than discover it at runtime.

My compiler tells me these things with ObjC.  What crappy compiler are 
you using that doesn't?

> Maybe YOU are the ignorant. Maybe Obj-C is fine for stupid programmers like
> you, and C++ fine for brilliant programmers like me ?

Maybe so.  I'm willing to entertain that possibility.  In fact, the 
*first* assumption I make when tackling a problem is that I'm a moron.  
It usually makes the right answer easier to find and accept.  Maybe 
thinking you're brilliant all the time is what makes the right thing so 
hard for you to see?

> Now that sentence
> sounds exactly as if Doc O'Leary had written it. Why don't you stop
> contributing to this newsgroup ? Everybody is tired of your insults.

Might be time to learn how to use a kill file, son.  But, then, what do 
I know, what with me being so ignorant and all . . .

> What makes an application unique is certainly NOT the language used to write
> it, it's the way it is designed.

Bingo!  A good OO design translates better to a good OO language.  I 
have seen far too many cases of programmers with a C++ background 
actually doing the *design* with C++ in mind rather than doing a solid 
OO design.  Maybe I should fault the programmer or their school more 
than the language, but I never seem to see crap designs coming from 
developers with other backgrounds.  My conclusion is that no other 
language does quite so much damage to an OO developer's design as C++ 
does.

> And from a CEO's perspective, being able to easily enhance, port and
> maintain existing code is much more important than implementation details.

Yet none of those things is especially true for C++.  Even the same hype 
around Java has turned out to be more market speak than reality.  From a 
CEO's perspective, doing better than the *other* guy is what is 
important.  Doing what the other guy is doing (i.e., endlessly chasing 
after the next proclaimed silver bullet) does *not* provide a 
competitive advantage.

> Now making this long contribution just to insult me just shows how much of
> your energy you spend in useless considerations compared to that required to
> create useful applications.

Maybe creating useful applications is so easy for me that I can spend a 
lot of time dedicated to insulting you.  Maybe it doesn't actually take 
a lot of time and effort to find ways to insult you.  Maybe I'm not even 
trying to insult you at all, and you merely *feel* insulted because I'm 
an idiot who has managed to construct a valid opposition to what you 
consider your own brilliant opinion.

> The sad news is that you'll be out of business before you even understand
> what I'm talking about.

Will I?  Me and Apple are beleaguered buddies!  Billions in the bank 
HERE I COME
!
0
Doc
5/23/2004 2:15:29 AM
>> Since I don't want a Windows app to behave like a Mac app, I won't complain
>> about the death of the Yellow Box.
> 
> Pure ignorance.  Ever seen a Yellow Box app?
Well I've seen iTunes on Windows, and that's enough for me.
> 
>> It's definitely possible,
>> but truth is it would have required much more rewriting using Obj-C, since I
>> have so much C++ code already running.
> 
> That is about the dumbest argument I have ever heard.
Well since you spend roughly 4 hours every single day insulting people on
this newsgroup, I assume YOUR apps are involve less than 1000 lines of code.
Mine involve 1000000, so it would have taken some time to port them to
Obj-C. Ever heard about deadlines ?
> 
>> Also, it would most certainly slow
>> down the app on systems for which no System-level Obj-C framework is
>> available, which unfortunately is the case with Windows.
> 
> Another ignorant assumption.  You again assume that the layers of
> hackery your porting library goes through must be quick and efficient.
> In reality, an ObjC port can be as simple as linking directly to a
> native Cocoa.framework.  I don't get why you think your wrapper library
> would be any more speedy.

Well where is YOUR knowledge ? Can YOU give an example of successfull Obj-C
port ? We're all dying for the answer.
 
>> No, my real question was: "Can you use stack objects in Obj-C ?"
> 
> As I noted, that's not a real question.  I guessed wrong that it was
> about GC; instead it was a different issue of scope.  Why not simply ask
> the question you have about object scope instead of dancing around what
> you're interested in?

Oh yes it IS a real question. But since YOU don't want to answer it, you say
it's not a real one.

>> Stack objects are
>> very useful not only for garbage collection but also for ensuring consistent
>> state of objects, for example locks.
> 
> That may be how you make use of them for C++, but the issue is entirely
> independent of the feature.  If ObjC seems to be doing OO quite well
> without the things you find *necessary* for C++, doesn't that point more
> to the fact that C++ is a crap language rather than the possibility that
> ObjC is missing something?

>> Say you have a global lock, and a
>> Locker class that locks a lock in its constructor and unlocks it in its
>> destructor, with a stack base Locker you can safely throw exceptions within
>> any scope without worrying about unlocking the lock. Don't tell me you can
>> do so in the 'finally' statement, there are many cases wher it's simply not
>> convenient. This is just one example.
> 
> That a pretty poor example.  It has almost nothing to do with scope.  It
> has to do with object deallocation (so, in a way, you *have* asked a GC
> question).  Cocoa could do the same thing in the scope of any
> autorelease pool.

No it has nothing to do with object deallocation. It has to do with
lifetime. Obj-C is NOT doing the things I need. It doesn't automatically
call destructors when an object is out of scope. Neither does Java. Only C++
provides this guarantee without me having to take care of it.

Which doesn't mean C++ is the best language around. In fact the language
that is closest to what I need varies depending on what I'm doing. I use
Java when I only do business logic, and C++ when I do user-friendly highly
interactive cross-platform apps, which doesn't mean Java and C++ cover
everyone's needs, neither that I refuse people the right to prefer Obj-C if
they're only in charge on MacOSX apps.
 
>> Stack objects are also very important
>> for performance. Allocating objects TAKES time, so if you need a small
>> utility object, for example to read specific bytes in a buffer, a stack
>> object is definitely faster than a heap object.
> 
> Sounds like speculation to me.  Profile me some code to show that
> differences in simple object allocation is a significant time suck.

I will.

>> It is because from a Design perspective, separating services is an absolute
>> need.
> 
> That makes zero sense.  Not only are you talking about design here and
> implementation later, I don't see how tying things together via MI
> achieves the separation you claim is necessary.  And what are these
> "services" you're talking about?  More action classes from the C++
> gallery?
> 
>> This is precisely why Obj-C provides protocols, so don't tell me it's
>> unnecessary.
> 
> Do you know what you're talking about?  A protocol just defines an
> interface.  Do you perhaps mean a category?  If so, you're still
> confused about the features they offer.
> 
>> Since you cannot encapsulate data in protocols, nor can you
>> 'append' data to existing classes using poseAsClass,
> 
> I don't understand what you're saying.

You said it ! Looks like YOUR brain is damaged by Obj-C.

> Do you even have any real OO
> background?  What is this "data" you're going on about?  What are
> "encapsulate" and "append" in this context?  Are you talking about
> adding instance variables here?
> 
>> as a result, if the
>> service requires both methods and data, you cannot simply re-use an
>> implementation like you do in C++ through MI. You have to re-implement it in
>> each single class that uses it. Is that a 'feature' of Obj-C ?
> 
> Yes, but you're just too blind to see it.  ObjC can use composition
> (with transparent forwarding, too) to reuse existing classes without
> inheriting directly from them.  All I'm getting from you is that you
> really only know OO by way of C++.  Color me unimpressed.
> 
>>> You are not *able* to use them with C++, you are *required* to use them
>>> to come even close to making use of the language. The fact that you
>>> think they offer you important features shows just how little exposure
>>> you have to other OO languages.
>> 
>> This stupid assertion shows just how little exposure you have to C++. See ?
>> Easy to insult people without providing ANY argument (not speaking of
>> valuable ones).
> 
> Your own words are ample argument of all that you don't understand.
> When I say ObjC doesn't have MI, I easily argue that what MI offers can
> be had with other OO techniques supported by the language itself.  If
> you think I'm so wrong, all you have to do is argue how you can
> accomplish what you want in C++ *without* MI.  If you can't, that is a
> pretty good case that such things are necessary in C++ but not necessary
> from an OO perspective.  If you really want to talk about code reuse,
> talk about code reuse; MI is neither related nor required.
> 

Well that is a very stupid argument, because true MI is necessary to all OO
objects. The fact that, due to runtime limits, it is not provided with Obj-C
does not invalidate the concept.

>> I believe in
>> STRONG typing because I'd rather let the compiler tell me a method I call is
>> unknown or called with wrong parameters rather than discover it at runtime.
> 
> My compiler tells me these things with ObjC.  What crappy compiler are
> you using that doesn't?

Well do you know a compiler which can warn you about a misuse of [obj
performSelector:withObject:] ? Does YOUR compiler check the type of
'withObject' ?

>> Maybe YOU are the ignorant. Maybe Obj-C is fine for stupid programmers like
>> you, and C++ fine for brilliant programmers like me ?
> 
> Maybe so.  I'm willing to entertain that possibility.  In fact, the
> *first* assumption I make when tackling a problem is that I'm a moron.
> It usually makes the right answer easier to find and accept.  Maybe
> thinking you're brilliant all the time is what makes the right thing so
> hard for you to see?

Well since you behave like you were GOD, nobody cares about how you reached
that opinion. You NEVER help anyone.

>> Now that sentence
>> sounds exactly as if Doc O'Leary had written it. Why don't you stop
>> contributing to this newsgroup ? Everybody is tired of your insults.
> 
> Might be time to learn how to use a kill file, son.  But, then, what do
> I know, what with me being so ignorant and all . . .
> 
>> What makes an application unique is certainly NOT the language used to write
>> it, it's the way it is designed.
> 
> Bingo!  A good OO design translates better to a good OO language.  I
> have seen far too many cases of programmers with a C++ background
> actually doing the *design* with C++ in mind rather than doing a solid
> OO design.  Maybe I should fault the programmer or their school more
> than the language, but I never seem to see crap designs coming from
> developers with other backgrounds.  My conclusion is that no other
> language does quite so much damage to an OO developer's design as C++
> does.

Well you really don't understand. Who cares about OO design ? The market ?
No. The end-user ? Neither. Only programmers do. A good design has nothing
to do with the technical design, only with the features provided and the
performances.

>> And from a CEO's perspective, being able to easily enhance, port and
>> maintain existing code is much more important than implementation details.
> 
> Yet none of those things is especially true for C++.  Even the same hype
> around Java has turned out to be more market speak than reality.  From a
> CEO's perspective, doing better than the *other* guy is what is
> important.  Doing what the other guy is doing (i.e., endlessly chasing
> after the next proclaimed silver bullet) does *not* provide a
> competitive advantage.

Yes it is, because while there are only a few Obj-C programmers out there,
there are millions of Java and C++ programmers, and as we've often seen on
this newsgroup, many of them are reluctant to learn Obj-C (I'm not saying
they're right)

>> Now making this long contribution just to insult me just shows how much of
>> your energy you spend in useless considerations compared to that required to
>> create useful applications.
> 
> Maybe creating useful applications is so easy for me that I can spend a
> lot of time dedicated to insulting you.  Maybe it doesn't actually take
> a lot of time and effort to find ways to insult you.  Maybe I'm not even
> trying to insult you at all, and you merely *feel* insulted because I'm
> an idiot who has managed to construct a valid opposition to what you
> consider your own brilliant opinion.

Well why don't you show us your useful apps ? I don't consider myself as a
brilliant guy, but rather a reasonable one. As we've seen in Irak, truth is
not always what it seems. Are you a member of G.W.Bush's family ?

>> The sad news is that you'll be out of business before you even understand
>> what I'm talking about.
> 
> Will I?  Me and Apple are beleaguered buddies!  Billions in the bank
> HERE I COME
> !

Well if you're happy with 1% of the market, that's good for you. Apple is
making money with computers, ipods and 1$ tunes, not with Obj-C.

0
Eric
5/23/2004 12:12:40 PM
In article <BCD661D8.21AD1%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> >> Since I don't want a Windows app to behave like a Mac app, I won't 
> >> complain
> >> about the death of the Yellow Box.
> > 
> > Pure ignorance.  Ever seen a Yellow Box app?
> Well I've seen iTunes on Windows, and that's enough for me.

One data point is not a valid sample for generalizing anything other 
than that data point. For some additional data points, you might notice 
that all of the few applications Apple provides for Windows look and act 
like their Mac counterparts. You might also note that iTunes is not a 
Cocoa app. It's C++. Has nothing to do with the language or tools Apple 
used, and everything to do with Apple's branding strategy.

G

-- 
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses.  - Jeremy Nixon
0
Gregory
5/23/2004 12:39:37 PM
dans l'article gwestonREMOVE-1D7198.08393623052004@netnews.comcast.net,
Gregory Weston � gwestonREMOVE@CAPSattbi.com a �crit le 23/05/04 14:39�:

> In article <BCD661D8.21AD1%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>>>> Since I don't want a Windows app to behave like a Mac app, I won't
>>>> complain
>>>> about the death of the Yellow Box.
>>> 
>>> Pure ignorance.  Ever seen a Yellow Box app?
>> Well I've seen iTunes on Windows, and that's enough for me.
> 
> One data point is not a valid sample for generalizing anything other
> than that data point. For some additional data points, you might notice
> that all of the few applications Apple provides for Windows look and act
> like their Mac counterparts. You might also note that iTunes is not a
> Cocoa app. It's C++. Has nothing to do with the language or tools Apple
> used, and everything to do with Apple's branding strategy.
> 
> G

Good point.

Eric

0
Eric
5/23/2004 1:03:58 PM
In article <BCD661D8.21AD1%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> >> Since I don't want a Windows app to behave like a Mac app, I won't 
> >> complain
> >> about the death of the Yellow Box.
> > 
> > Pure ignorance.  Ever seen a Yellow Box app?
>
> Well I've seen iTunes on Windows, and that's enough for me.


iTunes on the Mac side is NOT a Cocoa/Obj-C app. I have no reason to 
believe it is on windows either.
0
Mr
5/23/2004 1:19:49 PM
A promised to Doc O'Leary, here is a benchmark to evaluate advantages of
stack allocation. This benchmark provides 4 equivalent methods to safely
read a byte from a buffer. The first method uses an Objective-C instance.
The second method uses a heap allocated C++  instance, the third method uses
a stack C++ instance, and the last method uses an optimized (inlined) stack
C++ instance. On my computer (dual 1.8 G5), the results show as follows:

 - Objective-C: 0.7132801860570908
 - Heap C++: 0.1898949742317200
 - Stack C++: 0.06839983165264130
 - Inline C++: 0.03367300331592560

The code was compiled with CW 8.3, all optimizations off. I'm interested in
an Xcode benchmark to see if it brings any differences.
 
What this code shows is that:
 - the send_msg mechanism inherent to Obj-C slows down the loop by a 3.75
factor.
 - a stack object is almost 3 times faster than the heap object. Obj-C does
not allow stack objects.
 - inlining doubles the performance. I don't think it's possible to inline
Obj-C calls, is it ?

The overall result is that C++ code can run as much as 21 times faster than
Obj-C code.

Now I hope that this benchmark will show to everyone that Obj-C is NOT the
best language for ALL tasks. Neither is C++, neither is Java.

Here is the code:

@interface ObjCReader : NSObject {
    char* fBuffer;
    int fSize;
}
- (id)initWithBuffer:(char*)inBuffer withSize:(int)inSize;
- (char)getTheByte;

@end

@implementation ObjCReader

- (id)initWithBuffer:(char*)inBuffer withSize:(int)inSize {
    self = [super init];
    fBuffer = inBuffer;
    fSize = inSize;
    return self;
}

- (char)getTheByte {
    if(fSize<=32)
        return 0;
    return fBuffer[31];
}

@end

class CplusReader {
public:
    CplusReader(char* inBuffer,int inSize);
    char getTheByte();
    
protected:
    char* fBuffer;
    int fSize;
};

CplusReader::CplusReader(char* inBuffer,int inSize)
{
    fBuffer = inBuffer;
    fSize = inSize;
}

char CplusReader::getTheByte()
{
    if(fSize<=32)
        return 0;
    return fBuffer[31];
}

class InlineReader {
public:
    InlineReader(char* inBuffer,int inSize);
    char getTheByte();
    
protected:
    char* fBuffer;
    int fSize;
};

inline InlineReader::InlineReader(char* inBuffer,int inSize)
{
    fBuffer = inBuffer;
    fSize = inSize;
}

inline char InlineReader::getTheByte()
{
    if(fSize<=32)
        return 0;
    return fBuffer[31];
}

char objccall(char* inBuffer,int inSize);
char objccall(char* inBuffer,int inSize)
{
    char result;
    
    ObjCReader* reader = [[ObjCReader alloc] initWithBuffer:inBuffer
withSize:inSize];
    result = [reader getTheByte];
    [reader release];
    return result;
}

char heapcall(char* inBuffer,int inSize);
char heapcall(char* inBuffer,int inSize)
{
    CplusReader* reader = new CplusReader(inBuffer,inSize);
    char result = reader->getTheByte();
    delete reader;
    return result;
}

char stackcall(char* inBuffer,int inSize);
char stackcall(char* inBuffer,int inSize)
{
    CplusReader reader(inBuffer,inSize);
    return reader.getTheByte();
}

char inlinecall(char* inBuffer,int inSize);
char inlinecall(char* inBuffer,int inSize)
{
    InlineReader reader(inBuffer,inSize);
    return reader.getTheByte();
}
    
int main(int argc, const char *argv[])
{
    NSDate* start,*end;
    NSTimeInterval g1,g2,g3,g4;
    char buffer[32];
    char test;
    long i;
    
    NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];

    // 1 million calls using Obj-C
    start = [NSDate date];
    for(i=0;i<1000000;i++)
    {
        test = objccall(buffer,sizeof(buffer));
    }
    end = [NSDate date];
    g1 = [end timeIntervalSinceDate:start];
    [start release];
    [end release];

    // 1 million calls using heap C++
    start = [NSDate date];
    for(i=0;i<1000000;i++)
    {
        test = heapcall(buffer,sizeof(buffer));
    }
    end = [NSDate date];
    g2 = [end timeIntervalSinceDate:start];
    [start release];
    [end release];

    // 1 million calls using stack C++
    start = [NSDate date];
    for(i=0;i<1000000;i++)
    {
        test = stackcall(buffer,sizeof(buffer));
    }
    end = [NSDate date];
    g3 = [end timeIntervalSinceDate:start];
    [start release];
    [end release];

    // 1 million calls using inline C++
    start = [NSDate date];
    for(i=0;i<1000000;i++)
    {
        test = inlinecall(buffer,sizeof(buffer));
    }
    end = [NSDate date];
    g4 = [end timeIntervalSinceDate:start];
    [start release];
    [end release];

    [localPool release];
    return 0;
}

0
Eric
5/23/2004 1:39:23 PM
dans l'article BCD661D8.21AD1%eric.vergnaud@wanadoo.fr, Eric VERGNAUD �
eric.vergnaud@wanadoo.fr a �crit le 23/05/04 14:12�:

>>> Say you have a global lock, and a
>>> Locker class that locks a lock in its constructor and unlocks it in its
>>> destructor, with a stack base Locker you can safely throw exceptions within
>>> any scope without worrying about unlocking the lock. Don't tell me you can
>>> do so in the 'finally' statement, there are many cases wher it's simply not
>>> convenient. This is just one example.
>> 
>> That a pretty poor example.  It has almost nothing to do with scope.  It
>> has to do with object deallocation (so, in a way, you *have* asked a GC
>> question).  Cocoa could do the same thing in the scope of any
>> autorelease pool.
> 
> No it has nothing to do with object deallocation. It has to do with
> lifetime. Obj-C is NOT doing the things I need. It doesn't automatically
> call destructors when an object is out of scope. Neither does Java. Only C++
> provides this guarantee without me having to take care of it.

Here is an example:

Class XLocker
{
public:
    XLocker(XLock & inLock);
    ~Xlocker();

protected:
    XLock &  fLock;
};

inline  XLocker::XLocker(XLock & inLock)
: fLock(inLock)
{
    fLock.Lock();
}

XLocker::~XLocker()
{
    fLock.Unlock();
}

XLock gLock; 

void threadsafe_method()
{
    XLocker locker(gLock);

    if(test_something())
        return;
    call_method_which_might_throw_an_exception_not_caught_here();
}

Whatever happens in "test _something" or in
"call_method_which_might_throw_an_exception_not_caught_here", C++ GUARANTEES
that XLocker::~XLocker() WILL be called.

Now if someone can show me the equivalent of the above code in Obj-C, I'm
interested. I don't think it can be as simple.

Eric

0
Eric
5/23/2004 1:52:01 PM
On Sun, 23 May 2004, Eric VERGNAUD wrote:

> Now if someone can show me the equivalent of the above code in Obj-C, I'm
> interested. I don't think it can be as simple.

If only ObjC and C++ exceptions could be cleanly mixed; then you could
have tasty stack objects and tasty full dynamic dispatch together in the
same program via ObjC++. Of course, until ObjC++ gets merged into the
mainstream gcc, you'll either have to compile your own gcc from Apple's
sources (if the ObjC++ code even works on non-Apple systems) or be stuck
only on the Mac.
0
Michael
5/23/2004 5:59:13 PM
dans l'article 20040523135721.J66518@agamemnon.twistedsys.net, Michael Ash �
mike@mikeash.com a �crit le 23/05/04 19:59�:

> On Sun, 23 May 2004, Eric VERGNAUD wrote:
> 
>> Now if someone can show me the equivalent of the above code in Obj-C, I'm
>> interested. I don't think it can be as simple.
> 
> If only ObjC and C++ exceptions could be cleanly mixed; then you could
> have tasty stack objects and tasty full dynamic dispatch together in the
> same program via ObjC++. Of course, until ObjC++ gets merged into the
> mainstream gcc, you'll either have to compile your own gcc from Apple's
> sources (if the ObjC++ code even works on non-Apple systems) or be stuck
> only on the Mac.

Yes or maybe one could add introspection to C++. Combined with the va_list
parameter mechanism, it would provide the functionality (without - I admit -
the security).

Eric

0
Eric
5/23/2004 6:54:57 PM
In article <BCD6762B.21AD6%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> A promised to Doc O'Leary, here is a benchmark to evaluate advantages of
> stack allocation. This benchmark provides 4 equivalent methods to safely
> read a byte from a buffer.

While I appreciate the effort, the task itself seems like something 
easily handled by plain C or even just a macro.  I would not in a 
million years have written code like you've written.  Is this how you 
regularly do development?  If so, I think it's safe to say that C++ is 
the least of your problems.

>  - the send_msg mechanism inherent to Obj-C slows down the loop by a 3.75
> factor.

Poorly written code tends to be slower whatever the language.  Just 
because C++ was faster for you here doesn't mean writing the code as you 
did was a good idea.

>  - a stack object is almost 3 times faster than the heap object. Obj-C does
> not allow stack objects.

Bad conclusion.  Without an ObjC stack object, you can't really compare 
the speed.  It could be that supporting stack objects in ObjC would 
actually be slower.  All you can say is that C++ performance improves 
(for your poorly written benchmark) using the stack.

>  - inlining doubles the performance. I don't think it's possible to inline
> Obj-C calls, is it ?

No.  But, then, an inline isn't really a call.  Can you easily insert a 
block of code using a C macro in ObjC?  Sure.  Can you get a method 
implementation and call it directly to avoid dispatch?  Sure.  Can you 
not worry about any of that, just write a clean program, and *then* 
profile it to change things that really matter?  Absolutely, and I 
highly suggest it.

> The overall result is that C++ code can run as much as 21 times faster than
> Obj-C code.

And the single line of C you should have written instead?  How fast is 
that?

> Now I hope that this benchmark will show to everyone that Obj-C is NOT the
> best language for ALL tasks.

Who said ObjC is best for everything?  The only claim on this thread was 
that C++ is best for everything.  My counter-claim is that C++ is a crap 
OO language.  Nothing you've shown disproves that.  In fact, the more 
code C++ advocates show, the more clear it becomes that C++ has twisted 
far too many minds.
0
Doc
5/23/2004 10:23:56 PM
In article <BCD67921.21AD8%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> >> That a pretty poor example.  It has almost nothing to do with scope.  It
> >> has to do with object deallocation (so, in a way, you *have* asked a GC
> >> question).  Cocoa could do the same thing in the scope of any
> >> autorelease pool.

[ snip ]

> void threadsafe_method()
> {
>     XLocker locker(gLock);
> 
>     if(test_something())
>         return;
>     call_method_which_might_throw_an_exception_not_caught_here();
> }
> 
> Whatever happens in "test _something" or in
> "call_method_which_might_throw_an_exception_not_caught_here", C++ GUARANTEES
> that XLocker::~XLocker() WILL be called.
> 
> Now if someone can show me the equivalent of the above code in Obj-C, I'm
> interested. I don't think it can be as simple.

As I have said, and you have even quoted, what you want is already 
handled by autorelease pools.  Assuming a parity XLocker object (i.e., 
calls lock on init and unlock on release, we have:

void threadsafe_method()
{
   NSAutoreleasePool *pool = [NSAutoreleasePool new];
   XLocker *locker = [XLocker lockerWithLock: gLock];

    if(test_something())
        return;
    call_method_which_might_throw_an_exception_not_caught_here();

   [pool release];
}

Just as I stated earlier, the parent pool will release the local pool in 
the case of an exception, which will unlock gLock.  Hardly complex.
0
Doc
5/23/2004 10:37:04 PM
In article <BCD67921.21AD8%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Now if someone can show me the equivalent of the above code in Obj-C, I'm
> interested. I don't think it can be as simple.

Obj-C now has finally clauses, so it becomes as simple as

- (void)foo
{
   [theLock lock];

   @try
   {
      [someObject someMessageWhichMayThrow];
   }
   @finally
   {
      [theLock unlock];
   }
}

You may argue it is not as simple, but it surely is as effective.

- M
0
Mr
5/23/2004 11:40:22 PM
On Sun, 23 May 2004 14:59:13 -0400, Michael Ash wrote:

> If only ObjC and C++ exceptions could be cleanly mixed; then you could
> have tasty stack objects and tasty full dynamic dispatch together in the
> same program via ObjC++.

Someone ask for Membrane? <http://umbar.com/membrane/>

As explained at
<http://www.helpfultiger.com/helpfultiger/2004/03/knowing_your_bo.html>:

> Membrans allows you to create rules for converting C++ exception types
> to Objective-C NSExceptions and vice versa. It allows you to encapsulate
> objects from one language in another so deallocation is automatic.

Avi

-- 
Avi Drissman                                          avi@drissman.com
+--------------------------------------------------------------------+
                       http://avi.drissman.com/
               Argh! My news server is trunca

0
Avi
5/24/2004 3:16:11 AM
In article <BCD661D8.21AD1%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> >> Since I don't want a Windows app to behave like a Mac app, I won't 
> >> complain
> >> about the death of the Yellow Box.
> > 
> > Pure ignorance.  Ever seen a Yellow Box app?
> Well I've seen iTunes on Windows, and that's enough for me.

Y'know, that's not a Yellow Box app. :)

-Eric

-- 
Eric Albert         ejalbert@cs.stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
5/24/2004 3:24:24 AM
dans l'article droleary.usenet-1D04C2.17235623052004@corp.supernews.com, Doc
O'Leary � droleary.usenet@subsume.com a �crit le 24/05/04 0:23�:

> In article <BCD6762B.21AD6%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> A promised to Doc O'Leary, here is a benchmark to evaluate advantages of
>> stack allocation. This benchmark provides 4 equivalent methods to safely
>> read a byte from a buffer.
> 
> While I appreciate the effort, the task itself seems like something
> easily handled by plain C or even just a macro.  I would not in a
> million years have written code like you've written.  Is this how you
> regularly do development?  If so, I think it's safe to say that C++ is
> the least of your problems.

Wha cares about the task here ? Many simple tasks are delegated to simple
objects in a well designed app. Isn't OOP about encapsulation et reuse ?
Surely, you can insert 1000 lines of C code in the getTheByte method to make
it more ealistic, but t wouldn't be a benchmark anymore.

>>  - the send_msg mechanism inherent to Obj-C slows down the loop by a 3.75
>> factor.
> 
> Poorly written code tends to be slower whatever the language.  Just
> because C++ was faster for you here doesn't mean writing the code as you
> did was a good idea.

You never give up, do you ? What's poorly written in this code ? This is a
simple benchmark, nothing more. My claim was that writing an entire app in
Obj-C would certainly slow it down. This benchmark shows it's true. Why
don't YOU provide a benchmark that shows the opposite ?

>>  - a stack object is almost 3 times faster than the heap object. Obj-C does
>> not allow stack objects.
> 
> Bad conclusion.  Without an ObjC stack object, you can't really compare
> the speed.  It could be that supporting stack objects in ObjC would
> actually be slower.  All you can say is that C++ performance improves
> (for your poorly written benchmark) using the stack.

Read the code, and you'll see that 3 times applies between the heap C++ and
the stack C++ objects.

Are you saying ObjC instances are not in the heap ?
 
>>  - inlining doubles the performance. I don't think it's possible to inline
>> Obj-C calls, is it ?
> 
> No.  But, then, an inline isn't really a call.  Can you easily insert a
> block of code using a C macro in ObjC?  Sure.  Can you get a method
> implementation and call it directly to avoid dispatch?  Sure.  Can you
> not worry about any of that, just write a clean program, and *then*
> profile it to change things that really matter?  Absolutely, and I
> highly suggest it.

Inline makes it possible to optimize OO programming. Isn't OO programming
the reason why you support Obj-C and dislike C++ ?

>> The overall result is that C++ code can run as much as 21 times faster than
>> Obj-C code.
> 
> And the single line of C you should have written instead?  How fast is
> that?

Wouldn't have been OO.

>> Now I hope that this benchmark will show to everyone that Obj-C is NOT the
>> best language for ALL tasks.
> 
> Who said ObjC is best for everything?  The only claim on this thread was
> that C++ is best for everything.  My counter-claim is that C++ is a crap
> OO language.  Nothing you've shown disproves that.  In fact, the more
> code C++ advocates show, the more clear it becomes that C++ has twisted
> far too many minds.

Well OOP has twisted yours. Certainly Objective-C provides features that C++
doesn't have, but since it doesn't provide some that are essential for
performance, you can't use it to write an entire app unless you give up OO
programming.

0
Eric
5/24/2004 7:48:34 AM
dans l'article droleary.usenet-11A92F.17370423052004@corp.supernews.com, Doc
O'Leary � droleary.usenet@subsume.com a �crit le 24/05/04 0:37�:

> In article <BCD67921.21AD8%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>>>> That a pretty poor example.  It has almost nothing to do with scope.  It
>>>> has to do with object deallocation (so, in a way, you *have* asked a GC
>>>> question).  Cocoa could do the same thing in the scope of any
>>>> autorelease pool.
> 
> [ snip ]
> 
>> void threadsafe_method()
>> {
>>     XLocker locker(gLock);
>> 
>>     if(test_something())
>>         return;
>>     call_method_which_might_throw_an_exception_not_caught_here();
>> }
>> 
>> Whatever happens in "test _something" or in
>> "call_method_which_might_throw_an_exception_not_caught_here", C++ GUARANTEES
>> that XLocker::~XLocker() WILL be called.
>> 
>> Now if someone can show me the equivalent of the above code in Obj-C, I'm
>> interested. I don't think it can be as simple.
> 
> As I have said, and you have even quoted, what you want is already
> handled by autorelease pools.  Assuming a parity XLocker object (i.e.,
> calls lock on init and unlock on release, we have:
> 
> void threadsafe_method()
> {
>  NSAutoreleasePool *pool = [NSAutoreleasePool new];
>  XLocker *locker = [XLocker lockerWithLock: gLock];
> 
>   if(test_something())
>       return;
>   call_method_which_might_throw_an_exception_not_caught_here();
> 
>  [pool release];
> }
> 
> Just as I stated earlier, the parent pool will release the local pool in
> the case of an exception, which will unlock gLock.  Hardly complex.

Now THAT is pretty poor code snippet. Let's say I write:

Void parent_method()
{
    NSAutoreleasePool *pool = [NSAutoreleasePool new];

    for(int i=0;i<=1000;i++)
    {
        threadsafe_method();
    }
    
    [pool release];
}

What happens then ?

Do you ever get out of your classroom and fight with REAL situations ?


0
Eric
5/24/2004 7:52:17 AM
dans l'article magoo-4885FE.19402123052004@netnews.comcast.net, Mr. Magoo �
magoo@magoo.com a �crit le 24/05/04 1:40�:

> In article <BCD67921.21AD8%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> Now if someone can show me the equivalent of the above code in Obj-C, I'm
>> interested. I don't think it can be as simple.
> 
> Obj-C now has finally clauses, so it becomes as simple as
> 
> - (void)foo
> {
>  [theLock lock];
> 
>  @try
>  {
>     [someObject someMessageWhichMayThrow];
>  }
>  @finally
>  {
>     [theLock unlock];
>  }
> }
> 
> You may argue it is not as simple, but it surely is as effective.
> 
> - M

As mentioned earlier, there are situations where it's not that simple. As a
matter of fact, you omitted the:

 if(test_something())
    return;

And you're not rethrowing the exception.

This, I believe, shows how necessary it is to provide an "out_of_scope()"
mechanism, for which C++ stack objects are perfect.

Eric

0
Eric
5/24/2004 7:55:42 AM
On Sun, 23 May 2004, Avi Drissman wrote:

> On Sun, 23 May 2004 14:59:13 -0400, Michael Ash wrote:
>
> > If only ObjC and C++ exceptions could be cleanly mixed; then you could
> > have tasty stack objects and tasty full dynamic dispatch together in the
> > same program via ObjC++.
>
> Someone ask for Membrane? <http://umbar.com/membrane/>
>
> As explained at
> <http://www.helpfultiger.com/helpfultiger/2004/03/knowing_your_bo.html>:

I remember hearing about something like this (and it was probably this) a
while ago, but I couldn't find it with Google, thus my post.

It looks interesting, but unless I'm misreading the code it looks
decidedly non-automatic. It would be nice if the code could just look like
this:

try {
	...code that throws C++ or ObjC exceptions
} catch(blah) {
	...deal
}

But it looks like it needs quite a bit of work to build translators and so
on.
0
Michael
5/24/2004 10:17:33 AM
On Mon, 24 May 2004, Eric VERGNAUD wrote:

[snip example using @finally]
>
> As mentioned earlier, there are situations where it's not that simple. As a
> matter of fact, you omitted the:
>
>  if(test_something())
>     return;
>
> And you're not rethrowing the exception.
>
> This, I believe, shows how necessary it is to provide an "out_of_scope()"
> mechanism, for which C++ stack objects are perfect.

Actually, stuff in @finally gets executed no matter how you exit from the
enclosing block, but it otherwise doesn't affect things. Thus, executing a
"return;" inside the @try will still release the lock, and the runtime
automatically "rethrows" the exception. The given code works as intended.
0
Michael
5/24/2004 10:20:38 AM
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Yes or maybe one could add introspection to C++. Combined with the va_list
> parameter mechanism, it would provide the functionality (without - I admit -
> the security).

Not necessary. E.g. in Java you can introspect an object, invoke 
appropriate methods but get an SecurityException if you attempt fiddle 
with protected or private methods from the wrong context.

Regards,
   Tom_E

-- 
This address is valid in its unmodified form but expires soon. 

0
Thomas
5/24/2004 10:34:20 AM
dans l'article 20040524061743.D442@agamemnon.twistedsys.net, Michael Ash �
mike@mikeash.com a �crit le 24/05/04 12:20�:

> On Mon, 24 May 2004, Eric VERGNAUD wrote:
> 
> [snip example using @finally]
>> 
>> As mentioned earlier, there are situations where it's not that simple. As a
>> matter of fact, you omitted the:
>> 
>>  if(test_something())
>>     return;
>> 
>> And you're not rethrowing the exception.
>> 
>> This, I believe, shows how necessary it is to provide an "out_of_scope()"
>> mechanism, for which C++ stack objects are perfect.
> 
> Actually, stuff in @finally gets executed no matter how you exit from the
> enclosing block, but it otherwise doesn't affect things. Thus, executing a
> "return;" inside the @try will still release the lock, and the runtime
> automatically "rethrows" the exception. The given code works as intended.

Thanks for this clarification.

Eric

0
Eric
5/24/2004 11:07:51 AM
J�hnny F�v�r�t� (it means halo, then resonate) wrote:

> Eric VERGNAUD wrote:
> 
>>Stack objects are very useful not only for garbage collection but also
>>for ensuring consistent state of objects, for example locks. Say you
>>have a global lock, and a Locker class that locks a lock in its
>>constructor and unlocks it in its destructor, with a stack base Locker
>>you can safely throw exceptions within any scope without worrying
>>about unlocking the lock.
> 
> 
> i really agree with this one.

Except C++ can't really guarantee this.  What happens if I call 
longjmp(), for example?  Oops, just exited the function without calling 
the destructor; the lock remains locked.

[...]
0
Peter
5/25/2004 12:04:59 AM
Eric VERGNAUD wrote:

> dans l'article BCD661D8.21AD1%eric.vergnaud@wanadoo.fr, Eric VERGNAUD �
> eric.vergnaud@wanadoo.fr a �crit le 23/05/04 14:12 :
> 
> 
>>>>Say you have a global lock, and a
>>>>Locker class that locks a lock in its constructor and unlocks it in its
>>>>destructor, with a stack base Locker you can safely throw exceptions within
>>>>any scope without worrying about unlocking the lock. Don't tell me you can
>>>>do so in the 'finally' statement, there are many cases wher it's simply not
>>>>convenient. This is just one example.
>>>
>>>That a pretty poor example.  It has almost nothing to do with scope.  It
>>>has to do with object deallocation (so, in a way, you *have* asked a GC
>>>question).  Cocoa could do the same thing in the scope of any
>>>autorelease pool.
>>
>>No it has nothing to do with object deallocation. It has to do with
>>lifetime. Obj-C is NOT doing the things I need. It doesn't automatically
>>call destructors when an object is out of scope. Neither does Java. Only C++
>>provides this guarantee without me having to take care of it.
> 
> 
> Here is an example:
> 
> Class XLocker
> {
> public:
>     XLocker(XLock & inLock);
>     ~Xlocker();
> 
> protected:
>     XLock &  fLock;
> };
> 
> inline  XLocker::XLocker(XLock & inLock)
> : fLock(inLock)
> {
>     fLock.Lock();
> }
> 
> XLocker::~XLocker()
> {
>     fLock.Unlock();
> }
> 
> XLock gLock; 
> 
> void threadsafe_method()
> {
>     XLocker locker(gLock);
> 
>     if(test_something())
>         return;
>     call_method_which_might_throw_an_exception_not_caught_here();
> }
> 
> Whatever happens in "test _something" or in
> "call_method_which_might_throw_an_exception_not_caught_here", C++ GUARANTEES
> that XLocker::~XLocker() WILL be called.

This isn't true.  It does not guarantee it if either of those functions 
call longjmp(), for example.

> 
> Now if someone can show me the equivalent of the above code in Obj-C, I'm
> interested. I don't think it can be as simple.

Objective-C can't guarantee it either.  IMO, the proper solution to this 
is to use structured programming techniques: one entry point and one 
exit point per block.
0
Peter
5/25/2004 12:20:16 AM
In article <c8u3g1$970$1@news.apple.com>,
 Peter Ammon <peter_ammon@rocketmail.com> wrote:

> > Whatever happens in "test _something" or in
> > "call_method_which_might_throw_an_exception_not_caught_here", C++ GUARANTEES
> > that XLocker::~XLocker() WILL be called.
> 
> This isn't true.  It does not guarantee it if either of those functions 
> call longjmp(), for example.

That's somewhat of a pointless argument. If you call abort() the stack won't get 
cleaned up, either. The point is that in the default course of events (which can 
be bypassed if you so choose), C++ does the right thing with automatic objects.

> > Now if someone can show me the equivalent of the above code in Obj-C, I'm
> > interested. I don't think it can be as simple.
> 
> Objective-C can't guarantee it either.  IMO, the proper solution to this 
> is to use structured programming techniques: one entry point and one 
> exit point per block.

The fact that you believe that there is such a thing as "the proper solution" 
indicates you have some things to learn.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/25/2004 12:57:03 AM
Peter Ammon wrote:
> Except C++ can't really guarantee this.  What happens if I call
> longjmp(), for example?  Oops, just exited the function without
> calling the destructor; the lock remains locked.

red herring.  there's no technique so good that it can't be screwed up
by someone deliberately trying to.  if you call longjmp(), then you get
what you deserve.
0
ISO
5/25/2004 4:08:16 AM
In article <BCD77651.21B0B%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Now THAT is pretty poor code snippet.

Dude, it's essentially identical to yours with the addition of an 
autorelease pool.  Anything you see that is "poor" is probably written 
by you.  Thanks for the chuckle, though!

> Let's say I write:
> 
> Void parent_method()
> {
>     NSAutoreleasePool *pool = [NSAutoreleasePool new];
> 
>     for(int i=0;i<=1000;i++)
>     {
>         threadsafe_method();
>     }
>     
>     [pool release];
> }
> 
> What happens then ?

How should I know; it's a toy example.  If you have a specific issue, 
why can't you raise it and demonstrate you are thinking?  I assume 
you're trying to make a point about what *could* happen since the scope 
of an autorelease pool is not being tied to the scope of a code block.  
I assume you think that's an unmanageable horror.  That really only 
points to your coding ability, or lack thereof.

> Do you ever get out of your classroom and fight with REAL situations ?

That gets another chuckle, too.  In a real situation, I would not have 
handled locking using "action classes" that are called based on their 
scope.  What you consider REAL is still just twisted world of C++ you 
have decided to surround yourself with.  I submit that *you* are the one 
who needs to get out more.
0
Doc
5/25/2004 4:30:40 AM
On Mon, 24 May 2004, =?ISO-8859-1?Q?J=F8hnny_F=E4v=F2r=EDt=EA_=28it_means_=22halo=2C_then_resonate=22=29?= wrote:

> Peter Ammon wrote:
> > Except C++ can't really guarantee this.  What happens if I call
> > longjmp(), for example?  Oops, just exited the function without
> > calling the destructor; the lock remains locked.
>
> red herring.  there's no technique so good that it can't be screwed up
> by someone deliberately trying to.  if you call longjmp(), then you get
> what you deserve.

Of course, Objective-C exceptions use longjmp() internally, and that is
why I brought them up before in the context of Objective-C++. If you use
ObjC++, or even if you just have C++ code that eventually calls ObjC code
without an intervening exception handler, this is a real problem that you
have to be careful of. You could certainly place the blame for this on
Objective-C, though. On the other hand, throwing a C++ exception will
likewise bypass ObjC constructs, like @finally blocks, and that can cause
similar havoc. I guess the lesson is to be careful when mixing radically
different languages.
0
Michael
5/25/2004 10:15:17 AM
Miro Jurisic wrote:
> In article <c8u3g1$970$1@news.apple.com>,
>  Peter Ammon <peter_ammon@rocketmail.com> wrote:
> 
> 
>>>Whatever happens in "test _something" or in
>>>"call_method_which_might_throw_an_exception_not_caught_here", C++ GUARANTEES
>>>that XLocker::~XLocker() WILL be called.
>>
>>This isn't true.  It does not guarantee it if either of those functions 
>>call longjmp(), for example.
> 
> 
> That's somewhat of a pointless argument. If you call abort() the stack won't get 
> cleaned up, either. The point is that in the default course of events (which can 
> be bypassed if you so choose), C++ does the right thing with automatic objects.

No, the point wasn't about the "default course of events."  It was about 
"whatever happens."  Objective-C, with Cocoa's memory management, cleans 
up objects deterministically in its own version of the "default course 
of events" as well.

> 
> 
>>>Now if someone can show me the equivalent of the above code in Obj-C, I'm
>>>interested. I don't think it can be as simple.
>>
>>Objective-C can't guarantee it either.  IMO, the proper solution to this 
>>is to use structured programming techniques: one entry point and one 
>>exit point per block.
> 
> 
> The fact that you believe that there is such a thing as "the proper solution" 
> indicates you have some things to learn.

I wrote IMO to acknowledge it was my opinion.  Of course others have 
different ideas about how to write safe, maintainable code, with 
tradeoffs present in each technique.

-Peter
0
Peter
5/25/2004 5:32:11 PM
Michael Ash wrote:
> Of course, Objective-C exceptions use longjmp() internally, and that
> is why I brought them up before in the context of Objective-C++. If
> you use ObjC++, or even if you just have C++ code that eventually
> calls ObjC code without an intervening exception handler, this is a
> real problem that you have to be careful of. You could certainly place
> the blame for this on Objective-C, though. On the other hand, throwing
> a C++ exception will likewise bypass ObjC constructs, like @finally
> blocks, and that can cause similar havoc. I guess the lesson is to be
> careful when mixing radically different languages.

you were the guy who had a look at http://www.gotw.ca and decided that
those people must be equating "difficult" with "powerful," right?  in
that particular case, i agree.  i've made several attempts at reading
the guru of the week columns and have yet to see one that i thought was
anything but over-complicated obfustication.  herb sutter recently went
over to "the dark side," and it's no great loss, as far as i'm
concerned.

i feel the same way about exceptions.  they are supposed to ease error
handling, yet in my opinion they make it six or seven times more
difficult.  the benefit, handling errors in one place, or in a different
place than where they're encountered, is completely offset by having to
carefully examine every line of code you ever write anywhere to ensure
that it's exception-safe, or provides one of the two "exception-safe
guarantees," or whatever the current thinking is on the subject.  just
today i read appendix e in stroustrup's "the c++ programming language,"
which concerns standard library exception safety, and it makes my brain
hurt thinking about it.  and that is to say nothing of the difficulty of
handling exceptions thrown by libraries, or what will happen if not all
the code in your project was produced by the same compiler or with the
same compile-time options, or if you use more than one language.

i never use exceptions in c++ or obj-c.  i know that a lot of the stl
containers i use can throw exceptions, and the cocoa frameworks can, but
only in exceptional circumstances, which i am careful not to create.  i
suppose i could also get a bad_alloc if i run out of memory.  i don't
care, i'm not going to write a single try/catch statement.  if i get an
exception, it's free to terminate my programs.  i've got more important
things to worry about.

as long as we're on the subject, there are three major areas of c++ that
i reject as being too complicated and unwieldy: multiple inheritance,
exceptions, and streams.  everything else i've either used or plan to
use, in somebody else's code or in my own.
0
ISO
5/25/2004 10:30:43 PM
In article <PM0003DB474EF2DFA5@minion.nashville.comcast.net>,
 J�hnny F�v�r�t� (it means "halo, then resonate") <this.is@fake.com> wrote:

> as long as we're on the subject, there are three major areas of c++ that
> i reject as being too complicated and unwieldy: multiple inheritance,
> exceptions, and streams.  everything else i've either used or plan to
> use, in somebody else's code or in my own.

I find the idea that template template parameters are OK but exceptions are 
unwieldy pretty amusing.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
5/26/2004 1:53:27 AM
On Tue, 25 May 2004, =?ISO-8859-1?Q?J=F8hnny_F=E4v=F2r=EDt=EA_=28it_means_=22halo=2C_then_resonate=22=29?= wrote:

> Michael Ash wrote:
> > Of course, Objective-C exceptions use longjmp() internally, and that
> > is why I brought them up before in the context of Objective-C++. If
> > you use ObjC++, or even if you just have C++ code that eventually
> > calls ObjC code without an intervening exception handler, this is a
> > real problem that you have to be careful of. You could certainly place
> > the blame for this on Objective-C, though. On the other hand, throwing
> > a C++ exception will likewise bypass ObjC constructs, like @finally
> > blocks, and that can cause similar havoc. I guess the lesson is to be
> > careful when mixing radically different languages.
>
> you were the guy who had a look at http://www.gotw.ca and decided that
> those people must be equating "difficult" with "powerful," right?

Yes, that was me.

> i feel the same way about exceptions.  they are supposed to ease error
> handling, yet in my opinion they make it six or seven times more
> difficult.  the benefit, handling errors in one place, or in a different
> place than where they're encountered, is completely offset by having to
> carefully examine every line of code you ever write anywhere to ensure
> that it's exception-safe, or provides one of the two "exception-safe
> guarantees," or whatever the current thinking is on the subject.  just
> today i read appendix e in stroustrup's "the c++ programming language,"
> which concerns standard library exception safety, and it makes my brain
> hurt thinking about it.  and that is to say nothing of the difficulty of
> handling exceptions thrown by libraries, or what will happen if not all
> the code in your project was produced by the same compiler or with the
> same compile-time options, or if you use more than one language.
>
> i never use exceptions in c++ or obj-c.
[snip]

I agree partially. Most of the time, I don't throw my own exceptions and
don't worry about code being exception-safe. I've never dealt with
exceptions other than in Cocoa, so I can't comment on anything but that,
but Cocoa seems to make it fairly nice. For one, most normally-written
Cocoa code (in terms of line count or whateven) is exception-safe by
default, because of convenience methods and autorelease pools. Second
exceptions get caught and (mostly) ignored by the runloop if you don't
deal with them yourself, and often this is fairly reasonable behavior in
the event that a bug snuck past your testing and threw an exception for a
user.

However, there are certain specialized cases where exception handling is
useful. For complicated routines, it can be easier to throw an exception
and have the caller wrap the invocation in an exception handler than to
return an error and check for it. Another use is for basic recovery in the
face of bad data. If you read a plist, for example, and wrap the code that
uses it in an exception handler, you'll get decent recovery in case
somebody used a string when you were expecting an array, without having to
write a zillion isKindOfClass: checks.

On the other hand, a lot of the complicated exception handling stuff
(dispatching catch blocks based on the class of the exception, etc.) seem
to be overcomplicated, so I do agree with you there.
0
Michael
5/26/2004 8:41:09 PM
In article <BCD4E626.21A69%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Very interesting indeed, but doesn't close the case between supporters of
> strong typing and compile time checking and supporters loose design.
> 
> Eric

Well 125 messages is too much for me to go through, but I'll offer one 
reason why I like Obj-C.

Cocoa is extremely productive for me, and cocoa is written in Obj-C. If 
Cocoa didn't exist I probably wouldn't write shareware. I imagine others 
feel like me; so Cocoa (and hence, Obj-C) increases the amount of 
quality software available for the Mac.

Of course, if Apple has written Cocoa in C++, I'm not sure how that 
would affect my opinion, since I've not learned much C++.

-- 
|\/|  /|  |2  |<
mehaase(at)sas(dot)upenn(dot)edu
0
Mark
5/29/2004 11:01:45 PM
In article <macdev-4EFFD2.04170217052004@senator-bedfellow.mit.edu>,
 Miro Jurisic <macdev@meeroh.org> wrote:

> I therefore conclude that the Objective-C community is comprised 
> mainly of proselytizing wankers with theirs head firmly implanted up 
> their asses. Of course, Objective-C makes the process of getting your 
> head up your ass very efficient. You just have to drag a line from 
> your head to your ass in Interface Builder.

Language wars aside, this statement is a charm. Thanks for making my day!

Van
-- 
Van Bagnol / v b a g n o l at earthlink dot net / c r l at bagnol dot com
....enjoys - Theatre / Windsurfing / Skydiving / Mountain Biking
....feels - "Parang lumalakad ako sa loob ng paniginip"
....thinks - "An Error is Not a Mistake ... Unless You Refuse to Correct It"
0
Van
6/11/2004 8:33:16 PM
Reply:

Similar Artilces:

Looking for Mac Objective-C Programmer with Quartz Knowledge
Hey - looking for an Objective-C programmer who can, basically, make a rip off of PhotoBooth. Send experience, rates/compensation to Programmer@Sitticus.com. lat! M ...

No Mac Help in Mac Help?
When I go to Mac Help in Finder (latest version of OSX Tiger) I get nothing. The window pops up but it's blank. Click on the little house and the initial screen fills in but nothing beyond that. I had a simiar problem with Safari help some time back and someone suggested I remove a folder from Library/Caches, (com.apple.helpui or something similar) and that did the trick for Safari's help. I honestly don't recall if I've ever had the Mac Help or I've just never used it since this machine. The problem happens on or offline so I'm not sure where the Mac Help file re...

Storing C/C++ structures/objects (help needed)
Ok, I want to store my own C++ struct that contains my own C++ classes to the BerkeleyDB. It works wonderful if I do it in, lets say, the main method. I do the whole memcpy stuff like explained here: http://www.cs.sunysb.edu/documentation/BerkeleyDB/ref/am_misc/struct.html Nice, this works so far and at the end of the 'memcpy' stuff I do a Dbt data(&p, sizeof(p)); (p here equals the p in the example) Now, I think p is right because if I un-marshall it right after marshalling it, everything works fine. But I'd like to do that in a different method. With a cursor I run through every key/data pair in the database and I'd like to 'get' what I stored in the data. so I have again u_int8_t *p, data_buffer[1024] and I'd like to copy the data into the data_buffer to unmarshall it (from the concept that's right, isn't it?) what I basically want to do is strcpy(data_buffer, data.get_data()); Where data is Dbt data in a while (pDbCursor->get(&key, &data, DB_NEXT) == 0 - the 'thing' itself works - means, I get the right key value. But I haven't found out how to get the data back into my structure. Help is appreciated. > Ok, I want to store my own C++ struct that contains my own C++ classes > to the BerkeleyDB. It works wonderful if I do it in, lets say, the main > method. You have to properly serialize the object (see the Boost serialization framework for an example). ...

Link C++ object with C object
Hi All, I've compiled a cpp file with g++ without linking it and got an object file. Then I've compiled a C file with gcc and got an object file too. Now if I try to link it to an executable (the main method is in the C object) the linker complains about not finding the symbol for a function declared in the C++ object. Somebody told me that the two compilers use different symbol names for the same function names. He said also it would exist something like a "export this function as C style" keyword but I didn't find anything. Could somebody help me with this? bye! Domin...

[Objective-C++] Objective-C wrappers around C++ classes and KVC
Suppose I have a C++ class named Bar, and an Objective-C wrapper for it called BarWrapper that I use so that BarWrapper has a few KVC-compliant methods (essentially, Bar is the model of something I need to link to an NSArrayController through BarWrapper). Now inside Bar I have a std::vector<Bar*> object, and of course I need to make indexed accessors of the BarWrapper* type. Now, I have two issues, both with the NSArrayController that the BarWrappers are connected to: - the first (and the easier one) is deleting BarWrappers: If I remove a BarWrapper from the master list, I need to remove all the other BarWrappers that refer to the same Bar (then dispose of the Bar, but that's another matter). Should I subclass NSArrayController for that functionality? - the second issue (and maybe connected to the first) is adding them: Bar is non-POD, so BarWrapper contains a pointer to a Bar object. Thus, to make a Bar I need to use new. However, now the issue is that I still need the indexed accessors to return a BarWrapper*. Do I simply look through the NSArrayController's content array and return the appropriate BarWrapper* within, or do I make a second BarWrapper* that points to the same Bar object? -- I am only a mirage. ...

C programmers have a phobia of Java/C++ programmers
its because they know C is inferior and they are at a much lower level. C programmers like heathfield and navia are no match for java/C++ programmers face it, no one wants C programmerss..java /c++ is the in thing broli wrote: > its because they know C is inferior and they are at a much lower > level. > > C programmers like heathfield and navia are no match for java/C++ > programmers > face it, no one wants C programmerss..java /c++ is the in thing Troll Much? I bow to your languages obvious superiority Neil wrote: > broli wrote: >> its because they know C is...

Embedding an Objective-C object in a C structure
Yup, i have a quite perver problem : i would like to embed an Objective-C object within a C structure. The reason is the following: i have an old code base that use a kind of 'object oriented' style in C (stuff quite commons in the 80s and 90s), where an 'object', a kind of plugin for the application, is defined in C by extending a struct, like in: struct { struct basic_object obj; ... new fields .. } I would like to migrate the code base toward Objective-C, but keeping compatibility with the existing stuff. I can of course install a second plugin defin...

Help in this programm in C
Hi.I am started learning Programm language C before some time.I am trying to make a programm about a very simple "sell shop".This programm hasn't got any compile problem but when i run it i face some other ploblems which i can not correct.I would appreciated if someone take a look at my programm so as to help me.I tried many times to find out where my mistakes are but i didn't manage something. I have made some comments due to the programm so as to make it more easy to as. Any recommendations about my writing style in the programm are acceptable. Please help me!!! Programm ...

Help! iSync mac to mac
Am I right in saying that with iSync, if you want to sync 2 macs together (address book, iCal etc.) the only way to do this is via a ..Mac account, even if those computers are sitting not 5 feet from each other, both Airport equipped? If this is the case, I've never heard anything so ridiculous. Is this just part of another apple scam to get more money out of us? Does anyone know if this is indeed the case, and can you recommend any other sync software out there? I'm setting up an iMac, eMac and powerbook g4 for a friend's office, all running OSX Panther, and you'd think basi...

How to Call Objective C Object from C++ code
Hi, guys: i prepare to build UI of program by cocoa. but in order to make a portable program, some low level code sould write in C++. then i must find some way to call Apple Service or Objective C from C++. Could anyone tell me a way to do that. Best Regard. In article <1143784817.800849.152730@t31g2000cwb.googlegroups.com>, "Mopelee" <kingdry_cn@sina.com.cn> wrote: > Hi, guys: > > i prepare to build UI of program by cocoa. > but in order to make a portable program, some low level code sould > write in C++. then i must find some way to call Apple Ser...

c.l.j.programmer vs. c.l.j.help (was: Re: What does this mean??)
Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote on Wed, 02 Nov 2005 14:18:39 GMT in comp.lang.java.programmer: >On Wed, 02 Nov 2005 13:53:56 GMT, "Thomas G. Marshall" ><tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote, quoted >or indirectly quoted someone who said : > >>However, if people here are going to get all pissy about >>toward newbies and where they belong, then I will in their defense get >>equally pissy and point out the descriptions of the newsgroups established >>by the closest thing there ...

Help Help Help Help Help
please,help us . we have a seious problem, we are designing a radio controlled car that is guided by the PC, to send the data wireless between the PC and the Car and vice versa. we use 2 transmitter/reciever circuits from 2 seperate radio controlled car each running with a different frequency (27 MHz & 40 MHz)and modify the functionality of each to do the disered work. but on mounting a transmitter(40MHz) and reciever(27MHz) on the car, and attach another transmitter(27MHz) and reciever(40MHz) to the PC; we found that on sending signals from the car to the PC on the transmitter & rec...

Is the average IQ of C programmers less than that of C++ programmers?
I have a feeling that their EQ will show to be significantly lower. Feel free to post your IQs and EQs! On Tuesday, March 29, 2011 5:19:46 AM UTC+1, MikeP wrote: > I have a feeling that their EQ will show to be significantly lower. Feel > free to post your IQs and EQs! That would make C a better language for commercial purposes, wouldn't it? When I worked as a programmer, the management attitude was that they didn't want clever code; they wanted code that other staff could maintain and develop as easily as its author, especially after he had gone. On that basis, the...

Sending message to Objective-C object from C file
Hi everyone, I am an experienced programmer but quite new in Mac OS programming. I am developing a Cocoa application. I have an old C library files which I want to reuse in this application. Part of that C library file plays an audio file using another Audio library file. I want to replace functionality of that Audio library file with QuickTime. So I have created a Controller Objective-C object that includes QTMovieViewer and can use that to play an audio file. Now my question is how to send message to that Objective-C object from a C file in my old library. Thanks in advance Luca. In article <f8f4sk$dgm$1@news-01.bur.connect.com.au>, "Luca_a" <nojunk@nojunk.com> wrote: > Hi everyone, > > I am an experienced programmer but quite new in Mac OS programming. I am > developing a Cocoa application. I have an old C library files which I want > to reuse in this application. Part of that C library file plays an audio > file using another Audio library file. I want to replace functionality of > that Audio library file with QuickTime. > > So I have created a Controller Objective-C object that includes > QTMovieViewer and can use that to play an audio file. Now my question is how > to send message to that Objective-C object from a C file in my old library. I would say that in general if you find yourself needing to do that, the best place to start is to rethink your design. ...

C++ objects that act like Java/C# objects.
I've had an idea kicking around in my head regarding how to create a library of classes (templates?) that provide the same kind of functionality as do Java classes which all derive from the UBC Object. There is no UBC in C++, nor will there ever be one (well, there actually /is/ a UBC in C++, but it is a pure abstraction). One feature of user defined Java classes is that they all have a member derived from the java.lang.Class object. The Class member object is part of what provides introspection. I haven't looked at this in a couple years, so the details are a bit hazy for me. Ano...

Objectives on C and C++
hello, Can ne one tell me the sites where i can solve/download objective questions on C and C++? I want them for preparing for interviews. rudranee@gmail.com wrote: > hello, > Can ne one tell me the sites where i can solve/download objective > questions on C and C++? > I want them for preparing for interviews. If you are looking for a serious job, concentrate on proper writing. 'i' should be capitalized, and silly abbreviations like 'ne' make you look less than professional. ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http:/...

Objective-C and C++
I'm trying to write the, "Great American MMO" as a way to teach myself Objective-C. I was going to use an open source library to help with the 3D rendering and animation. However, most of them are written in C++, not Objective-C. So I have a couple of questions. 1) Is it more trouble than it is worth to try to get a C++ library working with an Objective-C program? 2) What is a good reference for C++ on the Mac? (I am using the latest version of Xcode and Tiger, if it makes a difference.) Oh, if anyone has a recommendation for an open-source 3D library, I'm interested in that too. -- Joe Claffey | "Make no small plans." indianajoe3@comcast.net | -- Daniel Burnham In article <indianajoe3-0F625F.19544414022006@news.giganews.com>, Indiana Joe <indianajoe3@comcast.net> wrote: > I'm trying to write the, "Great American MMO" as a way to teach myself > Objective-C. I was going to use an open source library to help with the > 3D rendering and animation. However, most of them are written in C++, > not Objective-C. So I have a couple of questions. > > 1) Is it more trouble than it is worth to try to get a C++ library > working with an Objective-C program? It is very easy to get a C++ library working in an objective-C program. You can write a simple C interface that returns opaque pointers to be held ...

C/C++ Help.
This is the closest Newsgroup that looks like it could help me with a C/C++ question, so here goes! I need a way to extract a string from another, larger string. I've tried this, but get compile errors: /* Function: LIST_READ */ int LIST_READ(t_StringType *strInput, t_IntegerType *intFrom, t_IntegerType *intTo) { char *strin = strInput->_value; int *intfrom = intFrom->_value; int *intto = intTo->_value; char *str; strncpy(str,strin+intfrom,intto); return (str); } This is what I get: userdefttcn.c:2121: warning: initialization makes pointer from integer withhout a cast u...

C++ for C programmer
I know C, and i want to learn c++. can someone recommend an on-line source? - I also already know javascript. will that help? Thanks. ~M ---- http://www.NovelTracker.com - top ten novels, ranked hourly. On Mar 13, 10:08 am, marywilliams1...@yahoo.com wrote: > I know C, and i want to learn c++. can someone recommend an on-line > source? - I also already know javascript. will that help? See the FAQ: http://www.parashift.com/c++-faq-lite/how-to-learn-cpp.html I'd suggest you get _Accelerated C++_ by Koenig and Moo. It will teach you the right way from the ground up (and ...

Objective-C Framework help
Hi, Does anyone have an example showing how to create an Cocoa/Objective-C++ app containing a private Objective-C++ framework, both built with CodeWarrior 9? I've been trying to adapt the C++ Framework example from the CW9 reference CD without much success. Cheers -Mark ...

I need a C# programmer to help me out
Here's my deal. I am new to C# but am not new to Java or C/C++, however, I have never programmed for windows apps before. So therefore I am a newbie at what I'm attempting to do. I am attempting to create a windows App with C# with Studio.NET. However, I am looking for someone/something to use as a resource for when I am having troubles or when I just plain don't know what to do or what I'm doing. So if anyone has any suggestions I'd appreciate it. Thanks ...

[Objective-C++] @defs, objective-c classes, and pod types
Can we assume that objective-C classes are C++ pod types when we do something like the following? @interface Foo { //... } //... - (bool) isEqualToFoo:(Foo*) foo; @end class FooWrapper { @defs(Foo) public: // no constructors as we must preserve podness operator Foo*() { return this; } bool operator==(FooWrapper& rhs) { return [this isEqualToFoo:rhs]; } }; -- I am only a mirage. kelvSYC <kelvSYC@no.email.shaw.ca> wrote: > Can we assume that objective-C classes are C++ pod types when we do > something like the following? ObjC classes are just C structs with funny semantics, so they should obey PODness. However.... > @interface Foo { > //... > } > > //... > - (bool) isEqualToFoo:(Foo*) foo; > @end > > class FooWrapper { > @defs(Foo) > > public: > // no constructors as we must preserve podness > operator Foo*() { return this; } > bool operator==(FooWrapper& rhs) { return [this > isEqualToFoo:rhs]; } > }; This is almost certainly a bad idea for other reasons. Objective-C classes really, really, really, really, really like to live on the heap. Here, you're making it live wherever your FooWrapper lives, which is probably going to be on the stack. You'd probably be much better off making FooWrapper wrap a pointer to Foo. That way you don't have to care about PODness, you can writ...

Help finding a C++ programmer
Hello all- Sorry for bothering the user group but I have 2 contract to hire positions that I am having a horrible time trying to fill due to the unique comination of skills required. The client will not budge on any of the skills or years required. If anyone know someone that is looking for employment that has the following, please direct them my way! Any and all help is appreciated! Skills required: At least 4 years of the folowing: Excellent C++, OOA/D, CORBA and SQL knowledge is a must. Must also have extensive experience with system profiling of C++ applications, tuning efforts, and...

Python help for a C++ programmer
I'm writing a text processing program to process some survey results. I'm familiar with C++ and could write it in that, but I thought I'd try out Python. I've got a handle on the file I/O and regular expression processing, but I'm wondering about building my array of classes (I'd probably use a struct in C++ since there are no methods, just data). I want something like (C++ code): struct Response { std::string name; int age; int iData[ 10 ]; std::string sData; }; // Prototype void Process( const std::vector<Response>& ); int main() { ...

Need help of C# programmers
I need a help of C# programmers who are willing to help me with a part of my seminar assignment (well, you should have thick nerves because I'm poor in programming). vlado scratched out in the sand > I need a help of C# programmers who are willing to help me with a part of > my seminar assignment (well, you should have thick nerves because I'm poor > in programming). Then why are you taking a seminar on C#? Take one on something you're better at. You don't see me taking seminars in sub-molecular physics. -- kai www.filesite.org || www.perfectreign.com g3prod...

Web resources about - Why Objective-C? - comp.sys.mac.programmer.help

Objective-C - Wikipedia, the free encyclopedia
.h, .m, .mm Objective-C is a general-purpose , high-level , object-oriented programming language that adds Smalltalk -style messaging to the ...

How-to articles for iPhone development and Objective-C
This question is protected to prevent "thanks!", "me too!", or spam answers by new users. To answer it, you must have earned at least 10 reputation ...

Beginning Objective C for iPad on the iTunes App Store
Get Beginning Objective C on the App Store. See screenshots and ratings, and read customer reviews.

Apple popularity boosts Objective-C language past C++ - Mobile Development, mobile technology, iPhone ...
Tiobe's language usage index now has the Objective-C language used for building iPad and iPhone apps taking third place, knocking C++ to fourth ...

Swift vs. Objective-C: 10 reasons the future favors Swift
... paradigms do. If you're developing apps for mobile devices and you haven't investigated Swift, take note: Swift will not only supplant Objective-C ...

Adobe Rewriting The Wired iPad App... In Objective C
Remember Wireds iPad app? It might still arrive, but rewritten in Objective C.

Programming with Objective-C: Working with Protocols
Describes elements of best practice when writing code with Objective-C using ARC.

Apple's top secret Swift language grew from work to sustain Objective C, which it now aims to replace ...
... on SwiftApple's surprise new programming language unveiled at WWDCstarted development four years ago in conjunction with efforts to keep Objective ...

Objective-C Programming Language
Holen Sie sich „Objective-C Programming Language“ im App Store. Sehen Sie sich Screenshots, Bewertungen und Kundenrezensionen dazu an.

Basic Unit Testing in Objective-C
... option of creating unit tests, which you can use to verify your code without manual intervention. Here's an example... // IntroductionToObjectiveCTests.m ...

Resources last updated: 2/20/2016 11:40:44 AM