How different is obj c from c++?

How different is obj c from c++?
http://www.theideallab.com/productiv...m-c-plus-plus/

I knew a lot of these already having written
code in both. The two languages are really
very different. Whereas C++ is C with classes,
Objective C is the intersection of C and the
self (predecessor to smalltalk) language.

Lynn

On 2/22/2012 10:12 AM, Lynn McGuire wrote:
> How different is obj c from c++?
> http://www.theideallab.com/productiv...m-c-plus-plus/
>
>
> I knew a lot of these already having written
> code in both. The two languages are really
> very different. Whereas C++ is C with classes,
> Objective C is the intersection of C and the
> self (predecessor to smalltalk) language.
>

almost, but not exactly:
Self was an experimental successor to Smalltalk (ST was created in the
1970s, Self in the late 1980s). Objective-C was AFAIK more directly
influenced by Smalltalk, and not by Self (also, timing would have made
this problematic as well).

later, however, Self was a notable influence on JavaScript.

in-turn, both (among others, namely Scheme, Common Lisp, Erlang, ...)
were influences on my language-design efforts.


aside:

as mentioned before (here and elsewhere), most of my code is written in
C, but technically, it has more in common with Objective-C than with
"traditional" C, as most of the C code I write is in-fact tool-augmented
to some extent (although I have not gone nearly as far as Objective-C,
and personally find the syntax design used by Objective-C to be "fairly
horrid", not that I necessarily like all aspects of C++ syntax either).

another difference is that I have more typically used a "co-compiler"
strategy (where tools parse source-code and process what they find
relevant, and potentially generate more code), rather than a
preprocessor strategy (more what Obj-C uses).

this means in-effect that all features need to be either representable
in standard C, or can be reduced down to plain (potentially no-op)
macros (some special added keywords and attributes are in-fact no-op
macros). a whole lot more is done with run-time facilities (the object
system and much of the type-system being implemented by the run-time).

in a few cases, I have used special pre-processors though.

sadly, the tools don't mix very well with C++ (can't really parse C++
syntax, ...), so it often leaves it as a choice of "one or the other".
though, some of the tools can be used with a C++ subset (typically
absent namespaces and templates), as they don't try to parse the
contents of included headers (and most don't notice/care about
overloaded functions or operators).


