Comment Re:The reason for its popularity... (Score 1) 356
Using void pointers is a choice.
As is using ids.
If you're prepared to not use the standard library; and that is impractical.
Anyway... Nazis etc.
Using void pointers is a choice.
As is using ids.
If you're prepared to not use the standard library; and that is impractical.
Anyway... Nazis etc.
Spoken like someone that has never needed to maintain other people's code.
This is actually ~80% of my job, for what it's worth.
You might not write code using these features, but if they're there, you must be able to read and understand them because someone else will use them.
But I do agree. My point was more than a language shouldn't be discounted because it's perceived to have "too many" features.
Both id and void* are part of the language. Both are avoidable. But of course we end up using them if the library uses them.
With Obj-C you end up using id when you use Apple's Foundation library collection classes.
OK, technically the standard library is not Obj-C, but you'll have a pretty hard time not using it for most purposes.
With C++ you are using them with printf. The first parameter is a char*, and then you implicitly have an unlimited number of void* parameters. And if you get the type wrong, they'll only fail at run time.
Technically printf is a variadic function, not one which takes a void pointer. The functions dealing with direct memory access (memset/cpy etc.) use void pointers obviously, but I can't think of any others off the top of my head. Using void pointers is a choice. Random aside: you can write a completely statically type safe printf using variadic templates.
Obj-C for example has categories, which allow you to extend the functionality of a library class - even if you don't have the source for it. C++ can't do that. It can only subclass. Which doesn't help if someone else's code is creating the class in the first place.
C# and Java can do this. Not really sure what you're getting at to be honest...
Not necessarily. id is what makes Obj-C somewhat weakly typed. But C++ has void* which has less type information than id does.
Yes, you can choose to use void pointers and subvert the type system if you so wish. That's a pretty dumb choice though and you deserve everything you get if your programs end up error prone. Obj-C's id type is an integral and unavoidable part of the language. Comparing the two things is a bit silly I think.
For sure, they both smell of the 80s. Obj-C is far from perfect. But it's much nicer than C++.
I think we'll have to agree to disagree. Both languages need to die off, but potential successors should resemble C++ far more than Obj-C.
You treat a pointer to foo as if it's a pointer to unrelated class bar, it'll fail more often at runtime in C++ than in Obj-C.
Of course strongly typed languages can fail at runtime; I'm not suggesting they don't. What I am saying is that having a strong type system makes you more likely to catch the failures at compile time. The hypothetical you've just stated would require an explicit reinterpret_cast to get a foo pointer to point to a bar i.e. you're asking the compiler not to point out your mistake.
What I think you meant is that the C++ compiler will catch more programmer errors at compile time than Obj-C the compiler will. But with the standard Obj-C compiler front end being LLVM now, the reverse is true. LLVM Obj-C compiler will catch far more programmer errors than the standard GCC C++ compiler.
I said it elsewhere, but the compiler can only compensate for the failures of the language -- it can't fix them. When the language allows you to fail exotically at runtime in ways that are statically unpredictable, the compiler is irrelevant. Almost all languages except for the strictest functional ones have these failure modes, but weakly typed languages have them more. Out of interest how would you rank LLVM Obj-C against LLVM C++?
On top of this, Obj-C allows techniques such as introspection that are just not available on C++.
That's not entirely true. Qt (the widget library) is an example of a C++ based code base that does introspection. To be honest though in my career I can only think of a handful of times where introspection has been useful and in most of those cases there were better solutions to the problem that didn't need it.
I'm kind of coming out of this sounding like a C++ apologist; I'm really not. Objective-C is not the answer though. It smells of the 80s.
I'm curious how you explain the meteoric rise of Objective-C then, if it's not down to the proliferation of iOS?
Are you sure this isn't just a matter of taste?
To some extent I guess; it depends how confident you are in your code. At the extreme end of functional programming you can prove that a certain program is correct before you even run it. This is very hard to do with a dynamic language.
It gives it scripting-language agility and introspection with compiled language speeds, and still most of the type checking features are available when you want them, it just doesn't compel them.
C# has reflection whilst being strongly-typed. The two things aren't mutally exclusive.
You sometimes hear this said about Obj-C and it is somewhat true. It's syntax is a little outdated in comparison to some of the more modern languages but other things like the dynamic typing being a big issue are long since history; Objective-C compilers will now give you a lot more compile time information and make these kind of runtime errors largely a thing of the past. Obj-C is far from perfect but it's a much nicer language than the bloated hell that is C++.
Compilers can only compensate for the language's failures, not fix them. Having said that, the 'Analyze' option in Xcode 4 is pretty good.
Language bloat isn't a problem in itself. You are free not to use the features you consider bloat, at no cost. Where it does become a problem is when new language features are shoe-horned with every effort not to break compatibility. The result is obscure new syntax and existing features that should have gone the way of the Dodo. This is where C++11 is, if you ask me.
If you substitute 'uses' for 'requires', the GP is quite correct. It's not like there has been a mass adoption of the language because of the merits of the language itself.
...is obviously because of iOS. More specifically it's because when Steve Jobs rejoined Apple in 1996 he brought with his a lot of NeXTStep tech, including Obj-C. That's why many of the system types have the 'NS' prefix. History lesson aside, it's rather a shame as it's (in my opinion) a rather poor and outdated language. If I'm ever asked by people who aren't familiar with it what it's like I say that it's the anti-sibling to C++. By this I mean that it has the same parentage as C++, but where C++ went down one path, Obj-C took the other. The fact that most well regarded modern languages have more in common with C++ than Obj-C should indicate that they made mistakes in its design. Obj-C's biggest failing is its tendency to fail at runtime rather than during compilation. This is mostly down to its weak type system.
Don't get me wrong, I think C++ is getting pretty creaky too. I'm quite fond of D; in a fantasy world, some big commercial player will start using it and make it popular.
That's basically what I said using more words.
Yep, I have humour.
Can't tell if troll or not. HDMI is a digital interface so cable quality isn't all that important.
In the domain in which it's dominant, the only viable alternative (IMHO) is D and that hasn't achieved critical mass.
With C++0x we have the mutually exclusive aims of nice syntax and new features. The comes a point where maintaining legacy support impinges on the cleanliness of the language to such an extent that it becomes counter-productive. The whole point of a programming language is to express problems in a legible way. The new "enum class" syntax is a good example of how things can go wrong.
It's not C++ itself I have a problem with; it's that improvements to the language are made without breaking legacy support -- no compromise and at any cost. I'm not singling out C++ either; pretty much every language is upgraded in the same way. The difference with C++ is that it's that old and the changes are that great that the syntax additions become plain ridiculous in some cases. It would be better to start with a relatively clean slate and just-do-it-fucking-right.
I like the look of D as a succesor to C++, but unfortunately it doesn't seem to be getting any traction.
The use of money is all the advantage there is to having money. -- B. Franklin
