I said before that dynamic code creation and execution is a feature which is better supported by rule based scripting languages such as Lisp, and scheme.
There are times when this is usefull, and necessary, but these times are mainly limited to configuration and dynamic organization issues.
All of the issues that the above author mentioned as nescessary were NOT. They were only nescessary because his design was not well planned, nor well executed. This left various major flaws which could only be patched by this sort of *duct tape* flexibility.
The whole approach which you attack things from is the exact opposite angle that a C++ or OOP coder would approach it from. The point is WITH A GOOD DESIGN YOU DONT NEED OR USE THOSE FEATURES.
Lisp and Scheme have a very important place in development, but most people tend to agree that its for configuration and similar issues. NOT system development, NOT application development.
There is a reason for this. Until you appreciate the fact that design is paramount in C++ and that the entire development method differs significantly from proceedural or rule based languages, you will be eternally frustrated with its limitations. This is NOT a language flaw. It is user error.
In this case I AM blaming the above gripes on the programmer. The deisng of this individuals application is horrid, and hes passing off judgment on the language because of it. All of the issues I have seen him make so far with respect to C++ being a poor choice in light of Scheme or Python are due to implementation and design issues. And he obvously discounts these right off, as he knows what hes doing and how to utlize the powerful features of C++. That is the part thats pissing me off, and that is the part that I am criticizing...
And you refuse to accept responsiblity for the development process. At least if you continue to assert the fact that all the problems you mentioned COULD NOT HAVE BEEN PREVENTED with reviews, testing, and standard process.
I think your an offended VB Scripter that wishes he was coding linux candy...;)
Ok, nice goey CORBA ORB's on linux. What, you code GNOME and now your a professional expert?
If you were to argue cost / time constraints I would conceede the point. That would be the only remotely allowable exception for using untested, third party products and being bumfuzzled when you implement in production, and holy shit batman, our object server dropped core.
Whats done in the real world... hmm... nope.
Anyway, like I said, reviews, testing and skilled coders TOGETHER will provide for very stable, well designed systems. Not just one piece (He was a $100 an hour consultant!) or (It was the IDL Compilers fault!!).. but all together.
P.S. Do you work with CORBA in a production, real world environment?
And I think we need to make better coders. There is no reason a technically adept person and the right environment cant produce very stable, very well designed, and very efficient code. No reason at all.
Ok, you mentioned COM/DCOM?. Microsoft SUCKS ASS, all their components suck ass, and anyone using their shit best not expect anything that DOESNT suck ass.
If this wasnt a microsoft component, then a review would have caught that error. All of our thrid party libraries and components are thoroughly tested to catch these types of situations.
Furthermore, a review process would have caught that slack consultants code. Period.
Hey, good tools have been written with assembly! and assmebly sucks for development!
The tool may kick ass... i dont know.
But bad code doesnt ALWAYS mean a bad product. And great, eleagant code doesnt always mean a great product either. They are two separate pieces of the whole, although often related.
iterate through fooMap. Or locate a specific fooMap with long ID. if the FooYou list has only one entry, you have one Foobar == one Foo *. And if Foo * ever changes to an array of Foobar *, then your entire traversal and location logic is never touched.
Instead of thinking about what ISNT supported, think about a more standard and generic way to do what it is you are trying to do.
If you ever find yourself making the compiler do tricks, chances are your design sucks. Rethink the process.
So what are you trying to say? That they're turing complete? Not a very useful observation.
You said CANT be done in C++ but CAN be done and done fast and easy with Scheme. That was the bullshit I was stomping on.
Actually, the case I had in mind involved scanning all pointer members of all objects deriving from a specific class. In C++ this is very painful, because you don't have reflection.
Sorry, I cannot think of anything even remotely relevant where this would be nescessary. And EVEN if it were, a member method overidden by each derived class should handle this type of functionality. Again, this is a design issue, and as stated multiple times before, your design is horrible, and its causing all sorts of problems down the line.
The fact that someone who manages to write a tool like Lilypond (can't be an idiot), and also yourself, has to read lots and lots of books and learn through writing 10's of thousands of lines on how to really use the language, is not a good sign.
Hes not an idiot in the knowledge sense, but an idiot for refusing to accept the fact that he does NOT understand C++, and does not know how to write good code. The evidence is right there, written with his own hand, but until this individual realizes that his code has much room for improvement, it never will! This says nothing about the complexity of C++ in and of itself, other than the fact that some people consider themselves very skilled C++ coders because they managed to cludge together a pile of crap that doesnt drop core.
As for myself, I have about 5 years of exp. with C++ and two years now with STL. It is a big improvement (STL), I can write nice programs in C++ after all these years. BUT: I think it takes too long, and average people may never make it to understand the language and use it effectively.
I think the average person doesnt want to invest the effort into refining and honing their skills. Perhaps the mindset of the lillypond guy is indicative of the average C++ coder which would certainly explain why, after many years and lots of code, they STILL cant write C++ code that is worth the bytes its stored on.
Abstraction is not only nescessary, it is VITAL. And always will be. It is your tool of comprehension in the face of massive and nested / recursive complexity and chaos!
Anyone who says otherwise is a blind fool who is calling abstraction by another name.
10,000 monkeys with typewriters can write C++ code! so what?!?!
Some people have been coding for years and write shit code. It shouldnt be a surprise. Because they never learn and continually refine their skills as they go.
But there are also people who have only been coding for months that can write some very good C++. Its not about time frame, its about the developers commitment to self improvement, value and refinement of skills, and motivation. (lastly, mental capacity, but even this doesnt have much effect without the previous attirbutes)
You are wrong. The topic that we were discussing was a music typesetter specifically, and definitely not a 3D rendering engine.
No, you said algorithms are more efficient in a more expressive language such a scheme or python. You said nothing about music typesetting in that algorithm remark. And even if it is a music typesetter, I still maintain that C++ will provide a better and faster implementation.
I rest my case. You have no clue.
Sorry, scheme may be more suitable for certain types of expression, but C++ can be used to do anything scheme can, and can also do all the lower level things that scheme cant.
Some things may be prohibitvely hard to do, such as on the fly code generation and execution, but they are still possible with C++. This is one area where scheme would obviously be more efficient, but it doesnt sound like those are the types of algorithms we are talking about.
If what you have in mind specifically is more suited for a scripted or rule based approach, then USE scheme or Python. but DONT make blanket statements that C++ is bad and Scheme is good because of your misconcpetions about OOD/OOP and what good code is.
What I am talking about is when there is no such thing as "data member integrity".
This is in the land of BAD CODE. Period.
The part of the program that was the most incestuous with objects is undergoing this transformation right now, but the "objects" are going to be scheme functions, because what I want the program to do can't be expressed in C++ conveniently.
At least you admit it was bad design. Scheme may very well be a great choice for the implementation of that piece of code, that wasnt my point though. It is the FACT that public data members are not only BAD, they are VERY BAD, and violate the msot basic concepts of OOP or even good coding practice in general.
Maybe you should read, erm, study the following quote by Bjarne Stroustrup:
OOP wasn't a panacea. [..] [OOP] just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies.
Correct. So use SOMETHING ELSE, but dont try and use a bastardized class. That is WRONG. Im sorry if youve convinced yourself otherwise, by thinking, wow, for 3 hours I thought about this and I cant think of a better way. There must not be one so lets break some fundamental guidlines.
I will repeat. This is a DESIGN ISSUE! Just because you dont understand C++ and the design required for that peice of the code doesnt mean you are right, and can violate all sorts of common practice without thought of correction or pending consequence. This kind of code is crap. Pure crap. Sorry, but I dont think any other means of explaining it will get the point across.
It's very well documented that you get more speed increase from better algorithms than from small optimizations (such as eliminating type checks).
Yes, and in algorithm design you learn about optomizing those tight little nested loops. Its the iterative processes where small impacts add up to huge overall effects. By your (flawed) logic all 3D renger engines should be written in Python or Scheme! Cmon man, think about it. Anything you can write in Python or Scheme you can write in C or C++. And it all likelihood it will be MORE efficient, probably much more so. Period.
In a more expressive language (like Python or Scheme), you have more ways to write code, so you get more chances to use better algorithms; this is in fact something that happened when we used the Scheme interpreter in LilyPond.
Thats because you dont understand C++. End of story. C++ is FAR more expressive and extendible than either of those languages. Not that the expressiveness of a language has anything to do with an algorithm. An algorithm DESIGN should be completely separate from its language dependant IMPLEMENTATION. And an algorithm written in C/C++ will always outperform Python / Scheme
It takes brains that think on many levels to write good C++ code.
Those brains dont congeal in hard skulls very often.
That is the problem. Most of the developers out there that DO write bad code could read until they are blue in the face and STILL not *get it*. I read X number of books on Y. I know what im doing!
This is EXACTLY the type of mentality that is a SCOURGE! yes, a SCOURGE! i cannot bash this type or arogant, self righteous ignorance enough. WAKE UP!! It is YOUR skills at risk, YOUR code that is affected. It is entirely worth your while to drop the expert fascade and think about everything your doing as if it may be wrong. Guess what, everytime you find something that can be implemented or organized in a better / more efficient manner. You may not be flat wrong most fo the time, but there is ALWAYS room for improvement.
One thing that bothers me about C++ protection zealotism (encapsulation, if you will) is that it assumes that behavior is something that can be encapsulated within one class
Wrong! this isnt about bahavior. Its about abstraction and class data member integrity. You are confusing the two.
Putting private: everywhere constrains the code, because it forces particular code to be in a particular class
Wrong! It constrains code by restricting access to private, implementation details. The only public parts of a class should be the interface methods which access the information and functionality represented by the given class. Again, your confusing issues. If you dont want constraints, use C and make everything global! Constraints are your friend, not your enemy.
The result is that half of the code is in a class where it belongs, and the other half is not. Moving the variable to a different class merely switches the halves.
Wrong! This is a design issue, not a language issue. Functionality shared between objects should be abstracted into a separate object, or the two objects collated into one (if appropriate, though not likely in this case). It sounds like what has happened in your case is that you didnt spend enough time upfront with design. Design is much much more important in large OO systems than with any other type of implementation. If you dont do your deisgn right up front, you get problems like you have mentioned.
In any case, my default mode is prototyping, and making everything public. The moment that a reason for encapsulation emerges, I make the relevant variables private, and the compiler catches all encapsulation violations for me. These are usually trivially to upgrade to a new interface.
This is NOT OOP! I repeat, NOT OOP! This is a red headed stepchild of OOP!
In fact, I've read it cover to cover. I learned C++ from it.
There is a difference between reading a book and studying it.
You dont understand OOD or OOP with C++. Period. Its blatantly obvious. If you really want to know where your vargs went the way of the dinosaur go pick up a book on OOD. Then think about large software systems. Think about distributed software development. Think about abstracted flexibility and scalability.
Sure, for converting JPEG to TIFF you wouldnt even need an object most likely. That would be a member method of Image which could read any image format and export in any format and all it would take is a
ImageObject.write(gifFIle);
oh, you want a JPEG?
ImageObject.write(jpegFile);
So, do yourself a favor and actually take the time to understand what OOD/OOP is about.
My point was with the proper precautions in place, like code reviews, talented developers with experience, thorough testing and profiling, you CAN eliminate bad code from ever joining your source pool. And everything built on top of that will have a stable foundation.
I do agree that a large number of developers are NOT good coders, and that needs to change. The smart companies hire $50-$100 an hour consultants with extensive experience and form teams with these individuals. You could do the same with selective hiring and thorough evaluations, but nowadays comapnies are so needy for talent that they will accept mediocre developers and ignore the negative impact they may have on the entire development lifecycle.
A talented team and implementing the above precautions will give you a very robust, very stable software system.
And then one day, after programming for a long number of years (it may be 2, but thats a long 600+ days!) you realize that it is all gravy.
Yes, coding is just a big pile of your mothers fresh cooked tasty gravy.. mmmmm mmmm yeah..
You see, in the begging was the logic gate. And it gave birth to the integrated circuit. And you programmed those by connecting little wires. And then they sprang forth and multiplied until they were VLSI's which old beardy d00ds and young hacker punks coded with reams of elegant and obscure assmebly calls. And the assembly was a horny bastard, and gave rise to many bastard children like COBOL, Pascal, Lisp, C, Ada, Fortran, C++.. some of them less bastardy than the others..
And upon these good features were taken and incorportated, deriviations thrived.
And you wake up one day and realize that its all a different shade of the same little bits flipping in your logic gates in silicon wafer.
Because, after all, you were just building pieces.. linking them together. Aggregation, Abstraction, Encapsulation, Polymorphism. It was all occuring long before we even knew what is was and in various degrees of completeness.
So you see, the true coder will see the advantages of a OO outlook on development. See its value in addition to the regular, algorithmic logic of proceedural code. And design patterns, objectless design, and all the other future meta abstraction possibilities will have their place as well. They are tools in the coders pocket, ready to use when applicable and well suited to a given task.
We have only begun to build our gleaming cities of logic, and the need for flexible and plentiful abstraction techniques will be a need long into the future. All our pieces today providing for the framework of tomorrows systems.
Flexibility, Extensibility, Reusability are the goals of the far sighted code poet.
Fill your little hacker mind with all the goodness that is rule based, proceedural, OO, and abstract possibility.
n my case EJBoss is based on many 3rd party libraries (BullSoft, IBM, SUN, W3C, Apache, Dreambean, Telkel). That REUSE is possible given that java comes with bytecode format and a DEFACTO ABI..
What are you trying to say? That C++ applications cant use thrid party libraries? Oh wait, your only saying that you dont have to relink. Well, that little convienance comes at a price. Namely big fat binaries with lots of added overhead.
The reason STL is so nice is because it IS a language standard, and is wonderfully extensible and usable.
OOP Resuse is VERY alive in C++. Your an ignorant fool if you are suggesting otherwise. And its the very generic features of C++ (templates, multiple inheritance) that provide this ability to reuse code. Your only point has to do with cross platform portability which is a very minor issue is most code reuse situations. In C++ cross platform portability may be some added work, but its worth it given the features of the language.
Your preaching Java from the wrong angle and with false pretence.
And good programmers dont write bad code. You can write a half million line code system in C++ and not have any memory leaks or pointer errors. It is possible, and in good programming teams, with reviews and standards, this is a minor issue. These errors are programmers faults, not language faults. They arise because of the POWER of the language. Sure you can use a less powerfull Java implementation, and it may be well suited for the development task at hand. But there is always a trade off. It will be slower, fatter, and have less features available to the coders.
Its a design decision in the end, and personally I think more time should be spent making better coders, than writing more abstracted, fatter, less powerfull tools.
Slashdot Mirror
I said before that dynamic code creation and execution is a feature which is better supported by rule based scripting languages such as Lisp, and scheme.
There are times when this is usefull, and necessary, but these times are mainly limited to configuration and dynamic organization issues.
All of the issues that the above author mentioned as nescessary were NOT. They were only nescessary because his design was not well planned, nor well executed. This left various major flaws which could only be patched by this sort of *duct tape* flexibility.
The whole approach which you attack things from is the exact opposite angle that a C++ or OOP coder would approach it from. The point is WITH A GOOD DESIGN YOU DONT NEED OR USE THOSE FEATURES.
Lisp and Scheme have a very important place in development, but most people tend to agree that its for configuration and similar issues. NOT system development, NOT application development.
There is a reason for this. Until you appreciate the fact that design is paramount in C++ and that the entire development method differs significantly from proceedural or rule based languages, you will be eternally frustrated with its limitations. This is NOT a language flaw. It is user error.
End of story.
In this case I AM blaming the above gripes on the programmer. The deisng of this individuals application is horrid, and hes passing off judgment on the language because of it. All of the issues I have seen him make so far with respect to C++ being a poor choice in light of Scheme or Python are due to implementation and design issues. And he obvously discounts these right off, as he knows what hes doing and how to utlize the powerful features of C++. That is the part thats pissing me off, and that is the part that I am criticizing...
And you refuse to accept responsiblity for the development process. At least if you continue to assert the fact that all the problems you mentioned COULD NOT HAVE BEEN PREVENTED with reviews, testing, and standard process.
;)
I think your an offended VB Scripter that wishes he was coding linux candy...
I am most definately an alien species.
.. but all together.
Ok, nice goey CORBA ORB's on linux. What, you code GNOME and now your a professional expert?
If you were to argue cost / time constraints I would conceede the point. That would be the only remotely allowable exception for using untested, third party products and being bumfuzzled when you implement in production, and holy shit batman, our object server dropped core.
Whats done in the real world... hmm... nope.
Anyway, like I said, reviews, testing and skilled coders TOGETHER will provide for very stable, well designed systems. Not just one piece (He was a $100 an hour consultant!) or (It was the IDL Compilers fault!!)
P.S. Do you work with CORBA in a production, real world environment?
And I think we need to make better coders. There is no reason a technically adept person and the right environment cant produce very stable, very well designed, and very efficient code. No reason at all.
Anything is is a cop out IMHO.
Ok, you mentioned COM/DCOM?.
Microsoft SUCKS ASS, all their components suck ass, and anyone using their shit best not expect anything that DOESNT suck ass.
If this wasnt a microsoft component, then a review would have caught that error. All of our thrid party libraries and components are thoroughly tested to catch these types of situations.
Furthermore, a review process would have caught that slack consultants code. Period.
Go back to your Visual Basic.
DOWN!!! DOWN WITH THE COBOL CODERS AND VB SCRIPT KIDDIES!!! DIIEEEEEE!!!
Hey, good tools have been written with assembly! and assmebly sucks for development!
The tool may kick ass... i dont know.
But bad code doesnt ALWAYS mean a bad product. And great, eleagant code doesnt always mean a great product either. They are two separate pieces of the whole, although often related.
typedef Foo* foobar;
typedef vector fooYou;
typedef map > fooMap;
iterate through fooMap. Or locate a specific fooMap with long ID. if the FooYou list has only one entry, you have one Foobar == one Foo *. And if Foo * ever changes to an array of Foobar *, then your entire traversal and location logic is never touched.
Instead of thinking about what ISNT supported, think about a more standard and generic way to do what it is you are trying to do.
If you ever find yourself making the compiler do tricks, chances are your design sucks. Rethink the process.
cout "#!/usr/bin/perl" endl;
cout "print \"Hello World!\";" endl;
ehehe.. of course! IM NEVER WRONG!!! NEVER!!!
So what are you trying to say? That they're turing complete? Not a very useful observation.
You said CANT be done in C++ but CAN be done and done fast and easy with Scheme. That was the bullshit I was stomping on.
Actually, the case I had in mind involved scanning all pointer members of all objects deriving from a specific class. In C++ this is very painful, because you don't have reflection.
Sorry, I cannot think of anything even remotely relevant where this would be nescessary. And EVEN if it were, a member method overidden by each derived class should handle this type of functionality. Again, this is a design issue, and as stated multiple times before, your design is horrible, and its causing all sorts of problems down the line.
The fact that someone who manages to write a tool like Lilypond (can't be an idiot), and also yourself, has to read lots and lots of books and learn through writing 10's of thousands of lines on how to really use the language, is not a good sign.
Hes not an idiot in the knowledge sense, but an idiot for refusing to accept the fact that he does NOT understand C++, and does not know how to write good code. The evidence is right there, written with his own hand, but until this individual realizes that his code has much room for improvement, it never will! This says nothing about the complexity of C++ in and of itself, other than the fact that some people consider themselves very skilled C++ coders because they managed to cludge together a pile of crap that doesnt drop core.
As for myself, I have about 5 years of exp. with C++ and two years now with STL. It is a big improvement (STL), I can write nice programs in C++ after all these years. BUT: I think it takes too long, and average people may never make it to understand the language and use it effectively.
I think the average person doesnt want to invest the effort into refining and honing their skills. Perhaps the mindset of the lillypond guy is indicative of the average C++ coder which would certainly explain why, after many years and lots of code, they STILL cant write C++ code that is worth the bytes its stored on.
Ahaha.. I eschew Charlie Moore!
Abstraction is not only nescessary, it is VITAL. And always will be. It is your tool of comprehension in the face of massive and nested / recursive complexity and chaos!
Anyone who says otherwise is a blind fool who is calling abstraction by another name.
10,000 monkeys with typewriters can write C++ code! so what?!?!
Some people have been coding for years and write shit code. It shouldnt be a surprise. Because they never learn and continually refine their skills as they go.
But there are also people who have only been coding for months that can write some very good C++. Its not about time frame, its about the developers commitment to self improvement, value and refinement of skills, and motivation. (lastly, mental capacity, but even this doesnt have much effect without the previous attirbutes)
You are wrong. The topic that we were discussing was a music typesetter
specifically, and definitely not a 3D rendering engine.
No, you said algorithms are more efficient in a more expressive language such a scheme or python. You said nothing about music typesetting in that algorithm remark. And even if it is a music typesetter, I still maintain that C++ will provide a better and faster implementation.
I rest my case. You have no clue.
Sorry, scheme may be more suitable for certain types of expression, but C++ can be used to do anything scheme can, and can also do all the lower level things that scheme cant.
Some things may be prohibitvely hard to do, such as on the fly code generation and execution, but they are still possible with C++. This is one area where scheme would obviously be more efficient, but it doesnt sound like those are the types of algorithms we are talking about.
If what you have in mind specifically is more suited for a scripted or rule based approach, then USE scheme or Python. but DONT make blanket statements that C++ is bad and Scheme is good because of your misconcpetions about OOD/OOP and what good code is.
Allright, my patience is tested...
What I am talking about is when there is no such thing as "data member integrity".
This is in the land of BAD CODE. Period.
The part of the program that was the most incestuous with objects is undergoing this transformation right now, but the "objects" are going to be scheme functions, because what I want the program to do can't be expressed in C++ conveniently.
At least you admit it was bad design. Scheme may very well be a great choice for the implementation of that piece of code, that wasnt my point though. It is the FACT that public data members are not only BAD, they are VERY BAD, and violate the msot basic concepts of OOP or even good coding practice in general.
Maybe you should read, erm, study the following quote by Bjarne Stroustrup:
OOP wasn't a panacea. [..] [OOP] just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies.
Correct. So use SOMETHING ELSE, but dont try and use a bastardized class. That is WRONG. Im sorry if youve convinced yourself otherwise, by thinking, wow, for 3 hours I thought about this and I cant think of a better way. There must not be one so lets break some fundamental guidlines.
I will repeat. This is a DESIGN ISSUE! Just because you dont understand C++ and the design required for that peice of the code doesnt mean you are right, and can violate all sorts of common practice without thought of correction or pending consequence. This kind of code is crap. Pure crap. Sorry, but I dont think any other means of explaining it will get the point across.
It's very well documented that you get more speed increase from better algorithms than from small optimizations (such as eliminating type checks).
Yes, and in algorithm design you learn about optomizing those tight little nested loops. Its the iterative processes where small impacts add up to huge overall effects. By your (flawed) logic all 3D renger engines should be written in Python or Scheme! Cmon man, think about it. Anything you can write in Python or Scheme you can write in C or C++. And it all likelihood it will be MORE efficient, probably much more so. Period.
In a more expressive language (like Python or Scheme), you have more ways to write code, so you get more chances to use better algorithms; this is in fact something that happened when we used the Scheme interpreter in LilyPond.
Thats because you dont understand C++. End of story. C++ is FAR more expressive and extendible than either of those languages. Not that the expressiveness of a language has anything to do with an algorithm. An algorithm DESIGN should be completely separate from its language dependant IMPLEMENTATION. And an algorithm written in C/C++ will always outperform Python / Scheme
It takes brains that think on many levels to write good C++ code.
Those brains dont congeal in hard skulls very often.
That is the problem. Most of the developers out there that DO write bad code could read until they are blue in the face and STILL not *get it*. I read X number of books on Y. I know what im doing!
This is EXACTLY the type of mentality that is a SCOURGE! yes, a SCOURGE! i cannot bash this type or arogant, self righteous ignorance enough. WAKE UP!! It is YOUR skills at risk, YOUR code that is affected. It is entirely worth your while to drop the expert fascade and think about everything your doing as if it may be wrong. Guess what, everytime you find something that can be implemented or organized in a better / more efficient manner. You may not be flat wrong most fo the time, but there is ALWAYS room for improvement.
One thing that bothers me about C++ protection zealotism (encapsulation, if you will) is that it assumes that behavior is something that can be encapsulated within one class
Wrong! this isnt about bahavior. Its about abstraction and class data member integrity. You are confusing the two.
Putting private: everywhere constrains the code, because it forces particular code to be in a particular class
Wrong! It constrains code by restricting access to private, implementation details. The only public parts of a class should be the interface methods which access the information and functionality represented by the given class. Again, your confusing issues. If you dont want constraints, use C and make everything global! Constraints are your friend, not your enemy.
The result is that half of the code is in a class where it belongs, and the other half is not. Moving the variable to a different class merely switches the halves.
Wrong! This is a design issue, not a language issue. Functionality shared between objects should be abstracted into a separate object, or the two objects collated into one (if appropriate, though not likely in this case). It sounds like what has happened in your case is that you didnt spend enough time upfront with design. Design is much much more important in large OO systems than with any other type of implementation. If you dont do your deisgn right up front, you get problems like you have mentioned.
In any case, my default mode is prototyping, and making everything public. The moment that a reason for encapsulation emerges, I make the relevant variables private, and the compiler catches all encapsulation violations for me. These are usually trivially to upgrade to a new interface.
This is NOT OOP! I repeat, NOT OOP! This is a red headed stepchild of OOP!
In fact, I've read it cover to cover. I learned C++ from it.
There is a difference between reading a book and studying it.
You dont understand OOD or OOP with C++. Period. Its blatantly obvious. If you really want to know where your vargs went the way of the dinosaur go pick up a book on OOD. Then think about large software systems. Think about distributed software development. Think about abstracted flexibility and scalability.
Sure, for converting JPEG to TIFF you wouldnt even need an object most likely. That would be a member method of Image which could read any image format and export in any format and all it would take is a
ImageObject.write(gifFIle);
oh, you want a JPEG?
ImageObject.write(jpegFile);
So, do yourself a favor and actually take the time to understand what OOD/OOP is about.
My point was with the proper precautions in place, like code reviews, talented developers with experience, thorough testing and profiling, you CAN eliminate bad code from ever joining your source pool. And everything built on top of that will have a stable foundation.
I do agree that a large number of developers are NOT good coders, and that needs to change. The smart companies hire $50-$100 an hour consultants with extensive experience and form teams with these individuals. You could do the same with selective hiring and thorough evaluations, but nowadays comapnies are so needy for talent that they will accept mediocre developers and ignore the negative impact they may have on the entire development lifecycle.
A talented team and implementing the above precautions will give you a very robust, very stable software system.
And then one day, after programming for a long number of years (it may be 2, but thats a long 600+ days!) you realize that it is all gravy.
Yes, coding is just a big pile of your mothers fresh cooked tasty gravy.. mmmmm mmmm yeah..
You see, in the begging was the logic gate. And it gave birth to the integrated circuit. And you programmed those by connecting little wires. And then they sprang forth and multiplied until they were VLSI's which old beardy d00ds and young hacker punks coded with reams of elegant and obscure assmebly calls. And the assembly was a horny bastard, and gave rise to many bastard children like COBOL, Pascal, Lisp, C, Ada, Fortran, C++.. some of them less bastardy than the others..
And upon these good features were taken and incorportated, deriviations thrived.
And you wake up one day and realize that its all a different shade of the same little bits flipping in your logic gates in silicon wafer.
Because, after all, you were just building pieces.. linking them together. Aggregation, Abstraction, Encapsulation, Polymorphism. It was all occuring long before we even knew what is was and in various degrees of completeness.
So you see, the true coder will see the advantages of a OO outlook on development. See its value in addition to the regular, algorithmic logic of proceedural code. And design patterns, objectless design, and all the other future meta abstraction possibilities will have their place as well. They are tools in the coders pocket, ready to use when applicable and well suited to a given task.
We have only begun to build our gleaming cities of logic, and the need for flexible and plentiful abstraction techniques will be a need long into the future. All our pieces today providing for the framework of tomorrows systems.
Flexibility, Extensibility, Reusability are the goals of the far sighted code poet.
Fill your little hacker mind with all the goodness that is rule based, proceedural, OO, and abstract possibility.
Code!
n my case EJBoss is based on many 3rd party libraries (BullSoft, IBM, SUN, W3C, Apache, Dreambean, Telkel). That REUSE is possible given that java comes with bytecode format and a DEFACTO ABI..
What are you trying to say? That C++ applications cant use thrid party libraries? Oh wait, your only saying that you dont have to relink. Well, that little convienance comes at a price. Namely big fat binaries with lots of added overhead.
The reason STL is so nice is because it IS a language standard, and is wonderfully extensible and usable.
OOP Resuse is VERY alive in C++. Your an ignorant fool if you are suggesting otherwise. And its the very generic features of C++ (templates, multiple inheritance) that provide this ability to reuse code. Your only point has to do with cross platform portability which is a very minor issue is most code reuse situations. In C++ cross platform portability may be some added work, but its worth it given the features of the language.
Your preaching Java from the wrong angle and with false pretence.
Its a trade off.
And good programmers dont write bad code. You can write a half million line code system in C++ and not have any memory leaks or pointer errors. It is possible, and in good programming teams, with reviews and standards, this is a minor issue. These errors are programmers faults, not language faults. They arise because of the POWER of the language. Sure you can use a less powerfull Java implementation, and it may be well suited for the development task at hand. But there is always a trade off. It will be slower, fatter, and have less features available to the coders.
Its a design decision in the end, and personally I think more time should be spent making better coders, than writing more abstracted, fatter, less powerfull tools.