note: this is separate from my scripting language, which is an entirely
separate language (based mostly on JavaScript and ActionScript, with
elements of C, C#, and C++ thrown on), and which runs in a
VM/interpreter, but does depend some on these sorts of tools for its FFI
and similar (for cross-language glue magic). I also considered more
options for VM managed C, but haven't done much with this (because "like
C, just with worse performance" isn't all that compelling).


it is a mystery though how much one can reasonably tool-augment C before
it is really considered a separate language though (vs tool-augmented C
with a bunch of specialized library code).


or such...

On 2/22/2012 4:10 PM, BGB wrote:
> On 2/22/2012 10:12 AM, Lynn McGuire wrote:
>> How different is obj c from c++?
>> http://www.theideallab.com/productiv...m-c-plus-plus/
>>
>>
>> I knew a lot of these already having written
>> code in both. The two languages are really
>> very different. Whereas C++ is C with classes,
>> Objective C is the intersection of C and the
>> self (predecessor to smalltalk) language.
>>
>
> almost, but not exactly:
> Self was an experimental successor to Smalltalk (ST was created in the 1970s, Self in the late 1980s). Objective-C was AFAIK more
> directly influenced by Smalltalk, and not by Self (also, timing would have made this problematic as well).
>
> later, however, Self was a notable influence on JavaScript.
>
> in-turn, both (among others, namely Scheme, Common Lisp, Erlang, ...) were influences on my language-design efforts.
>
>
> aside:
>
> as mentioned before (here and elsewhere), most of my code is written in C, but technically, it has more in common with Objective-C
> than with "traditional" C, as most of the C code I write is in-fact tool-augmented to some extent (although I have not gone nearly as
> far as Objective-C, and personally find the syntax design used by Objective-C to be "fairly horrid", not that I necessarily like all
> aspects of C++ syntax either).
>
> another difference is that I have more typically used a "co-compiler" strategy (where tools parse source-code and process what they
> find relevant, and potentially generate more code), rather than a preprocessor strategy (more what Obj-C uses).
>
> this means in-effect that all features need to be either representable in standard C, or can be reduced down to plain (potentially
> no-op) macros (some special added keywords and attributes are in-fact no-op macros). a whole lot more is done with run-time
> facilities (the object system and much of the type-system being implemented by the run-time).
>
> in a few cases, I have used special pre-processors though.
>
> sadly, the tools don't mix very well with C++ (can't really parse C++ syntax, ...), so it often leaves it as a choice of "one or the
> other". though, some of the tools can be used with a C++ subset (typically absent namespaces and templates), as they don't try to
> parse the contents of included headers (and most don't notice/care about overloaded functions or operators).
>
>
> note: this is separate from my scripting language, which is an entirely separate language (based mostly on JavaScript and
> ActionScript, with elements of C, C#, and C++ thrown on), and which runs in a VM/interpreter, but does depend some on these sorts of
> tools for its FFI and similar (for cross-language glue magic). I also considered more options for VM managed C, but haven't done much
> with this (because "like C, just with worse performance" isn't all that compelling).
>
>
> it is a mystery though how much one can reasonably tool-augment C before it is really considered a separate language though (vs
> tool-augmented C with a bunch of specialized library code).
>
>
> or such...

Interesting. I thought smalltalk was a successor
to self. I did not know it was the opposite.
http://en.wikipedia.org/wiki/Self_%2...ng_language%29

Lynn

Lynn McGuire <lmc@winsim.com> wrote:
> How different is obj c from c++?
> http://www.theideallab.com/productiv...m-c-plus-plus/

That article concentrates mostly on minutia and skips the most *important*
differences between the two languages.

Where Objective-C shines:

- Objective-C has full runtime introspection and reflection.
For example, you can take an anonymous object (ie. an object from
which you know *absolutely nothing*, ie. you don't have any kind of
class declaration) and check if it, for example, has a method with
a certain signature, and then call that method if that's so. (C++
has basically zero support for this.) You can likewise determine at
runtime if an object is of a certain type or derived from it (similar
to C++'s dynamic_cast), is exactly of a certain type, implements a
certain interface, or contains a certain member variable.

- As a consequence of the above, you can call a method (well,
technically speaking "send a message") whose signature has been
created at runtime (ie. was not determined at compile time).
(In principle it could be possible, for example, to have a class
definition as a text file which is parsed and interpreted at runtime.)
Yet calling Objective-C methods is suprisingly efficient (constructing
a selector eg. from a string is not efficient, but once you have the
selector, sending it to an object is surprisingly efficient).
According to my tests calling an Objective-C method is only about
6 times slower than calling a raw C function, which is impressive
considering the amount of dynamicity involved.

- Likewise because of the above you can create an object of the same
type as another object, without having to know what that type actually
is (iow. even if you have a completely anonymous object). In C++ you have
to know an object's exact type in order to create another one of the same.

- "Method pointers" are much easier and versatile in Objective-C than
in C++. (Basically, a "method pointer" doesn't need to know which class
it's for, and in fact the same method can be called using such a "pointer"
for completely unrelated classes. This alongside anonymous object pointers
makes it quite versatile and useful. All this is because you are not,
technically speaking, handling a "pointer" but a "message", and the
signature of this "message" is not dependent on any class.)

Where Objective-C sucks:

- No RAII. Enough said.
(On the Mac OS X platform you can use a limited form of garbage collection
that takes care of eventually freeing objects. However, this feature is not
available on all platforms, eg. on the iPhone. Regardless, RAII is useful
for more than just memory management.)

- No constructors.
(There are "constructors" in Objective-C classes, but they are a meta
convention, not something imposed or handled by the language itself.
These constructors do not get automatically called, like in C++, but have
to be called explicitly, and there's no way to ensure that a certain
constructor is called when the object is created. This can be annoying
when creating a derived class, because there's simply no way of creating
a constructor for it that will surely be called when the object is
created.)

- There kind of is a destructor that always gets called, but even then
it's really also a meta convention rather than a language feature. (It gets
called because all objects are/should be derived from a common base class
NSObject which calls this "destructor" when its reference counter gets to
zero, or when the garbage collector wants to free it. However, the lack of
automation can be seen in that in your destructor implementation you have
to manually call the destructor of the superclass. If you don't, you have
probably a leak.)

- Because of all the above, and because objects cannot be handled by
value, C++-style "smart pointers" which would handle reference counting
of objects automatically are just not possible.

- No private methods.
(Methods can be "private by convention" in that they do not have to be
declared alongside the class declaration. However, nothing stops something
from calling this "private" method by simply sending the object the message
with the proper signature.)

- No abstract classes. (In C++ parlance this means that there's no support
for pure virtual functions, ie. classes that cannot be instantiated directly
but have to be specialized.)

- No inner classes or types. Everything goes to the global namespace.

- No templates or "generics" of any kind. (Generic object data containers
are possible, but they can only contain anonymous pointers, which means that
you always have to downcast. Obviously it's not possible to have generic
data containers for basic types.)

- No way of calling the "super super" class from a method. (It's a question
of discussion whether this is a good or a bad thing. I consider it a bad
thing.)

- (Lack of multiple inheritance was already mentioned in the article.)

On Thu, 2012-02-23, Juha Nieminen wrote:
> Lynn McGuire <lmc@winsim.com> wrote:
>> How different is obj c from c++?
>> http://www.theideallab.com/productiv...m-c-plus-plus/
>
> That article concentrates mostly on minutia and skips the most *important*
> differences between the two languages.

That was the impression I got, too (even though I don't know objc).

> Where Objective-C shines:
[big snip]
> Where Objective-C sucks:
[big snip]

Yet again, Usenet beats blogs! Thanks.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Juha Nieminen <nospam@thanks.invalid> wrote:
> - No abstract classes. (In C++ parlance this means that there's no support
> for pure virtual functions, ie. classes that cannot be instantiated directly
> but have to be specialized.)

But there are (formal) protocols. Protocols are similar to interfaces in
Java or classes with only pure virtual methods in C++. A class that
implements a protocol must implement all methods/selectors in that
protocol.

But Obj-C is quite flexible in how you can use such a protocol:
id <Protocol1, Protocol2> myVariable;
declares a variable of type id (which is Obj-Cs void* for Objects IIRC)
which implements the two Protocols "Protocol1" and "Protocol2".

Tobi

Am 23.02.2012 12:21, schrieb Juha Nieminen:
>
> Where Objective-C sucks:
>
> - No RAII. Enough said.
> (On the Mac OS X platform you can use a limited form of garbage collection
> that takes care of eventually freeing objects. However, this feature is not
> available on all platforms, eg. on the iPhone. Regardless, RAII is useful
> for more than just memory management.)

With Objective-C++ you can have the best of both worlds (to some extent).

> - No inner classes or types. Everything goes to the global namespace.

That's where it really sucks.

I once worked in a company that make printer drivers for large
postscript printers. The printer driver GUI (printer setup dialog) was
cross platform - windows and mac osx. The GUI used wxWidgets to achieve
this. wxWidgets used to use the carbon API on mac - until 10.6 snow
leopard came along and required all printer driver plugins to use cocoa
and therefore Objective-C. And that's where the problems started.
Switching wxWidgets from the proven carbon port to the experimental
cocoa port was comparatively easy (I submitted a bunch of bugs to the
wxWidgets bug tracker...), but the printer driver plugin is a "bundle"
that dynamically gets loaded into the application that wants to print.

Now, if the application is already using cocoa wxWidgets, there are name
clashes as soon as the plugin's wxWidgets Objective-C classes are
loaded, because there is only one flat global namespace for Objective-C
classes. Fortunately, wxWidgets provided a hack that enabled us to set a
prefix to rename all of the wxWidgets classes at once. But the next
problem I encountered was when there were multiple printers, and the
application loaded other printer plugins at the same time. The plugins
are very likely to use the same names, because they all have to
implement the same plugin interface. That's when we started to name our
classes com.company.printermodel.version.blah...

The other thing that turned out to be fiddly was to properly implement
plugin unloading. I think I remember it just seemed impossible, and I
gave up trying.


Peter

Tobias Müller <troplin@bluewin.ch> wrote:
> Juha Nieminen <nospam@thanks.invalid> wrote:
>> - No abstract classes. (In C++ parlance this means that there's no support
>> for pure virtual functions, ie. classes that cannot be instantiated directly
>> but have to be specialized.)
>
> But there are (formal) protocols. Protocols are similar to interfaces in
> Java or classes with only pure virtual methods in C++. A class that
> implements a protocol must implement all methods/selectors in that
> protocol.

Which is not the same as an abstract class because a protocol cannot
have member variables nor function implementations.

Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> wrote:
> Am 23.02.2012 12:21, schrieb Juha Nieminen:
>>
>> Where Objective-C sucks:
>>
>> - No RAII. Enough said.
>> (On the Mac OS X platform you can use a limited form of garbage collection
>> that takes care of eventually freeing objects. However, this feature is not
>> available on all platforms, eg. on the iPhone. Regardless, RAII is useful
>> for more than just memory management.)
>
> With Objective-C++ you can have the best of both worlds (to some extent).

To some extent, yes. When I develop for the iPhone I always use
Objective-C++ and have my own smart pointer to handle the reference
counting of Objective-C objects automatically and use it whenever it's
possible and feasible. (Thankfully Apple extended Objective-C++ so that
Objective-C classes can have C++ objects as members, as long as they have
a default constructor. This makes life a lot easier in many cases.)

However, there are many situations where a C++ smart pointer cannot
be used. One example is when using Interface Builder to create your UI.
It doesn't understand Objective-C++, so you have to use Objective-C
properties instead (which in turn need synthesizers and manual releases
in a manually-written deallocator; you can minimize the tediousness and
verbosity of this by using some cleverly made preprocessor macros, but
only to a limited extent).

On 22 Feb., 18:12, Lynn McGuire <l...@winsim.com> wrote:
> How different is obj c from c++?

Objective C adds object-orientation to C. At least, that is what
wikipedia says: "Objective C […]
adds Smalltalk-style messaging to the C programming language".
Although Objective C is considered a real programming language, the
additional functionality of Objective C over plain C is only marginal.
One could quite easily implement Objective C as a simple library in C
(like Microsoft's COM, where reflection is added to COM CoClasses
through the IDispatch interface).

The real difference between the two compilers thus boils down to the
differences between C and C++. These are widely known: The major
enhancements of C++ are template (meta-) programming and exceptions
(stack-unwinding).

And even that doesn't mean much since one simply has to rename the
source file from ".m" to ".mm" and can use C++ and Objective C at the
same time: Objective-C++.

Regards,
Stuart



> * *http://www.theideallab.com/productiv...-different-is-...

Not worth reading.

Stuart Redmann <DerTopper@web.de> wrote:
> One could quite easily implement [language] as a simple library in C

Could people please stop arguing that? It's idiotic. Seems that whenever
someone compares any language in the universe to C, someone will argue
that the same things can be implemented in C.

Sure, you could probably implement something vaguely resembling runtime
introspection, reflection, compiler-generated properties (which can be
atomic, non-atomic, retaining, non-retaining, etc), inheritance, protocols,
messages, selectors, code blocks, exceptions (and try/catch blocks), public,
protected and private sections of classes, range-based loops, and so on,
but it would be neither simple (to either implement or use) nor very
efficient. (For instance, selectors would need to be strings rather than
being constructs that the compiler itself understands. These strings require
parsing and interpretation at runtime rather than being convertible to an
internal, efficient format at compile time, like an Objective-C compiler
does.)

Stuart Redmann wrote:
> > One could quite easily implement [language] as a simple library in C

Juha Nieminen wrote:
> Could people please stop arguing that? It's idiotic. Seems that whenever
> someone compares any language in the universe to C, someone will argue
> that the same things can be implemented in C.


I think I makes quite a difference whether something is an inherent
feature of the compiler or is simply a library. This way we can
distinguish between powerful languages (like C++, Ada95) and powerful
libraries (Java, C#), at least if we restrict the comparison to
imperative languages. The "objectiveness" of Objective C adds very
little to C in comparison to C++. I would even go so far to say that
building an Objective C compiler is a nice task for a diploma thesis.


> * Sure, you could probably implement something vaguely resembling runtime
> introspection, reflection, compiler-generated properties (which can be
> atomic, non-atomic, retaining, non-retaining, etc), inheritance, protocols,
> messages, selectors,

Should be easy to implement.

> code blocks,

Those would be a bit tricky, I guess.

> exceptions (and try/catch blocks),

Since Objective C does no stack unwinding, this should be easy as
well.


> public,
> protected and private sections of classes, range-based loops, and so on,
> but it would be neither simple (to either implement

I disagree, but are open to well-founded arguments.

> or use) nor very
> efficient. (For instance, selectors would need to be strings rather than
> being constructs that the compiler itself understands. These strings require
> parsing and interpretation at runtime rather than being convertible to an
> internal, efficient format at compile time, like an Objective-C compiler
> does.)

Efficiency was not on my mind here, though this a good point. However,
if the parsing of selector names were the only feature that made
Objective C a programming language rather than a library, this would
be a very poor language.

Stuart

Am 29.02.2012 08:54, schrieb Juha Nieminen:
> Stuart Redmann <DerTopper@web.de> wrote:
>> One could quite easily implement [language] as a simple library in C
>
> Could people please stop arguing that? It's idiotic. Seems that whenever
> someone compares any language in the universe to C, someone will argue
> that the same things can be implemented in C.
>
> Sure, you could probably implement something vaguely resembling runtime
> introspection, reflection, compiler-generated properties (which can be
> atomic, non-atomic, retaining, non-retaining, etc), inheritance, protocols,
> messages, selectors, code blocks, exceptions (and try/catch blocks), public,
> protected and private sections of classes, range-based loops, and so on,
> but it would be neither simple (to either implement or use) nor very
> efficient. (For instance, selectors would need to be strings rather than
> being constructs that the compiler itself understands. These strings require
> parsing and interpretation at runtime
That's exactly what Qt does when you call QMetaObject::invokeMethod(). I
was amazed by the complex machinery behind this function...

> rather than being convertible to an
> internal, efficient format at compile time, like an Objective-C compiler
> does.)


Peter

Juha Nieminen <nospam@thanks.invalid> wrote:
> Stuart Redmann <DerTopper@web.de> wrote:
> > One could quite easily implement [language] as a simple library in C

> Could people please stop arguing that? It's idiotic. Seems that whenever
> someone compares any language in the universe to C, someone will argue
> that the same things can be implemented in C.

To be fair, they usually are implemented in C. Just not in the way you're
thinking.

On 2/29/2012 3:54 PM, William Ahern wrote:
> Juha Nieminen<nospam@thanks.invalid> wrote:
>> Stuart Redmann<DerTopper@web.de> wrote:
>>> One could quite easily implement [language] as a simple library in C
>
>> Could people please stop arguing that? It's idiotic. Seems that whenever
>> someone compares any language in the universe to C, someone will argue
>> that the same things can be implemented in C.
>
> To be fair, they usually are implemented in C. Just not in the way you're
> thinking.
>

one can implement both Scheme and JavaScript as library functionality in
C...

nevermind if a dedicated parser, bytecode compiler, interpreter, and
maybe a JIT compiler, is involved...

one can use a lot of the functionality directly from C as well, but
granted it is not as nice or necessarily as efficient as it could be.
say, if the VM's FFI also doubles as a dynamic reflection mechanism.

....