Slashdot Mirror
Objective-C Overtakes C++, But C Is Number One
mikejuk writes "Although the TIOBE Index has its shortcomings, the finding that Objective-C has overtaken C++ is reiterated in the open source Transparent Language Popularity Index. The reason is, of course, that Objective-C is the language you have to use to create iOS applications — and as iPads and iPhones have risen in popularity, so has Objective-C. If you look at the raw charts then you can see that C++ has been in decline since about 2005 and Objective-C has shot up to overtake it with amazing growth. But the two charts are on different scales: if you plot both on the same chart, you can see that rather than rocketing up, Objective-C has just crawled its way past, and it is as much to do with the decline of C++. It simply hasn't reached the popularity of C++ in its heyday before 2005. However the real story is that C, a raw machine independent assembler-like language, with no pretense to be object oriented or sophisticated, has beaten all three of the object oriented heavy weights — Java, C++ and Objective C. Yes C is number one (and a close second in the transparent index)."
But that's just my opinion.
sorry but html and javascript is the future.. it must be true because all the kids just out of college say so.
However the real story is that C, a raw machine independent assembler-like language, with no pretense to be object oriented or sophisticated, has beaten all three of the object oriented heavy weights
This sounds like it was written by someone who doesn't understand C. You can write object orientated code in C. You don't always need the language to hold your hand. And C is NOT assembler-like language. Not even close.
And as far as sophisticated code, I guess the author doesn't consider operating systems or most system programming to be sophisticated.
As a (very) amateur programmer, ok, script kiddie. I can't pretend to truly understand this, but what I can say is that the idea of object oriented vs. non object oriented languages has always thrown me off.
Now, I understand that the idea is an object can have several different types of variables as attributes, and can be created dynamically, but I've never seen any text that can give any up front idea of (You can do this in OO/You cannot otherwise) that would sell me on programming that way. Yes, thats not what languages are about, different ones are best for different domains, and so forth, but really slashdot, what is the big draw to OO? The killer feature?
Pointers?
Sincerely,
AC
From the Made-it-to-chapter-16-of-all-of-these-at-some-point-but-no-further-dept.
I count about 100 more possible headlines of the form "A overtakes B". Must we see them all here?
C's philosophy doesn't integrate well with Ayn Rand's.
There's no -1 for "I don't get it."
You can write reusable functional code in any language .... but you CAN'T write object oriented with it.
Java's apparent decline seems to be because of the financial slump. Where the number of new enterprise projects using Java has reduced. Most of this work was deferred and is starting to pick up again (at least as far as I can see). Some of the apparent 'decline' in languages is due to the introduction of new languages. The absolute number of projects using any language may be increasing but with new languages being introduced the proportion for any one language becomes diluted.
That said, C deserves to be right up there because it is still completely relevant as a 'lingua franca' (common language) for talking to hardware or operating systems. It also has the same benefits of Java in that the language is small and the convention is to place complexity in the libraries rather than as arbitrarily added keywords. This is not very exciting for many Slashdotters but for regular joes it allows them to get things done while working on huge, long-term projects (where the set of staff that start the project aren't necessarily those that finish it) where being able to follow other people's code is critical. This doesn't make for good press or excitement in the blogosphere or conference circuit but these two stalwarts pretty much let you solve any problem in any computing environment (portability matters!).
"Objective-C is the language you have to use to create iOS applications"
There are plenty of games and other iOS applications that are written in C and C++.
Yes, there is a little bit of "glue" code required for interaction with Apple APIs, but the implication here is that you can't use another language write the majority of an iOS Application, which is wrong.
What they don't tell you is C++ (NDK) is used in Most Android games or else it will be slow as hell. Google doesn't want to tell you that because they want you to use Java. Of course C,C++, Objective C > Java.
C is hardly in demand at all in the job market compared to other languages if you check monster.com and dice. I am not saying it is not important as operating systems tend to be written in it, but most demand is not to write operating systems or do very low level things.
Java was tops the last time I looked followed by C#.net, with php third but I would not be surprised if .NET overcame Java and php is becoming more and more popular.
Any other measure of importance is subjective and biased as every nerd has his opinion on why his tastes are better. But job openings and demand truly show what the market wants and is willing to pay which equals value/importance. Fact is I saw only one C programming position advertised in the last 7 years. .
http://saveie6.com/
As much as I like languages like Perl and Java, where memory is managed for you (kind of), there will always be a great need for languages that brings programmers as close as necessary to the workings of the machine itself.
What? What idiot posted that garbage? Oh, timothy...
Understood.
Here's a crazy brief explanation:
The big draw to OO is that it (ostensibly) makes it easier and/or faster to write applications. This doesn't mean that you can make programs with an OO language that you couldn't with an imperative or structured language, only that certain tasks may be easier to implement.
That said, OO isn't always the best option. OO languages are typically a lot more complex and produce slower executables than plain C, so there is a trade-off that can be important in certain situations. As with anything, pick the best tool for the job.
For myself, when I first learned programming (via some books), I learned C before moving to C++. I absolutely hated C++ and didn't see the point of OO programming, due in large part because of the way the book presented it. At the start, the author had you write a C program, and throughout the course of the book, you would change it into a C++ program full of OO goodness. The final C++ program wound up having 50% more lines of code for the exact same functionality, and that was the point where I gave up on it. It was a pretty bad first impression.
So maybe you're reading from the wrong book?
If you can't convince them, convict them.
1) The one stated in the summary - the C++ vs. Objective C graph is on a very small Y axis that exaggerates the differences.
2) They've included Javascript, apparently in it's seldom-used server-side form, to intimate its popularity is going down (AFAICT they don't bother to mention this differentiation).
3) In their 2011 vs 2012 table, they indicate a language's change in table rank using arrows - one point in change equals one arrow. Visually that makes it look like some languages (e.g. Visual Basic .NET) are exploding when in reality it's just that lesser-used languages need smaller increases in usage to make it look like they're taking off. VB .NET is in 15th place - the language in 10th place, Ruby, only has 1.77% penetration.
#DeleteChrome
I have to wonder if the world is ready to move back to a simpler time. So much of programming these days involves building "infrastructure" with all the industry approved buzzwords (factories, patterns, aspects, reuse, blah, blah, blah); sometimes it's better to just bang out the application and move on.
I don't get it. If you try searching for jobs programming in C, you'll find that almost everything that matches the search is Objective C, C++, or C# (or, on some poorly run job sites,a C++ or C# job where the punctuation got lost and it's displayed as C). Sometimes a job will say C/C++. C is rare as hen's teeth except for embedded development and there aren't *that* many jobs in embedded development.
I just went to monster.com and searched for C. What I found starting at the top was:
-- C++ job that lost the punctuation
-- Objective-C
-- C# job that lost the punctuation
-- C/C++
-- Objective-C
-- C/C++, C#
-- C/C++
-- Objective-C
etc. The first C job was item 14 (and is embedded). The next C job, ignoring the false hits on such things as A B C, was item 24 (also embedded), and C wasn't the main skill required. So how in the world can C be number one?
Objects simply allow for an efficient programming structure for large software. That's the main reason. The real debate is about how far this object orientation should go. There are people like me that are of the opinion: use objects when necessary for structure. Others on the other hand will wrap anything in layers of objects. Dynamic allocation isn't strictly necessary for object support (see C++ to know why). It's just that most object oriented languages now also want to use polymorphism, at that point dynamic allocation is necessary cause it's near impossible for the compiler to predict what'll happen. But it's a rather pointless debate in the long run. To each his own as they say.
It's like the static vs dynamic linking debate that you sometimes hear. There's no real valid answer to that one either, it's a best guess on what'll lead to the best performance. With dynamic linking you don't need to load all the libraries at the start, on the other hand with static linking you don't need to call up the linker each time a library is loaded, and so on... My main advice: stay out of it. There's no real valid answer to these sort of things.
Wherefore art thou Dennis Ritchie?
Ummm, Jon, aren't you supposed to be dead...? - Otter(3800)
Power and syntax of C, safety of C++, useful compiler errors like Java. NO HEADER FILES!!!
Come to the C-side
C you Soon
C is number one...hundred, in Roman numerals, that is. Hence the popularity, it's the Benjamin Franklin of programming languages, and as we all know, it's all about the Benjamins!
#include <stdio.h>
int main()
{
printf( "suck my wind, bitches.\n" );
return 0;
}
- from "The C Programming Language", 2012 edition
Shame D is moving so slowly.
Say you're coding a graphical interface and you want two buttons for okay and cancel. They both need to be blue. The toolkit yours using will have an object called Button that has the basic characteristics of what a button its, e.g., a clickable icon that does something. You sub class this Button and give it the specifics.
Button okay = new Button;
Button cancel = new Button;
You now have two objects of type Button. Next you get specific.
okay.onClick(proceed());
cancel.onClick(abort());
okay.color("00f");
cancel.color("00f");
This is terrible pseudocode butyou get the idea. instead of having to code buttons from scratch, you sub class them and only add what you need. typing on a tablet so I hope I haven't been unclear.
The soylentnews experiment has been a dismal failure.
My guess is that C, besides being a good low-level language, is popular because it is the most portable.
C code runs on any platform, the first thing people do when they make a new platform is create a C compiler. If your library is written in C, then you can write bindings for it from practically any language. Then the Ruby guys can be just as happy as the Java guys.
Probably more importantly, recently, if you want to write an app for both iPhone and Android, you can just code the backend in C, and all you have to do is create a GUI on top for each platform. You can't even write standard Java on either platform.
"First they came for the slanderers and i said nothing."
All languages come with compromises, and it's still a matter of selecting the one that gets a particular task done in an optimal manner given all the parameters of getting the specific task done with whatever compromises are allowed, the skills available, using the program, and maintaining it going forward.
And that's not something to be settled by a popularity contest.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
If you are looking for an imperative language that is flexible and lets you treat memory as memory, then C is the best language out there.
If you're looking for a language that abstracts all those computer bits out, and makes your job as easy as possible, you might want Ruby, C#, Prolog, or something else. But C lets you get a good feel for what your code is actually doing on the computer.
"First they came for the slanderers and i said nothing."
deal with it.
retvalue = [object methodname]; // YUCK YUCK YUCK
K&R (also known as the bible) is only a couple of hundred pages long. C is a simple language. You can read C code and not have to worry about strange gotchas. C++, on the other hand, not so much ... you can never be sure someone hasn't overloaded something beyond recognition. The rules of other languages are also way complicated and make it hard to understand what's going on.
You can write more concise code with other languages but the plethora of rules means that you will have more trouble understanding that code. Anyway, you can totally write fully structured code in C and that takes away many of the supposed advantages of other languages.
The only major language that is clearly better than C, in the clarity and simplicity department, is Python. The code is easy to read and doesn't have a lot of complex rules that will cause confusion.
So Java is used by the financial institutions and we know that the whole finance industry is evil and crooked. That makes Java the tool of the evil crooks and therefore Java is evil and crooked by association.
After all, it's always taking memory that I've allocated by my hard work and saying that it's for my "convenience".
And Java is now an Oracle product, too.
Evil++
Who says it has overtaken anything? For who? Where I code, we all use good 'ol C++. No matter how many times we tried to adopt Obj-C it just failed. Unless we wanted to write an iPad/iPhone app. Is this actually posted by an Apple shill? That would make more sense to me.
I have never found a non-Apple task that works better in Obj-C than a C/C++ setup.
If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
This survey is skewed by iOS developers trowelling out tons of appstore apps of questionable utility.
Kriston
See, now this is you troll! You even got a few takers. You should teach a thing or two to the Ron Paul troll above. Psshh, amateurs.
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
I am not really a programmer and certainly not a software engineer so I have no input on what people SHOULD do, but as a person who reads and compiles and occasionally even successfully fixes code (occasionally but not usually fixing others' mistakes, mostly accounting for changes in libraries and such) I find it confusing when code is a combination of object-oriented and not. If I have to remember when I need to do something one way or the other I often seem to have a problem with that. It's valid criticism that there may be something wrong with my brain ;) but it seems to me like it makes more sense to pick a method and stick with it.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Monster.com shows Objective-C tying with FORTRAN for a very small number of jobs: 5, in the entire Denver job market.
Not something I am going to base any career decision on for now.
Mikejuk obviously has no experience programming in assembler and/or C. Not all languages that are not "object oriented" are raw or assembler languages.
C is a simple, well defined language that allows almost any program to be written - look at its ubiquity and persistent popularity for writing a very wide range of programs. It is far removed from the hardware details that assembler languages deal with (CPU registers and instruction sets, in particular). Where it not so, C programs wouldn't enjoy the high degree of portability that they do.
It is hard to guess what Mikejuk imagines a "sophisticated" language to be. Perhaps one that wears tuxedos, drinks martinis with the upper crust at swish affairs and puts on posh manners and accents to impress the debutantes? Or is she just trying to say that C isn't complicated, in a sophisticated manner? In which case, it's a feature, not a fault.
Since when?
Say you're coding a graphical interface and you want two buttons for okay and cancel. They both need to be blue. The toolkit yours using will have an object called Button that has the basic characteristics of what a button its, e.g., a clickable icon that does something. You sub class this Button and give it the specifics.
Button okay = new Button;
Button cancel = new Button;
You now have two objects of type Button. Next you get specific.
okay.onClick(proceed());
cancel.onClick(abort());
okay.color("00f");
cancel.color("00f");
This is terrible pseudocode butyou get the idea. instead of having to code buttons from scratch, you sub class them and only add what you need. typing on a tablet so I hope I haven't been unclear.
OK:
typedef struct button {
long long color[3];
void (*onClick)(int);
} Button;
Button okay;
Button cancel;
okay.onClick =
cancel.onClick =
okay.color[2] = 0xffffffff;
cancel.color[2] = 0xffffffff;
The C version is probably smaller and faster than your version.
Have you ever heard of librarys?: code re-use began long before OOP and the converse of OOP is not "coded from scratch".
Well, that was embarrassing. Wait, no.
I intended this to be a challenge.
Fill in the blanks.
Stupid slash code.
Arguably, the new 2011 standard could push C++ back to number 1, as it addresses a lot of the usual weaknesses of C++ (better memory management, type inference, threading, etc.). But I suppose it depends on how many people are willing to learn and code to the new standard.
Heh. If you want to get fancy, I could chain mine together into a one liner. I was just showing the guy one purpose for OOC. personally, I use object oriented code only when really necessary usually for some kind of persistence otherwise I'm with you.
The soylentnews experiment has been a dismal failure.
Well, it IS a machine-independent assembly-like language. Use the -S or 'save temps' switch on GCC, and see the ASM code it generates. Don't forget your -O2 or -O3 switch, otherwise the code is really bad.
What is a struct if not an object in the philosophical sense?
It's not about political correctness. It's about mentioning this "god" fantasy thing and talking about USA politics in a thread about computer languages.
Please, please, slashdotters, please stop these tiobe index horserace stories.
I'm begging you, they are so damn foolish, they bother me enough to post about it.
Keyword count on the www pages is not a precuse measure of real world usage. And looking at day to day changes in such an index is extracting data from noise.
I'm guessing this was because the authors were exhibiting uselessly "object-oriented" toy programs to illustrate language features. You'd probably have had a different first impression if you'd started with Cocoa and Objective-C. While it hadn't been updated in years and consequently seems to have disappeared down the memory hole, one of Apple's old Cocoa tutorials was something to the effect of "Build a Text Editor in 15 Minutes", where they showed how you could build a TextEdit-like rich text editor with Cocoa in a couple pages of code.
In fact, it's pretty easy figure out how to do this starting from the Xcode "document-based application" template, as there's not much more to it than replacing the label control in the document window with a Text View and implementing a couple methods in the document class to get and set its contents.
the idea of object oriented vs. non object oriented languages has always thrown me off.
Everyone else will attempt to explain OO using OO terms to a non-OO programmer. Thats like trying to teach my dog to sail a boat by speaking Japanese. I'll try a different tack. You know what a computed goto is, right (other than pure unadulterated evil, right?) What if your compiler enforced the hell out of good commenting and error bound checking to let you do computed goto's safely (er, more or less)? Well that is barely scratching the surface of OO. Syntactic sugar mounded on top of syntactic sugar. You know that quote about turtles all they way down, well fundamentally no matter the paradigm its Turing machines all they way down... more or less.
but really slashdot, what is the big draw to OO
When your professor was a little baby skript kiddie wannabe on his TRS-80 Coco-2 running OS/9 and BASIC09 and liking it, object orientation was the silver bullet among the crowd who could not bother to read "the mythical man month" by Brooks. So now you suffer thru OO because it was "cool" back when parachute pants were also cool, and leggings. Much as we're now raising a crop of wannabe skript kiddies who look up to the functional programming and agile methods people who have also never read "the mythical man month" by Brooks, so your kids / my grandkids are going to have to learn functional programming as The_One_True_Paradigm_And_all_disbelievers_should_be_burned_at_the_stake. And I'll still be writing device driver code on PIC microcontrollers in raw assembly, and it'll work great and I'll be liking it.
There's a really nice wiki article you probably need to read. The world is a lot bigger than "OO" "non-OO".
http://en.wikipedia.org/wiki/Comparison_of_programming_paradigms
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
OK:
typedef struct button {
long long color[3];
void (*onClick)(int);
} Button;
Button okay;
Button cancel;
okay.onClick =
cancel.onClick =
okay.color[2] = 0xffffffff;
cancel.color[2] = 0xffffffff;
The C version is probably smaller and faster than your version.
That's incorrect. Your version will produce code that is at best as fast as a class with an inline color setter (that should be in the ctor, really) and an inline settable click function. If you use virtual inheritance to override click instead of passing a function pointer, the C++ will be faster, as modern compilers can inline many virtual function calls when they know the type at compile time.
But, as written, the provided class would produce identical assembly to your code, with in addition explicit construction/destruction semantics and easier invocation.
Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.
The first language I learnt in Highschool was Hypertalk, more of a HTML forerunner (it was 1990) than a real programming language.
when I got to Uni and was studing Engineering they taught us C. When I started my Computing course the first language they taught us was Smalltalk, if you start talking about real OO languages you cannot ignore Smalltalk
Objective-C is really a bastard child of C and Smalltalk, and this messaging behaviour really flows back to Smalltalk's influence on the language.
I hated Smalltalk back then, as did most of my classmates, but I guess it has made Objective-C a but more straightforward for me as I have played in a language that communicates like that.
I have heard from my Programming friends (mostly Games programmers) that C++ is losing traction. C# is taking it's place (Not a massive departure syntax wise, and C# is used by 3rd party suites like Unity) and Objective-C is gaining popularity, even if it is from a GUI design point of view.
I'm not sure if I believe that Objective-C has overtaken C++, but the trend is there.
Leg Godt!
What the fuck? Why the fuck would I subclass a button just to make it blue? That's just data, and damned trivial data at that. If your button object doesn't already have some mechanism for dealing with that data, it sucks and I'm using a different object, not yours.
Instead of having to code buttons from scratch, you sub class them...
No no no no NO. Goddamnit NO. Fucking Java. Motherfucking Javascript. They've ruined a generation of programmers.
Subclassing is the LAST thing you should be doing. The very last. First you should be using the customization features built in to the object, and using them directly on an instance of that object. Set the blue color on the Button class and be done with it. If that's not sufficient, use object composition. Most of the time, your object is NOT a Button. It's a something that needs to have a button. Only as a last possible resort do you subclass Button, and you'd damn well better be writing an object that still is-a Button. If you're not, you've done it WRONG.
It helps you organize your program.
This isn't really an issue unless your program gets > ~5000 lines. When you have more than 100,000 lines, you spend more time integrating into existing code than you do creating new code. Good code-organization can reduce the integration time.
"First they came for the slanderers and i said nothing."
Indeed there was OO before C++. I first learned it in a language called CLU. But the language itself was not really mature. I just took the object abstraction idea back to assembly language when I abandoned CLU.
now we need to go OSS in diesel cars
OK, with you so far...
But you're still trying to teach your dog to sail using sailing terms!
Now if on the other hand your dog was Japanese...
No bloody sharp, no bloody postincrement, and certainly no bloody "objective". Just C. Accept no substitutes.
Except that if you read his code, he's not actually subclassing Button, he's instantiating it. He's certainly saying it wrong, though.
generation of future C-programmer-turned-C++-programmer are being trained to think they know the one true way to code. They,too, someday, will try out C++ for its standard libraries and then will end up writing the most awful C++ code anyone has to read. And until their brain gets rewired for object-oriented thinking, they'll be laughing off everyone telling them that the garbage they write has to be actually readable by someone or it's pretty much useless. They will scoff and they will feel self-righteous. And then someday they will realize that they themselves can no longer read what they wrote. They will start thinking of ways to program in a way that is not just some throw-away code readable by a very small group of people. And then they will start coming up with ideas... the way they came up with ideas the first time they learned to program (only to later on realize that it's all been described in standard textbooks and that they didn't really come up with anything innovative). This time around it will be no different when after all the scoffing and all the flaming they'll pick up a copy of the 4 horsemen, read through it and nod along thinking to themselves "why haven't I read this before?" It has all happened before. It will all happen again.
Any guest worker system is indistinguishable from indentured servitude.
Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.
The C standard requires the compiler initialize all stack-allocated memory to zero. color[0] and color[1] are exactly as the OP specified. To be safe, they should indeed be initialized to zero. In professional practice, I always memset everything I allocate to 0 for the entire block of memory I have allocated, and then initialize individual members of structures to whatever their default value should be.
OK, with you so far...
But you're still trying to teach your dog to sail using sailing terms!
Now if on the other hand your dog was Japanese...
Ah, but is he sailing on a starboard tack or a port tack? And should he tack or jibe the boat? And should he attach the sheets to the tack or the clew of the sail?
OO in a hundred words or less:
Object-oriented code is a way of collecting functions and the data types they operate on into collections. Instead of having hundreds of functions that all operate on a particular data type, you group them together into a class—a collection of functions—so that you, the programmer, can easily see the relationship between them.
That's it. Inheritance is syntactic sugar around struct pointer casting. In C++, most of the OO could be approximated with "#define class struct" and slightly different syntax for the methods (use function pointers in C). It's not magic; it's just an organizational tool.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.
The C standard requires the compiler initialize all stack-allocated memory to zero. color[0] and color[1] are exactly as the OP specified. To be safe, they should indeed be initialized to zero. In professional practice, I always memset everything I allocate to 0 for the entire block of memory I have allocated, and then initialize individual members of structures to whatever their default value should be.
The C standard requires static variables to be initialized to zero by default. Stack variables that aren't explicitly initialized can be random garbage.
To verify that I'm correct, I just tested it:
You sub class this Button and give it the specifics.
Which is nice when that's what your toolkit actually does, but I seem to recall that that's exactly how most Win32 GUI toolkits don't work - that you can't subclass GUI controls at all and have to deal with them as black box objects that you work around.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
OO is *always* the best choice, depending on your definition of OO. I programmed in C back when C was considered OO. How's that? "modular programming" is what OO was based on. And, like everything else in C, it is what you make of it. C is an OO language, if you write OO code with it. What it doesn't do is enforce OO on you. The OO languages assume a level of incompetence. Back 30 years ago, I took an OO class that exclusively used C. All you young whipper-snappers and your forced good practices. Forcing practices on someone, even good ones, is a bad practice.
The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.
Of course, there are other ways of handling large projects (for example, there are examples of large projects written in C that control complexity by conventions about the separation of data and modules). But the object oriented paradigm is a common choice for large software engineering projects.
You might miss this when learning from a text book, since you are often only given small code examples and toy object hierarchies. But that extra 'overhead' around the defining of object abstraction pays off as the complexity increases. For many problems, thinking in terms of objects rather than instruction sequences can make the problem easier to solve.
Starting off with C and moving to C++ is not necessarily a good process, as you will not begin to learn to think in terms of objects; it is a completely different way of problem solving. Even for experienced programmers, the transition from C to C++ can be a six month process, not because of the extra language features, but because it requires a change in approach. Many don't stick at it long enough to realize the benefits.
The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C. Speed is affected far more by other choices; data structures and algorithms, memory localization, parallelism, and so on.
And you would also be aware that there are other paradigms as well, such as functional programming. These paradigms are not just "different tools for the job". They can have a radical impact on problem solving methods.
True. I got lazy on the tablet keyboard but was going to sub class to a blue object then instantiate with the text etc. Oh well. It was just an illustration.
The soylentnews experiment has been a dismal failure.
So now you suffer thru OO because it was "cool" back when parachute pants were also cool, and leggings.
So terrifyingly true.
It's interesting to note that the technologies which really made the Net and the Web scale - TCP/IP, HTML/HTTP and SQL databases- are not even remotely related to object orientation. The pre-Net 1980s and early-90s "online services" world, however, was utterly littered with the discarded corpses of object system after object system.
I've come to realise that there's something fundamentally "not even wrong" about the basic concepts of object orientation as it's usually sold. Like postmodernism, if you go looking you find that theres there's no actual definition to it. There's no formal mathematics, no reference implementation, no validity checking. No two experts or language designers will even agree what object orientation is. Is it inheritance? Well then, single or multiple? Either. Interfaces? COM has them, other systems don't. Is it classes? No, because there's prototype OO. Is it private/public members? No, because Javascript doesn't have those. Is it object persistence? Not according to C++ and PHP, but yes if you ask the object database people. Is a JSON data structure an object? Well, yes and no. Maybe.
The term "OO" is applied to systems which have fundamentally incompatible semantics. Good luck trying to get any of that mess to integrate. It only seems to work with a strong centralised hand coordinating the object repositories. The OO people's attempt to standardise objects across systems was Software Components, which gave us COM and CORBA. Those worked in very limited contexts - as a fancy way of loading C++ libraries in Windows - but not at web scale. The IETF answer, which did work, was to just give up on using objects and use prehistoric, pre-OO ASCII-based markup languages - SMTP and SGML/HTML/XML.
We got the Web by NOT using OO. Why do we want to keep trying to apply a failed concept?
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
TIOBE is essentially just a big troll site. Their methodology is so far beyond unscientific it's not even wrong. Here is the result of my own unscientific poll:
C: About 234,000,000 results
Objective-C: About 41,400,000 results
See, C++ dominates Objective-C by more than a factor of five. You can take that to the bank. You're welcome.
When all you have is a hammer, every problem starts to look like a thumb.
Sure it *can* be done, but it fucking sucks. Compare programming Qt and GTK and you'll see why.
(Not that OOP is the be-all and end-all of programming. Frankly, it sucks for many problems, but GUI toolkits is one place where it's very useful -- mainly because of polymorphism.)
umm...if a language is Turing complete then there is nothing that can be done in one language that can not be done in another, so no...you would not see a comparison like that.
duh... you can use cin and cout in C++.
you forgot, "get off my lawn."
Object-oriented code is a way of collecting functions and the data types they operate on into collections. Instead of having hundreds of functions that all operate on a particular data type, you group them together into a class—a collection of functions—so that you, the programmer, can easily see the relationship between them.
That's the best-case, well-behaved upside of OO, yes. But it has an evil twin called "object-oriented analysis".
Object-oriented analysis is a way of taking your company's essential business data - the data you need to trade and survive, which has been around since before punched cards and which will be around when mind-mapped DNA moon crystals are obsolete - and then wrapping that data together with hard-coded functions hacked up in some quirky, platform-specific language invented five minutes ago and for which all support will evaporate in another ten - and shoving that into a proprietary "business methods repository" running on a database sever which has never been tested written by a company which will go out of business tomorrow.
Next Thursday, when you've left the ICT department for greener fields writing iPad apps in HTML5, your successor will have to work out how to un-hack all that weird platform-specific code, decrypt the proprietary runtime format, extract the actual business data back into some standard database table format which can't include any of the class inheritance structure or "business methods".. and then shove the mutilated quivering remains back into the OO Design process to start the cycle again.
This procedure is called "mixing code and data" and is essential to the OO way of thinking. It is a beautiful shiny butterfly which only wants to be your friend and it is the bestest way of handling data ever imagined.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I saw what he did. But I knew he meant to do what he said, not what he wrote. As he later confirmed. Hence, rant.
Yes. And there are no shortage of toolkits, libraries, macros and personal styles that use C structs as objects.
They don't do inheritance so well though.
There's nothing wrong with C, and I greatly prefer C to the horror that is C++, but there ARE some things real objects do that are pretty nice in many circumstances. That's why it's nice that Objective-C (and C++ if you insist on doing that to yourself) are supersets of C, so you can happily mix non-object oriented C code and OO code however you like.
Your slashdot ID is lower than mine, so you can take care of it.
OO is *always* the best choice, depending on your definition of OO.
Believing this is a tremendously bad mistake to make. There are plenty of other high-level programming paradigms that for some tasks can be vastly superior to OO--e.g. straight functional programming in ML or Dylan, or logic programming in Prolog, or explicitly stack-based programming in Forth or Postscript. There is no "one size fits all" when it comes to programming.
rage, rage against the dying of the light
it's a struct. no inheritance, no polymorphism. not a class/object.
YES! Now, explain to me how you got past "C, a raw machine independent assembler-like language"?
Assembler-like? C? C used to be the hot new language that held your hand and did everything for you, unlike assembler. Now C is assembler-like?
That's exactly what the author was doing. I've since returned to OO stuff (programming is a hobby, not a profession), and enjoy it much more than my initial impressions. And yes, some of Apple's sample programs do a very good job of demonstrating the ways that OO programming (and Apple's frameworks, natch) can make some tasks a breeze.
If you can't convince them, convict them.
I miss this type of stuff on /,
Great to see actual geek stuff.
Waiting for an amusing sig.
Wasn't me saying C is assembler-like.
I write C. I write C++. I write Python. I write shell script. I've written goddamn VB, when I have to. I was taught how to write FORTRAN77, but I never did once I left the class. And I've written a double handful of MIPS and 8086 assembly. C ain't assembly, that's for sure.
I agree. The GP was asking for a killer feature, however, and stated that (s)he was an amateur. I figured "faster and easier" was more exciting than "encapsulation and abstraction" :)
You're right that C++ isn't a snail compared to C. I was thinking of interpreted languages when I wrote that. I disagree with you that different paradigms don't fit the "different tools for different jobs" attitude, but I suspect we're arguing semantics here. Regardless, it is likely you know more than I, so I will concede the point.
If you can't convince them, convict them.
We got the Web? That's your argument?
Object oriented programming is a nice organizational technique for larger programs and code reuse. It works well, if used properly, not least because it imposes a namespace system. Most OO systems also give you some neat automatic features like inheritance.
OO is not a silver bullet, not everything needs to be OO, and nobody, ever, should start learning programming with OO. If you make absolutely everything an object you're either an idiot or a Java programmer (no comment). If you make everything a templated class you're evil and a C++ programmer. If you reject all of OO because some people take it too far, you're no better than the other two.
OO does some cool things. Used properly, at the right time, it makes very nice code. Used badly, it makes a godawful mess.
Almost all the C++ books never talk about object-oriented concepts and nor introduce them one by one. Sequence, selection and loop concepts and how they are implemented in the procedural part of the object modules are not clearly explained. Most will teach C for the most part and then jump to OO. OO thinking is difficult to comprehend and one needs lots of experience in that domain. Most authors are contract writers for the publishing companies and have very little understanding of how to teach a language. If you can write simple BASIC code - sequence, selection and loop, then with about 6 or seven rules, you can easily convert them into C code. I have done about 60 simple programs like that to understand the implementation of C. So, it boils down to the following - the best teachers don't write text books as it takes too much time and less monetary reward and the good text book writers have not taught courses to wide audience to understand what should be the "Student friendly " text book should be. In most universities, the instructors select a text book that comes with solution manuals and Power point slides. You don't learn from these instructors. If you have had solid foundation in problem solving, data structure etc., you can learn any programming language any time but takes time to become a professional. No 24 hours book can teach you what you can learn from a good instructor over a period of time.
Objects simply allow for an efficient programming structure for large software. That's the main reason.
Sorry, those imaginary benefits are as mythical as unicorns. OOP is objectively inefficient.
Really, this shit has been studied. No benefits in productivity were found for OOP. I'm actually shocked to find that OOP didn't harm productivity!
OOP leads to an incomprehensible mess of dependencies (inheritance is bad, composition is almost worse) -- and design patterns lead directly to over-engineered monstrosities that are not only bloated and slow, but destroy any hope of maintainability.
People get confused because objects can be handy abstractions -- and used extremely sparingly, and only when other modular approaches don't fit the problem as well, can make code easier to understand and maintain. Objects, however, do not OOP make.
Even Alan Kay (the guy who coined the term) regrets it. It distracted from his much better idea: agents that communicate via message passing (incidently, a concept NOT well served by modern OOP languages)
One apology I hear all the time is that no one really understand OOP and that it takes years of study to truly grok the concepts and see the benefits. Well, if that's the case (very doubtful) then half of the promises of OOP are false. It's not easier to use, it clearly doesn't simplify design or development, and to top it all off, it bloats your code with no tangible benefits.
OOP is a lie, a hoax, over-hyped, and over-sold. It's a blight on software development. It needs to die. It's anti-modular (accidentally) and anti-parallel (intrinsically) It's the single worst paradigm (if that even qualifies, as there is so little agreement about what constitutes OOP) for this modern era.
If you're an advocate of OOP, I can automatically assume that you're either an idiot or so insecure that you don't dare question the "mainstream" view, like the average creationist.
I have written apps in C++, Objective-C, and others such as C#. I have always wound up using C in those apps, too. All of them make provisions for its use. The reason I used the other languages was the tools associated with the development environments such as Xcode and Visual Studio. For example, getting to the iOS APIs is not as easy for me just using C, but some things are easier for me to write in C, and the wrappers are straightforward.
Therefore, the survey might include usage such as mine, which could tag every app I ever wrote as a 'C' app. FWIW
OO isn't always the best option. OO languages are typically a lot more complex and produce slower executables than plain C, so there is a trade-off that can be important in certain situations. As with anything, pick the best tool for the job.
You got modded up for that misinformation? Perhaps you are not aware that gcc and g++ use the same optimizer and code generator. If you just mindless recompile your C program as C++ then you will get the same executable code. On the other hand, you can often take advantage of C++ features such as member functions to write code that optimizes better than palin C. So the truth is the opposite of what you claim.
When all you have is a hammer, every problem starts to look like a thumb.
Ayn Rand ended her life on Medicare. Which is kind of ironic don't you think?
Undetectable Steganography? Yep, there's an app fo
there are plenty of other high-level programming paradigms that for some tasks can be vastly superior to OO--e.g. straight functional programming in ML or Dylan, or logic programming in Prolog, or explicitly stack-based programming in Forth or Postscript.
OO is orthogonal to all those techniques. If you want to OOP your explicit stacks, you can.
When all you have is a hammer, every problem starts to look like a thumb.
C used to be the hot new language that held your hand and did everything for you, unlike assembler. Now C is assembler-like?
C was always considered assembler-like, including by those who wrote it. Non-assembler like languages of the day included Algol 68, LISP, Snobol, TRAC and Simula.
When all you have is a hammer, every problem starts to look like a thumb.
I've written goddamn VB, when I have to.
I've written GWBASIC and no matter how hard I scrub, I can't get it off me.
When all you have is a hammer, every problem starts to look like a thumb.
Everyone else will attempt to explain OO using OO terms to a non-OO programmer.
How about: "It's like when you stop beating yourself on the head with a hammer".
When all you have is a hammer, every problem starts to look like a thumb.
I'd need to double check, but I don't believe that's true. I believe that the C standard says, if you want a variable set to some pre-determined value, you'd damn well better do it yourself because the compiler isn't going to do it for you, be it on the heap or the stack. C is built around efficiency, and it assumes that if you didn't do something, you meant for it not to be done, and pre-assigning a stack variable to 0 would break that paradigm. I mean, what if I write the code
object* next = list.head();
int i;
while((i = object.value())
next = next.next();
do something with i;
Clearly in that case you wouldn't much want to initialize i to 0, it'd be a waste.
Inheritance is syntactic sugar around struct pointer casting.
Control structures are syntactic sugar around gotos and high level languages are syntactic sugar for directly typing the bytes into memory.
When all you have is a hammer, every problem starts to look like a thumb.
We got the Web by NOT using OO. Why do we want to keep trying to apply a failed concept?
Still trying to explain why you haven't gotten around to learning C++? Because you obviously haven't. It hurts, but not that much. And then you might have a clue.
When all you have is a hammer, every problem starts to look like a thumb.
Absolutely, and it's an excellent technique to apply in a lot of cases. Just not always.
rage, rage against the dying of the light
If you just mindless recompile your C program as C++ then you will get the same executable code.
duh...because it's just C code, recompiling it doesn't magically make it OO C++ code.
Valid is probably not the word you are looking for. Objective, maybe?
Valid is something that can be shown to be true, given that the inputs were true. There are cases where you could argue that OO is a valid choice. It just depends on what the assumptions/inputs are.
what is the big draw to OO? The killer feature?
The short version: Instead of putting your data in the code, you put your code in the data, and that makes your code much easier to understand and reuse. Here's a quick Ruby example of doing something procedurally:
def degCtoF(c) ; return (c * 9.0 / 5.0 ) + 32 ; end
def degFtoC(f) ; return (f - 32) * 5.0/9.0 ; end
def format_c_temp(c) ; return "%s degrees F, %s degress C" % [degCtoF(c), c] ; end
oven_temperature_C = 55
puts format_c_temp(oven_temperature_C)
And then again doing it OO:
class Temperature :degC
attr_accessor
def degF ; return (@degC * 9.0 / 5.0) + 32 ; end
def to_s ; return "%s degrees F, %s degrees C" % [degF, degC] ; end
end
oven_temperature = Temperature.new
oven_temperature.degC = 55
puts oven_temperature.to_s
The idea is that by attaching your code to the data, the data becomes "smart" and knows how to process itself. This is a huge benefit for code reuse since the person reusing your classes doesn't have to understand how they represent data internally, or the mechanics of how they process the data. It's already slightly easier to understand with this short example, and the effect is magnified greatly as the size of the codebase grows.
Sorry, those imaginary benefits are as mythical as unicorns.
Hey just like your knowledge of the subject.
OOP is objectively inefficient.
Then you don't understand the meaning of the word 'objectively'.
Really, this shit has been studied.
By whom? Evidence? None.
No benefits in productivity were found for OOP.
Evidence? None, what a surprise, decrying something with no evidence and no facts and no basis.
I'm actually shocked to find that OOP didn't harm productivity!
Really? Evidence? None, again decrying something with no evidence and no facts and no basis.
OOP leads to an incomprehensible mess of dependencies
I suppose the very basic concepts of inheritance would seem like an incomprehensible mess to someone with such a small feeble mind as you as to purport idiotic and baseless opinions as fact.
People get confused because objects can be handy abstractions
Judging from your post you get confused WAY before that.
It distracted from his much better idea: agents that communicate via message passing (incidently, a concept NOT well served by modern OOP languages)
There is absolutely nothing wrong with message passing agent paradigms wrt OOP, but it doesn't surprise me that like all the other claims in your post this one lacks merit, basis or citation and is just a poorly articulated emotional complaint to something you clearly have no understanding of.
One apology I hear all the time is that no one really understand OOP and that it takes years of study to truly grok the concepts and see the benefits.
Well it just doesn't.
Well, if that's the case (very doubtful) then half of the promises of OOP are false.
It's not the case.
It's not easier to use, it clearly doesn't simplify design or development, and to top it all off, it bloats your code with no tangible benefits.
Looks like more emotional complaints because you can't understand it, unsurprisingly again lacking any evidence or merit whatsoever.
OOP is a lie, a hoax, over-hyped, and over-sold.
Hey just like your post!
It's a blight on software development. It needs to die.
If you were right it would simply die on its own, but obviously you are just angry at yourself for your failure to understand it otherwise you would have objective (look up the word because your previous use of it suggests you don't understand it) basis for your claims and some evidence to back them, which you don't.
It's anti-modular (accidentally) and anti-parallel (intrinsically) It's the single worst paradigm (if that even qualifies, as there is so little agreement about what constitutes OOP) for this modern era.
Yet more emotional complaints, unsurprisingly again lacking any evidence or merit whatsoever.
If you're an advocate of OOP, I can automatically assume that you're either an idiot or so insecure that you don't dare question the "mainstream" view, like the average creationist.
I suppose the AC with no evidence and an obvious lack of mental capacity to even understand the most basic concepts is a reliable source.
From their own description:
emphasis in the original
I think it's fair to say that if you take TIOBE for what it's worth, there's a lot to learn about how programming languages wax and wane in popularity over the years. Surely that's worth something.
It's about mentioning this "god" fantasy thing
It's no fantasy.
God started out as a C coder, got bored and tried to rebuild the project in a self-built language similar to Brainfuck http://en.wikipedia.org/wiki/Brainfuck, now called DNA. The signs are everywhere - in fact GCC is still being used in places, notably to produce Alanine.
Of course, it's an old project, abandoned long ago. There's cruft, commented out code and dependencies everywhere, The APIs are wildly inconsistent, the whole thing is a virus and worm magnet. Even fork bombs are rarely trapped.
The documentation is archaic and unreadable, rewritten from the original by ancient geeks.Modern coders can only guess at what it means, and according to Nietzsche, the guy who wrote it left the company long ago.
About the only thing going for it is a very effective, if slightly weird, bootstrapping process.
"I've got more toys than Teruhisa Kitahara."
On slashdot, it's a point of pride not to RTFA. Also it's much more interesting to go from Objective-C to Objectiv-isim to the spectrum of primate behaviour. The language popularity thing is just something for people who like talking about football ladders.
What we need now is another tenuosly linked meme...In my copy of 1984 there is a reference to a fictional document that describes the different languages spoken by various groups. One of those languages is 'C' - the language of technocrats. So it follows that if using objective-C makes one a Randian, I guess my long time use of 'C' means I'm an Orwellian technocrat. The odd thing is, I do believe the public service should be staffed with experts who are unaffraid to "speak truth to power".
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
The C standard requires the compiler initialize all stack-allocated memory to zero.
And how about heap-allocated structures?
So your C example results in differently initialized objects depending on how they're allocated. Fortunately C++ solves that by having constructors/destructors. The author of the Button class can guaranteed that the entire object is correctly initialized. That's the sort of stuff you don't get from C. Sure, you can fake it in C, but if you're just going to emulate C++, you might as well use C++.
Hopefully this will bring more developers to GNUStep / Etoile.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
The C standard requires the compiler initialize all stack-allocated memory to zero.
Not only the standard does not require it, but virtually all real-world implementations don't do that, either.
In professional practice, I always memset everything I allocate to 0 for the entire block of memory I have allocated
That's a bad habit. There's no guarantee in the standard that setting all chars to 0 will correspond to a default value of a type, or even some valid, representation of pretty much any other type. For locals, you'd do better by writing an explicit initializer ={0} - this works with any type, and will implicitly initialize all remaining fields to their default values.
Variables with static storage duration are initialized to 0 by default. Variables with auto storage duration are not initialized by default.
For heap, malloc doesn't guarantee anything about the contents of the allocated memory block, so it's effectively uninitialized - but then there's also calloc to zero-init.
. Goddamnit NO. Fucking Java. Motherfucking Javascript.
There's no subclassing in Javascript (unless you mean some third-party library).
Palin C? I much prefer to code in Monty Python.
The C standard requires the compiler initialize all stack-allocated memory to zero.
So how many years have you been programming C with this absolutely wrong piece of info? I love how the C guys tout that their programmers are the best because the language requires it, where the reality is that the inevitable mistakes end up much more costly.
Palin C? I much prefer to code in Monty Python.
Sarah's C sounds betters...
Everything I write is lies, read between the lines.
This is just another one of those 'Jim floats -> Jim is made of wood' matters. Don't know how so many people can be so daft not to see that the language popularity indice is simply created from the number of internet searches on the matter. Of course Objective-C will score high because 10 people trying to figure out just how the hell to use the bolloks will generate as many searches on Objective-C in a single month as a 10000 people that knows how to program C++ does on the latter in the same period. I write C++ 9 hours a day 289 days a year and probably perform a search related to it once a month. So the indice adds 2 and 2 and comes up with 5. Too many of this kind of stupidity going on in the world really.
...and I thought God was a Higgs boson, kicking around in a pinball machine (aptly named Symmetry Breaker) operated by some bored hyperdimensional kid. How wrong I was! :-)
Worst. Metric. Ever.
Using web searches? Seriously?
Given the sheer volume of code that will never, ever show up on a web search, the most they could hope to capture accurately is open source code. Which does not even come CLOSE to capturing the popularity of a language. The amount of commercial, closed-source code that is just ignored by this metric is disgusting to the point it makes it completely irrelevant.
At most, it shows what is trendy in the open source world. But having worked on a number of proprietary, multi-million line ode projects, that never see the light of a search engine, I can tell you're some languages are still as popular as ever in the corporate world. For example I have not noticed any significant decline in end for C++ programmers. Nor have I seen. Big uptick in places hiring for Objective-C. At least, not that are actually willing to pay living wage in big city.
And if not to try and inform people where to spend their 'learning time' for bet benefit (ie. to get the best job) then what is the point of such rankings?
And don't forget that the hypervisors (plural) run outside of time. One can't do garbage collection when the garbage is eternal, only transmutation.
No no no no NO. Goddamnit NO. Fucking Java. Motherfucking Javascript. They've ruined a generation of programmers. Subclassing is the LAST thing you should be doing.
Can't speak for the JavaScript folks, but in the Java world the best practice is to favour composition over inheritance. So subclassing a button just to change the colour would not be considered good form. The problem with people using inheritance in inappropriate places is down to what I call the "new toy" syndrome. Programmers new to OOP feel they must use it, and to be fair many books tend to place too much empahsise on it (I'm looking at you Mr Stroustrup).
It was kind of a rant. Accuracy took a back seat to histrionics. Java rage spilled over onto Javascript. My bad.
You didn't actually verify it by using gcc but you're still correct.
By using gcc you only tested gcc's implementation-defined C behaviour.
If gcc was strictly adhering to the C std it would tell you that int main() is undefined behaviour on hosted environments and implementation-defined on freestanding environments.
Oh, how I hate those "Build a gizmo in 15 minutes" advertutorials.
Here's mine:
#include <kitchensink>
int main(int argc, char *argv[]) {
everything_but_the(argc, argv);
return 42-6*7;
}
Morale: all those "build an * in 15 minutes" quickies do is try to sell you on whatever libraries / frameworks included in the system, they teach you little to nothing about the usefulness of the language for building completely new things.
The Hacker's Guide To The Kernel: Don't panic()!
Exactly.
OP sounds like:
void oop_rulezz() {
Gizmo gizmo;
Hammer hammer;
hammer.knock((Nail *)&gizmo);
}
which isn't always the right thing to do.
The Hacker's Guide To The Kernel: Don't panic()!
You're wrong. I only got to terms with OOP after becoming familiar with hardware synthesis. It is a very natural method if used correctly. I agree it doesn't lead to the most efficient machine code. I also agree that the Ruby and Java style OOP is just a bad idea. Then again, it's a compromise just like everything else about your computer. But the correct naming should be modular programming. OOP is a valid paradigm to pull a program into modular chunks. You can make the rather small parts of code in the module very efficient. They might not tie into the rest of the application in the most efficient way but it'll work just fine. In fact objects are a logical extension of dynamic loading. There are a few set entry points, and everything happens in the library its own memory space or the program's memory space (see this as public, protected and private access in some way). When the code is done executing it'll return to the main program and return its values through some mechanism like a stack. Now doesn't this sound an awful lot like an object?
Being against something in a radical way is stupid, you neglect its possible uses and the advantages it might offer. It's the same with people who are radical against a certain language (except Ruby, you're allowed to hate that one cause it really is a bad idea in terms of readability in my humble opinion).
Personally I find myself aligned with Ada's methodology for modular programming, but sadly many people have difficulties grasping the finer points of the language. Ada allows you to drag pretty much everything out of any system if you use it correctly. Most people just don't like that Ada really won't let you mess around with data types as you wish; you respect Ada's way or you can bugger off. But in return you gain security and speed, the compiler knows exactly what will occur at any given point and is able to produce very efficient code. Still people hate it for various reasons; First of all it was made by the U.S. military, I grant you that's not a good start all things considered. A second problem is the lack of popularity on the internet. I have yet to find a good Ada tutorial on the internet. Third and foremost it's very verbose and strict. Make one mistake and the compiler will come back at you with a long sharp object with the sole intention to pierce your vital organs and your children. Ada programmers will often curse at the compiler like there'll be no tomorrow cause of it. They'll blame it for every bad event on the planet, but at the end of the day they know it'll do its job and prevent them from writing bad code.
http://www.bkent.net/Doc/darxrp.htm ... the value of this book resides in its critical, probing approach to the difficulties of modeling reality in typical information systems... it is very well written and should prove both enjoyable and enlightening to a careful reader. -ACM Computing Reviews, August 1980"
"Data and Reality illustrates extensively the pitfalls of any simplistic attempts to capture reality as data in the sense of today's database systems.
And also:
http://conferences.idealliance.org/extreme/html/2003/Kent01/EML2003Kent01.html
"The identity problem is intractable. To shed light on the problem, which currently is a swirl of interlocking problems that tend to get tumbled together in any discussion, we separate out the various issues so they can be rationally addressed one at a time as much as possible. We explore various aspects of the problem, pick one aspect to focus on, pose an idealized theoretical solution, and then explore the factors rendering this solution impractical. The success of this endeavor depends on our agreement that the selected aspect is a good one to focus on, and that the idealized solution represents a desirable target to try to approximate as well as we can. If we achieve consensus here, then we at least have a unifying framework for coordinating the various partial solutions to fragments of the problem. "
I thought you were going to also make a point about non-Western cultures often being less "object oriented" in their language learning (and perhaps more "relation-oriented" which I've heard in the past)...
Also, Alan Kay, who coined the term "object oriented" for Smalltalk, and said C++ was not what he had in mind, suggested later he should have used "message oriented", since message sending and processing is really at the heart of Smalltalk.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
The godfather of C, Herbert Schildt, is smiling today. Maybe he'll take the Windows 95 chapter out of his C book and release a new edition!
hrmpfh, been out of that stuff too long, must be 'hammer.knock((Nail &)gizmo);'
Anyway, make up your own Gizmo & Nail classes, then try it. Compiler won't complain if you want to nail yourself in the foot, that's the point, (type) pun intended.
The Hacker's Guide To The Kernel: Don't panic()!
I once read a great explanation in a book for nonprogrammers:
Imagine a procedural program being a stack of bricks. When you're not careful, the stack falls over, and the whole program breaks down. Programmers have the task to keep this stack stable.
When you're using OO properly, you split this stack into multiple smaller ones. So it's easier to balance them, and when one of them does fall over, the others stay intact.
True. The friendliness of a language is directly proportional to the thickness of the layer of glaze.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The most insightful thing you will ever take from using OO programming practices extensively is that its the politically correct way to write spaghetti code and other "bad practices."
In the days of old before Structured Programming really took hold, people would write code with lots of GoTo's, branching haphazardly around in a hard to follow ways. "GoTo Considered Harmful" they said.
In these enlightened times however, people now use the powerful OO techniques such as polymorphism and inheritance to branch haphazardly around in hard to follow ways. But its OK now because its "Object Oriented."
You will see that global variables are bad if its a structured program, but its quite alright to have a single instance of an object accessible from anywhere and everywhere.
And C++ makes it a whole lot better because of templates. You can completely override every convention while doing your OO stuff, because that makes everything much easier to understand and follow. You will never be asking the question "how the hell did it get here?"
Now there is an even greater power for OO purists to leverage. Its called "lambda expressions" also known as "anonymous functions" because if there is one thing the OO guys need, its another way to hide program flow.
"His name was James Damore."
You have to be careful when verifying things in this way. You're actually testing two things:
1. The compiler's implementation.
2. The operating system's memory allocation
Some operating systems always clear memory before giving it to user programs. Having garbage in the output proves that GCC allocates a certain way and that your OS didn't care to clean things up. It doesn't prove anything about the C standard itself. Looking at the C11 standard is the best choice here.
I remember in college I had a lot of trouble early on because I'd write my homework on Mac OS X and then try to run it on Solaris or Linux boxes. Many things worked on OS X because the memory was cleared. Sparc hardware showed me where I screwed up passing things around on the stack.
He also has an asshole, As do I. I just try not to emulate mine as much as he does.
So he can't figure out how to write clean C++ code. Fine. So he prefers C - even better. Whatever. Not sure why this matters.
Local variables in C are almost always on the stack. These are not "allocated" from the OS just prior to use. The garbage on the stack comes from the setup routines that the C runtime called just prior to entering main(); the OS has no control over that.
At any rate, as you point out, getting 0 proves nothing. (In fact, if you turn on compiler optimization, gcc eliminates the actual stack storage and does give you a compile-time computed zero.) However, finding an actual garbage value the way I did proves that either gcc has a bug (unlikely in this case), or that local variables may indeed be totally uninitialized.
I verified it well enough for the real world.
I mean really. What are the actual odds that if gcc sees "int main()" instead of 'int main(void)', it thinks "Oh! Undefined behavior! Just for grins, I'll do everything just the same, except now I'll fail to initialize automatic variables to zero at runtime. That'll teach 'em."
Try Bruce Eckel's "Thinking in C++". I found it absolutely invaluable. Also, the online version is free on his own site.
You are hitting on different aspects of programming here. For instance, memory management techniques aren't the same as say drawing a line on the screen.
I'll stick to Eiffel.. thank you very much ;-)
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
Unless you are doing string or memory manipulation in c, then yes, you can use them. In all other languages it should be banned. I remember tutting when i read that c# had caved in to the c programmers and included it. There is just no need because 1) it is not obvious (eg, _month[0]="Jan" or things like that). 2)Use an iterator, that's what they are there for.
Of course that is just my opinion.
I have excellent Karma and I am not afraid to Troll it.
And for that matter, don't get me started on Objective C either. Worst of both worlds.
I have excellent Karma and I am not afraid to Troll it.
Actually, structs can be used to provide inheritance and polymorphism. And if you add a bunch of function pointers to the struct, now you have a what is essentially an object in every sense of the word. See http://stackoverflow.com/questions/351733/can-you-write-object-oriented-code-in-c for more information.
I do not have a signature
The competition between Microsoft and Apple is really starting to look like The Tortoise and The Hare.
Apple suffered so many humiliating defeats back in the day.
Now, they are dominating everything beyond desktop PCs.
Even Objective C is making a comeback.
Apple is really having the last laugh.
Note, I'm a linux user and not particularly a fanboy of either company.
I guess if people who have mastered C by programming with it for 15 - 20 or 30 years would have spend the same amount of time doing C++, SmalTalk or CLOS or OCaml they would say the same about such a language. ... the more powerfull the language the less lines you then need to write.
Point is: every language (family) forces you to think in "idioms" of that language.
Learning to think in those idioms and extending that to patterns is the long time consuming part.
Have you done that you are an artist in any language
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Well, C is one step above assembler but not much more than that. Most of its commands and operations map onto assembly quite nicely (x++ to increment a variable, etc) and outside of the libraries, there is not much "high level" functionality built into it. Its portable as most of it is "lowest common denominator" stuff.
I have excellent Karma and I am not afraid to Troll it.
I was asking how you could write such a great rant without even commenting on that little gem.
What is wrong with header files?
Helps keep my code nice and clean.
Stuck in your ways hey? There's nothing wrong with that syntax, it's just unfamiliar to you.
revalue = object.methodname(); would be as yucky to a SmallTalk or Objective C programmer who had never used anything else. Personally, I used to write PyObjC code, so I barely see the difference anymore.
I belive you are wrong, except the C standard changed greatly recently: http://en.wikipedia.org/wiki/Automatic_variable
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There's a C compiler for almost every platform. And most of the compilers/interpreters for other languages are written in C.
Coder's Stone: The programming language quick ref for iPad
Some of us make the instructions that other people invoke in assembly language.
>C ain't assembly, that's for sure.
Assembler ain't microcode, that's for sure.
Microcode ain't system verilog, that's for sure.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I'm confused, how is that much different than OOP in C++, and grabbing a value from an object's accessor function?
Purely out of curiosity, I mean
Object oriented code is simple:
lets start with C:
#include "somestuff.h"
int myData;
char* firstWord;
void doSomething(int argc, char **argv) { ...
println("in fact I'm not doing anything fancy\n");
firstWord = argv[0];
}
int main(int argc, char** argv) {
doSomething(argc, argv);
}
I did not try to make this perfect. So what do we have here? A C file. main is only ment as entry point, as a "class" wont have that, but an constructor instead.
Now lets simply wrap the whole file into { and } and replace the first comment.
// was fancy.c // this would move, but I keep it here
class fancy {
#include "somestuff.h"
int myData;
char* firstWord;
void doSomething(int argc, char **argv) { ...
println("in fact I'm not doing anything fancy\n");
firstWord = argv[0];
}
int main(int argc, char** argv) {
doSomething(argc, argv);
}
}
Now instead of a C File with a main function that can be started multiple times from the command line (when compiled ofc), occupying one process each and only capable to communicate via Unix IPC features, we now have a class.
#inlcude "fancy"
int main(intc argc, char**) {
fancy fancy1;
fancy *fancy2 = new fancy;
fancy1.doSomething(argc, argv);
fancy2->doSomething(argc, reverse(argc, argv);
}
What did we gain?
We can now instanciate "the same thing" two times inside the same process, as objects
The two objects can communicate via function calls with each other or other objects.
If the language only would support it (unlike C++), then a class is simply a name, bracers and a keyword wrapped around an ordinary C or Pascal file.
The variables inside of the fancy.c are global static variables.
The variables inside of the class fancy (myData and firstWord) are where ever the fancy object is allocated. fancy1 on the stack, fancy2 on the heap.
Thats it, nothing more magic about object orientation ... at least not on the first glance ;D
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The last time I worked on programms haveing around 5k lines was 1985 when I started learning pascal.
Since the last ten to 20 years most programs I'm working on are in a few 100k locs or several million locs.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Until hardware supports C++/Java/C# etc... at a native level, e.g. that compilers don't convert to C or the higher level language isn't based/written in C, then you'll start to see C decline.... rapidly.
Obj-C and iOS show this as an example. iOS is Obj-C compiled/processed at the h/w level.
Most people don't knwo what turing complete actually means.
For starters: no you can not write a "pointer" in Java. No you can not place some code or some data at an arbitrary memory location.
No, you can not use the non existing pointer to access that memory location. And no you can not use that non existing pointer to call some code in that memory that you can not access.
However: you can simulate a microprocessor in Java, like an 6502. So a Java program can run all what a 6502 can inside that emulation.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The big draw with OOP is that (ideally) it removed the separation between algorithms and data. In traditional imperative programming, you would code set of algorithms, procedures that do different things with data, and the data itself would be stored in arrays or allocated memory accessed with pointers. With OOP you code classes that encapsulate both the data, and the methods that are used to manipulate it. So if, for example, you were writing a file manager and wanted to implement a print function, you could handle files as objects, and as long as each different file type implemented an interface that had a print() function, you could call file.print() to print the contents of that file, without needing to know anything about how the data works within it.
Of course, it's perfectly possible to do that sort of thing using defined APIs in non object-oriented languages, but there is a neatness to the way OOP works that makes that sort of thing a lot easier. OOP hides all of the details of how a class works, and as long as it's coded cleanly, it's quite easy to extend programs to work with different types of data that the original author never intended, by coding classes that implement the same base classes (or interfaces) that the programs expects.
Best Slashsdot post ever!
Ruby and Java have two vastly different styles of OOP. Java is closer to the C++ style, while Ruby is closer to the Smalltalk/Objective-C message passing style.
return 42-6*7;
Better do another code review before running that. In some locales, that divides by 0 and returns NAU.
And congratulations, you've just invented OOP. You just did it without the compiler.
No, it's an object. Its a set of attributes on a particular thing. And if you want, you can put some pointers to functions in there that would act on that data. Hell, you don't even need the pointers to functions to be in the struct, you just need functions that take the struct as a parameter.
Yes, and both are a bad idea; Notice the usage of the word "and". I never implied the styles were identical.
- in fact GCC is still being used in places, notably to produce Alanine.
Isn't phenyl-alanine --oops I mean aspertame-- --oops, I mean nutrasweet-- the shit they put in 'low cal' soft drinks that pretends to be sugar, but makes kids sick and gives people cancer?
Not a programmer by any means(You're out of your element, Donny), but I remember one of the first things being taught in high school APCS ~10 years ago was to always initialize a variable because uninitialized variables are unpredictable. We used a Borland compiler, and it gave random junk in an uninitialized variable if I recall.
So are you saying it takes a fifth to do Forth?
OMG, you have clearly never seen a business system written primarily in SQL stored procs. I spent 6 months working on an ERP system that did the majority of its processing in SQL...it nearly killed me (nothing wrong with SQL for actual data tasks though). Also, XML? I would rather store everything in CSV flat files like on on an old school RPG systems than relying heavily on XML.
No, you verified it well enough for gcc.
gcc complains about void main(), which is perfectly valid C in a freestanding environment, so why can't it complain about int main() in a hosted environment?
My best guess is that the gcc devs don't care about the difference between C and C++ mains because int main() is correct C++.
Or they don't know. Or they're just lazy. In any case, if gcc wasn't free and available, I doubt it'd be used as much.
" However the real story is that C, a raw machine independent assembler-like language..."
Okay...it is now obvious to me that you have never used C before...and probably not C++ either. I'm still scratching my head about that "machine independent" part as well. I would NOT say that C is machine independent as it compiles down to machine code...and machines are notoriously fickle about their machine code. Maybe what you meant to say was that there are standards-compliant C compilers available for most (maybe all?...probably not *all*) platforms out there.
And what exactly do you mean by "raw?" That one's got me scratching my head as well.
Anyway, I expect C to be around for a very long time. Like Java, html, javascript, etc., it has its place...
But I don't care what kind of main() gcc accepts, or what warnings it might or might not print about main(), or why the gcc devs handle main() in any particular fashion. None of that has the slightest relevance to the original discussion, which was about uninitialized local variables.
The fact of the matter is, if local variables were supposed to be initialized to zero according to the standard, then gcc, which is probably the most popular C compiler on the planet, would do it.
So, you're saying that the explosive overpopulation of homo retardus is just a fork bomb?
And the reason for this is, of course, efficiency. Creating space for local variables is as simple as moving a stack pointer. Initializing them to 0 just takes extra time. Uninitialized static variables belong to a special section of the executable (bss in elf format) that quickly and automatically initializes to 0. None of this is specified by the C standard, but the standard was written to accommodate these optimizations.
I believe there's one exception, which is the initialization of pointers declared as static. These are initialized to NULL, not 0. While generally the same, some bizarre architectures have a different bit pattern for NULL. The GP's idea of memset everything to 0 is technically a bad idea for any structure that has a pointer, although it should be fine for most any modern CPU.
And regarding the original discussion about uninitialised local variables I agreed with you. But that's because of the standard, not because of how gcc does things.
Regarding gcc's adherence to the standard I gave you the most basic example a compiler should get right but doesn't.
All I'm trying to tell you is that if you want to verify that something is according to the standard, then using a piece of code and a compiler is not the correct way to do it, especially since a compiler can do whatever it wants with all undefined and implementation defined behaviour in the standard.
gcc could have easily chosen to always initialise uninitialised local variables to 0 regardless of optimisations.
If gcc was strictly adhering to the C std it would tell you that int main() is undefined behaviour on hosted environments and implementation-defined on freestanding environments.
This is incorrect: Additional prototypes of main() are implementation-defined even on hosted implementations, so as long as gcc documents its behaviour, everything is fine as far as the standard is concerned.
However, this doesn't actually apply in this particular case: When a function declaration is part of a definition, an empty parameter list is equivalent to a prototype declaration with a single unnamed void parameter (see C99 6.7.5.3 10 and 14).
haha I love the but... do you?
I've programmed all of them professionally with multi-million line code bases and frankly... in recent years the extensions to C have made it a far more sophisticated language than ever. With extensions like variable length arrays in structs to allow for easier construction of classes (yes, they don't call them that, but they might as well) and things that just feel like hacked in RTTI, C has grown VERY sophisticated and even in some cases object-orientedish.
C++ has become a bit of a disaster. They have added ridiculous features like Lambas which may my rear end itch. They're a kinda neat feature in many ways, but I feel they will almost certainly be abused as opposed to used. It will attract JavaScript style programming which is painful to look at. I had hoped they would have added constructs for things like functional programming, but instead they made classes for that. The real problem with C++ in recent times is that the standard C++ library is a cludge of template on template on template. Also, with many companies I've encountered, we don't know how to treat the licensing for the templates when using GPL/LGPL implementations. It seems that since you're not linking to them so much as basing your code on them, even LGPL would require you to open source your code. It's a bit of a mess. So, we use Qt in most cases since it does everything the Standard C++ libraries do but without the licensing questions.
Objective-C is the least understood by the author of the article. There are certainly thousands of open source iPhone and Mac apps coming along, but it's VERY rare that a program is written in that language as opposed to wrapped in it. You have to code Objective-C to simply create an app, after that, you can use C, C++ or just about anything else (thank to SWIG) to write the rest of your app. If you look at the Mono.NET stuff which is REALLY popular as it's as easy as it gets, it compiles C# or CIL into Objective-C which is then compiled natively to the device. So, this can easily be considered writing in Objective-C, but in most circumstances, it would account for 1% or less of the actual program. The rest in C++, C# or C.
Now, I would be willing to believe that C# is quickly taking a high position in the open source since any C++ programmer can code it with almost no experience and it works on every platform known to man. Mac, Windows, Linux, iPhone, Android, Windows Phone... I don't know but maybe even Symbian. I even heard there's a Java back-end for it somewhere which could be used to make an app for BlackBerry... who the hell knows why... but there you have it. Oh.. and thanks to Unity3D, there's GOBS of C# apps.
C and C++ (from my reading of the latest standards) are virtually identical: they both require main to return an int in a hosted environment. In a freestanding environment, the startup function can be called by any name and with any return type that the implementation wants.
Thus, for hosted environments, 'void main' is specifically disallowed and GCC is doing the right thing.
Now, let's talk about freestanding environments. To say that void main() is "perfectly valid C" isn't quite right. It's certainly allowed under the C11 and C++11 standards, but by no means is GCC required to support it, as it's an implementation defined feature, and very target-dependent to begin with.
So, what we have is GCC supporting the standard, but whose implementation differs from other compilers. The devs made the choice to not support void main and that's perfectly fine. Nearly everybody who declares main as void are doing so in a hosted environment, and warnings/errors and completely justified.
I would never choose C++ because of it's "OO" features (classes and inheritance). I use it because of templates and operator overloading making it easy to write a lot of generic code which the compiler can inline and optimize for me. You could do similar stuff in C with macros but gets extremely clunky and it is very hard to get type safe.
The whole concept of OO programming is totally overrated. I like to use "interfaces" as defined in Java, but I must say I really dislike inheritance. In C++ you can be inspired both from Java and functional languages like ML. And you can do it semi low-level: You write it high-level but everything will become very simple and effective when compiled due to compiler optimization. Something you can not do with a language like Java - and can't do easily in C.
gcc could have easily chosen to always initialise uninitialised local variables to 0 regardless of optimisations.
That's true. And if my experiment had returned 0, then it would have been a useless result. But it didn't return zero. Instead, it returned garbage, thereby proving my hypothesis to a sufficient degree for the real world.
(In fact, if you turn on optimization, gcc does create a zero at compile time. So turning on optimization does not result in a useful experiment for this case.)
Would have diluted the rant. A good rant can't ramble, or it just sounds like raving. A sharp focus is necessary to drive the point home. And preferably grind it on bone.
I was talking about the capability of the language to build software, not a feature of the language(pointer usage).
Thanks.
because that is soooooooooo much better than just using C++.
We got the Web by NOT using OO.
You realize that the first web server and first web browser were written in Objective-C, right?
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
in C and C++ it is absolutely NOT an object. in Java and C# and other modern languages...sure, just like any other data type is an object.
The main in C and C++ differ. /*...*/ } or /*...*/ }
The main in C in hosted environments has been either
int main(void) {
int main(int argc, char *argv[]) {
since at least the C89 standard.
http://web.archive.org/web/20050207005628/http://dev.unicals.com/papers/c89-draft.html#2.1.2
C99/C11 Section 5.1.2.2.1
For freestanding environments the standard states that the name and type of the function called at program startup are implementation-defined.
So, yes void main() would be perfectly valid C if the freestanding environment requires it that way.
Obviously gcc doesn't have to support it or any freestanding environment.
I didn't imply it had to, I merely stated that gcc complains about one incorrect main in a hosted environment but not about another in a hosted environment.
The main in C++ in freestanding environments is, again, implementation-defined. /*...*/ } and /*...*/ }
In hosted environments the main shall have a return type of int but its type is implementation-defined.
Any implementation must at least support
int main() {
int main(int argc, char *argv[]) {
Has been like that since the C++98 standard, section 3.6.1.
In C int f(void) is a function with no parameters returning an int,
int f() is a function with no parameter specification returning an int.
They are not the same and should not be treated as such.
So, what we have is GCC supporting the standard, but whose implementation differs from other compilers. The devs made the choice to not support void main and that's perfectly fine. Nearly everybody who declares main as void are doing so in a hosted environment, and warnings/errors and completely justified.
No. What we have is gcc failing to support the most basic part of the C standard, rendering its -W flags at least questionable.
If it can't warn about an improper main, what else is it failing at?
All I really wanted to point out is that using some code and a compiler is no way to verify the standard.
I used main as an example because the OP wrote int main() in his "verification".
Actually, I was thinking at a cellular level, where a fork bomb is analogous to cancer, but that'd work too...
"I've got more toys than Teruhisa Kitahara."
Yeap. But if you are inexperienced enough to ask why OOP is important, as the GP did, then you probably haven't worked on many programs with more than 5k lines.
"First they came for the slanderers and i said nothing."
In C int f(void) is a function with no parameters returning an int,
int f() is a function with no parameter specification returning an int.
They are not the same and should not be treated as such.
This only applies to declarations which are not part of a definition. In particular,
int main() { ... }
and
int main(void) { ... }
are the same.
I stand corrected. Shame on me, I suppose.
No idea why 6.7.5.3p14 had slipped my mind so badly.
Certainly embarrassing enough.
Both C and C++ standards allow for other parameters to main():
The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters: /* ... */ } /* ... */ }
int main(void) {
or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) {
or equivalent;10) or in some other implementation-defined manner.
An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main: /* ... */ } /* ... */ }
int main() {
and
int main(int argc, char* argv[]) {
In the latter form argc shall be the number of arguments passed to the program from the environment in which the program is run. If argc is nonzero these arguments shall be supplied in argv[0] through argv[argc-1] as pointers to the initial characters of null-terminated multibyte strings (ntmbss) (17.5.2.1.4.2) and argv[0] shall be the pointer to the initial character of a ntmbs that represents the name used to invoke the program or "". The value of argc shall be non-negative. The value of argv[argc] shall be 0. [ Note: It is recommended that any further (optional) parameters be added after argv. —end note ]
You're right that there are some minor differences here. The value of argv[argc], for example. Is a C implementation required to support both basic forms? I'm not sure.
In C, however, the parameters to main() can be just about anything the implementation wants. In C++, other parameters are allowed, with the recommendation that additional parameters be placed after argv.
Meaning, the implementation is free to add extra parameters like:
int main(int argc, char *argv[], char *envp[])
or not have a parameter specification like:
int main()
Or just about anything else, in both C and C++. However, a return type of int is required.
GCC is doing the right thing. BTW, if you're in a freestanding environment, -ffreestanding disables the warning about 'void main' (as well as doing a few other important things).
(However, your point about not using a compiler to verify the standard is very much correct, even if we disagree on this particular situation.)
The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.
For all that, it is the componentization that is the source of the big gain. Having a reasonable degree of isolation and clearly defined interfaces makes things so much easier. OO is a somewhat fickle friend of this approach, especially when inheritance is used. Inheritance is a powerful and oft-misused tool. Some programmers, on finding a problem, think "I'll use inheritance to solve this!" After that, they don't have one problem, or two, but rather a whole family of needy child problems. (If only we could disable inheritance for all programmers who don't know what an "is-a" relationship actually is, we'd fix the problem with bad use of inheritance almost immediately. And there'd only be about 10 people worldwide who actually willingly used it in the first place.)
The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C.
I take it you're not including the time to compile in that?
More seriously, C++ most certainly has the potential to be slower than C, even without the problems of optimization. (C++ compilers optimize really rather well indeed; they damn well ought to, given how much compiler writing effort has been applied to them!) The real problem is that C++ programs tend to have more levels of indirection, and poorer data locality. That in turn hurts cache efficiency, which hits performance.
The other problem that plagues C++ code is a tendency to take ages for a process to shut down. That's caused mainly by the widespread use of the RAII style of coding (nonetheless a useful technique) and the way that on exit that leads to the C++ runtime wanting to neatly delete every single object. It's a theoretically laudable aim — after all, the object might need special action to release, even though that's rarely true for a majority of objects — but hurts rather a lot in a large program. It's particularly galling to know that the cost of getting everything that was paged out back into memory just to delete them is mainly wasted; the OS could reclaim far more efficiently by just reaping the process.
"Little does he know, but there is no 'I' in 'Idiot'!"
You now have two objects of type Button. Next you get specific.
okay.onClick(proceed());
cancel.onClick(abort());
This is terrible pseudocode butyou get the idea.
I'm glad you say that it's terrible, since you're registering the result of a function call with the button handler. While that might be what you intended, I somehow doubt it.
In general though, it's normal to deal with GUI objects through configuration and aggregation; subclassing to just set the color and add an "activated" callback is misuse. Instead, a subclass should add significant extra behavior, e.g., those buttons that also incorporate a menu dropdown to select variations on behavior. It's for those sorts of reasons that you use a subclass (assuming that the toolkit doesn't provide the widget already; if it does, writing your own is just dumb).
"Little does he know, but there is no 'I' in 'Idiot'!"
It is an object. It just doesn't have language support for being treated special. But for all intents and purposes, it's an object.
I'm not an iPerson, but I notice that most Android apps are simply ports of web applications. In that use case, simply making the original web site mobile-friendly is a better use of resources. I would predict that the fascination with mobile apps will go away when people realize this, and then Objective C will be a much less popular skill.
No....it isn't.