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.
C's philosophy doesn't integrate well with Ayn Rand's.
There's no -1 for "I don't get 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!).
typedef struct { // And data goes here.
int (*open)(void *self, char *fspec);
int (*close)(void *self);
int (*read)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
int (*write)(void *self, void *buff, size_t max_sz, size_t *p_act_sz);
} tCommClass;
http://stackoverflow.com/questions/351733/can-you-write-object-oriented-code-in-c
"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.
you are aware that the first C++ compilers simply generated C code from the C++ then compiled to that.
Oh, and I've seen several OO languages written in C as well, that some senior engineer who "didn't trust C++" came up with. The only thing you don't get with these is enforcement of visibility with private/public, which isn't strictly required for OO. But polymorphism and the lot, yup, all that was there.
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.
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.
BS!
I have written fast programs in both Java and C# that are maybe 10% slower than pedal to the metal C or C++.
Good for you: for i = 1 to 100 is pretty fast in any language.
Now try doing complex signal processing in Java.
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.
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.
Enforecement of public private can be done: simply have your base object struct have a void pointer field called private and declare and allocate a private data struct as static in the .c implementation of the class. Voila, private fields and methods as needed.
Craft Beer Programming T-shirts
Of course you can write object-oriented code in C. It has been done many times.
An object-oriented language has lots of syntactic help for the purpose, but all languages compile to some type of runtime code structure. If you understand what code gives the object-oriented behavior you want, then you can write it in C.
And yes, the poster who said C was assembler-like likely has never seen an assembler language, I would guess. I do remember writing a C routine once which had an initialized array containing hex representations of machine code to do a particular highly specialized task, and then using some coding wizardry to get the locus of control into that array when needed. Ah, those were the days.
Considering that C++ was originally implemented as a preprocessor for C, there's an existence proof that says you are wrong.
This survey is skewed by iOS developers trowelling out tons of appstore apps of questionable utility.
Kriston
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.
You can write object oriented code in assembler if you want.
It's easier to write object oriented code if the compiler supports syntactic sugar around the pillars of object oriented code (inheritance, polymorphism, encapsulation, message passing, etc.) but such syntactic sugar is not strictly needed.
doesn't need to be void, even. (I'm sure purists will complain about _t being reserved)
[header file] ...
typedef struct something_s something_t;
something_t *private stuff;
[C file] ...
struct something_s {
};
I use this sort of construct quite a lot.
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
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.
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
And yes, the poster who said C was assembler-like likely has never seen an assembler language,
C doesn't look like 6502 or 1802 or 10f220 assembly, but if you squint you can see some PDP-11 addressing modes in there. Because a primary dev box was a ....
Also I see aspects of BAL from MVS370 but maybe thats just dead brain cells flickering.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
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...
Except that if you read his code, he's not actually subclassing Button, he's instantiating it. He's certainly saying it wrong, though.
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?
So, you think that is object-orientation? Oh boy.
From wikipedia: "Object-oriented programming (OOP) is a programming paradigm using "objects" - data structures consisting of data fields and methods together with their interactions - to design applications and computer programs."
The GP's method certainly qualifies. Just because it doesn't include all the sugary syntax or features that are included in your favorite so-called "OOP language" doesn't mean that you can't do object-oriented programming in C.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
Oh, but it is. C is actually very, very close to assembly language, with only the most unimportant CPU-specific details abstracted away. The primitive types in C are almost always natively supported by the CPU in assembly language, with few exceptions. Instead of having to manage your own stack, it mostly manages it for you, but it still leaves plenty of room for shenanigans, particularly because it doesn't enforce the number of arguments any more than asm does. And if you use varargs, you pretty much are doing direct accesses to the stack using indexed addressing. Simple asm.
Accesses to a struct are just a tiny bit of syntactic sugar on top of an indexed load/store. Goto is a jmp, setjmp and longjmp just set a register and then perform a jump to that address The if/then commands have near exact ASM equivalents (albeit with a couple of extra jump instructions thrown in), and even while loops are just a couple of instructions (not counting whatever calculations must be performed to determine which path to take).
C abstracts away some stack management details, register quantity limits, etc., but it really is little more than portable assembly language, by design. It was intended for systems-level programming, and does that job well, in part because it is such a thin layer compared with most other languages.
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:
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.
I didn't know they retired the C preprocessor.
Rethinking email
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
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
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?
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.
I think that falls under "you don't always need the language to hold your hand."
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
I think that falls under "I hope to the great FSM that I never have to maintain your code."
-1 overrated isn't the same thing as "I disagree".
I think that if there's only 5 obj-c jobs in the Denver area, it probably means it's not a very useful skill.
What it means to me is that Denver is not quite the hotbed of development activity that you seem to believe it is.
You are aware that Denver metro is second in the number of tech jobs in the country, losing out only to silicon valley?
That's news to me. The last time I was looking to hire someone in Denver, I had about fifty applications for the gig. As for Denver being "second only to silicon valley", I'd need to see a source on that. Judging by the headhunter pings I get, you're way behind NYC, DC, LA, Chicago, Los Angeles, Seattle and Atlanta.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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."
You don't need to get to functions pointers if you don't need polymorphism. It's like making (in C++) all methods virtual just for fun. You can have static OOP in C:
typedef struct FileClass;
int FileClass_open(FileClass* this, char* fileName);
int FileClass_close(FileClass* this);
int FileClass_read(FileClass* this, void* in, size_t size, size_t* actualSize);
int FileClass_write(FileClass* this, void* out, size_t size, size_t* actualSize);
typedef struct {
} FileClass;
int FileClass_open(FileClass* this, char* fileName) {
thisc->data
}
FileClass class;
int ret = FileClass_open(&class, "filename.txt");
Btw, I'm not a system developer so I'm using names that are not acronyms. Are there still so many C compilers that can't handle names with more then 8 letters? I wish C would get namespaces, so I don't have to write FileClass_ prefix so it won't collide with the C standard libraries.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
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.
I find it hilarious that Obj-C is ranked so far above something like Javascript. These indexes are meant to rate popularity, right? So subjective qualitative WTF-is-wrong-with-your-language arguments aside, the sheer volume of Javascript programming going on in browsers (that includes a large portion of phone-based software in webapps built for phones) should surely dwarf Obj-C. I also find that JS questions tend to dominate SO, too, much more so than Java, Obj-C, or C/C++. In fact, the numbers from SO are:
231,861 questions tagged 'Javascript'
91,526 questions tagged 'Objective-c'
So as you say, I can't find these indices valid at all, as they fail horribly to be accurate. For instance, the transparent index lists JS as a "script language." Nice.
The first "real" OO language was Simula 67, and in fact it's a direct ancestor of C++ - if you look at Simula, you suddenly realize that the first version of C++ was more or less C with Simula OOP constructs grafted on top (this is where "virtual" came from, by the way).
If you look at the description of how they compute the index, it's essentially useless for any practical purpose. So why even bother debating it?
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.
I wish C would get namespaces, so I don't have to write FileClass_ prefix so it won't collide with the C standard libraries.
#define CLASS_MEMBER(return_type, p...) CLASS_MEMBER2(CLASS_NAME, return_type, p)
#define CLASS_MEMBER2(class_name, return_type, p...) CLASS_MEMBER3(class_name, return_type, p)
#define CLASS_MEMBER3(class_name, return_type, member_name, params...) return_type class_name##_##member_name(class_name *this, ##params)
#undef CLASS_NAME
#define CLASS_NAME FileClass
CLASS_NAME(int, open, char* fileName);
CLASS_NAME(int, close);
CLASS_NAME(int, read, void* in, size_t size, size_t* actualSize);
CLASS_NAME(int, write, void* out, size_t size, size_t* actualSize);
I'll leave it to you to figure out how to use this pattern to #define namespaces. Also, there's a *lot* more you can do with the preprocessor if you really push it.
Note: ', ##' might be a GCC-only extension.
Yes, but keep in mind. The C preprocessor is the only thing that stands in between the sanity of the average C programmer and the great void.
Doesn't sound like you know what OOD is. That method qualifies, and you also get inheritance and polymorphism. Perhaps you shouldn't be so smug next time?
It's not being smug when it's about pointing the folly of reinventing the wheel, poorly, out of a square block and claim that it is a wheel. You guys are the MadTV Stuarts of software development (ma, look what I can do.... with structs and pointers to callback functions.)
One could say that programming in assembly using nothing but unconditional jumps and cond jumps is just the same as structured programming because, after all, structured programming will get translated to its assembly/machine language jump-based equivalent.
Or functional programming is nothing but pointers to functions...
For that matter one could have an array of locations one can jump to in assembler and call it OO (not OOD or OOP as those are somewhat different animals stemming from OO). You can simulate inheritance, and you can simulate polymorphism... with a lot of elbow grease.
Now, I'm going to slow it down for you one more time. Here is the operative expression.... a lot of elbow grease In the GPP's example, you have to extensively rely on programming by convention to make sure
The last part is the most important one. Message is the meat of OO. Everything else is just gravy. And the transparent message dispatching mechanism that makes OO economical is being thrown out of the window (along a lot of other things) with the GPP's supposedly good example.
Now, there are situations where this approach is useful (I've used it myself for building plugga
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.