C++/Fido.net/Memories
-
Was just remembering old times when I was still programming plain C and had virgorous fights about the usefulness of C++ and OOP on FIDO net :) Me fighting on the C side of course :suss: Ahhh, silly old times. Long years ago.
Off to in ~87 days
I was always on the C side also. Still am :) C++ is simply not quite as close to the machine as C was and I miss it. But I guess progress and evolution in languages and the need to make it easier for those less skilled tecnically forces us to accept things that we really don't want to. Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
-
I was always on the C side also. Still am :) C++ is simply not quite as close to the machine as C was and I miss it. But I guess progress and evolution in languages and the need to make it easier for those less skilled tecnically forces us to accept things that we really don't want to. Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
How is C++ any less "close to the machine" than C? William E. Kempf
-
How is C++ any less "close to the machine" than C? William E. Kempf
If you had to ask then you wouldn't understand the answer :) Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
-
If you had to ask then you wouldn't understand the answer :) Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
Richard Stringer wrote: If you had to ask then you wouldn't understand the answer LOL! Jeremy Falcon Imputek
-
If you had to ask then you wouldn't understand the answer :) Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
Uhmm... no. Not hardly a legitimate answer. Trust me, I could understand the answer... but the chances are I'd have to disagree with you. There is nothing intrinsic to the C++ language that makes it less low-level than C. Nothing. People who make the claim you have usually mistake the presence of higher level constructs as an indication that the lower level constructs aren't there, which is not the case. William E. Kempf
-
Uhmm... no. Not hardly a legitimate answer. Trust me, I could understand the answer... but the chances are I'd have to disagree with you. There is nothing intrinsic to the C++ language that makes it less low-level than C. Nothing. People who make the claim you have usually mistake the presence of higher level constructs as an indication that the lower level constructs aren't there, which is not the case. William E. Kempf
Yeah, but in pratice C++ programmers aren't taught that. C++ pushes OOP; OOP pushes abstraction, and it all fits hand-in-hand. Jeremy Falcon
-
Yeah, but in pratice C++ programmers aren't taught that. C++ pushes OOP; OOP pushes abstraction, and it all fits hand-in-hand. Jeremy Falcon
A slightly better description... but even that is full of FUD. Abstraction, by itself, does not equal performance degradation or over use of resources. You can create extremely efficient OOP designs. More over, C++ has proven to allow even greater flexibility and performance than C in many areas. For example, Blitz and other such numerical template libraries, out strip C and rival Fortran for complex scientific calculations. Are the high level features of C++ abused by the ignorant? You bet. But then, few developers produce efficient C code, as well. If you have the attitude that C++ is too high level, you shouldn't be using C. You should be coding in Assembler. As someone who's coded a lot in all three... I'll pick C++ over C every time, and C++ over Assembler in all but the most critical areas. William E. Kempf
-
Uhmm... no. Not hardly a legitimate answer. Trust me, I could understand the answer... but the chances are I'd have to disagree with you. There is nothing intrinsic to the C++ language that makes it less low-level than C. Nothing. People who make the claim you have usually mistake the presence of higher level constructs as an indication that the lower level constructs aren't there, which is not the case. William E. Kempf
Only because C++ is a superset of C. There is also nothing that you can do In C++ that I can't do in C. Forget the semantic differences and focus on performance and implementation of algorithms. But if you look at any low level operations in C++ it is in terms of C - not anything that was ADDED by the C++ baggage which trys its very best to hide low level operations. William E. Kempf wrote: People who make the claim you have usually mistake the presence of higher level constructs as an indication that the lower level constructs aren't there, which is not the case Now this is curious because it is my argument in reverse. Most ( not all but most ) C++ programmers have no clue as to what is really going on under the hood because they are only exposed to the high level constructs and never have to deal with the machine itself. They use features like virtual functions and have no idea how they work. They think that overloaded functions is something special about the C++ language and have no idea that its really a compiler trick and there are no REAL overladed functions. Ask most of them to write a sort from scratch and see what you get. They think that a pointer to an integer and a pointer to a double are different animals and void pointers are the work of the devil when in reality all pointers are void pointers. Don't get me wrong. I love C++ and have worked with it from way back at its very beginning. It allows me to do things with a different mindset than C does but it is kinda like the difference between a city boy and a country boy. A City boy - having always gone to the store to get his meat and milk and bread would be at a total loss if all of a sudden he couldn't do this anymore. Hell he'd starve. A country boy would think that the super market was wonderful but he would still know how to raise and milk a cow and butcher a pig and make biscuits. He would survive. A through knowledge of C and ASM ( any chip ) is almost essential to REALLY understand a language. Of course thats just MHO. Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
-
Only because C++ is a superset of C. There is also nothing that you can do In C++ that I can't do in C. Forget the semantic differences and focus on performance and implementation of algorithms. But if you look at any low level operations in C++ it is in terms of C - not anything that was ADDED by the C++ baggage which trys its very best to hide low level operations. William E. Kempf wrote: People who make the claim you have usually mistake the presence of higher level constructs as an indication that the lower level constructs aren't there, which is not the case Now this is curious because it is my argument in reverse. Most ( not all but most ) C++ programmers have no clue as to what is really going on under the hood because they are only exposed to the high level constructs and never have to deal with the machine itself. They use features like virtual functions and have no idea how they work. They think that overloaded functions is something special about the C++ language and have no idea that its really a compiler trick and there are no REAL overladed functions. Ask most of them to write a sort from scratch and see what you get. They think that a pointer to an integer and a pointer to a double are different animals and void pointers are the work of the devil when in reality all pointers are void pointers. Don't get me wrong. I love C++ and have worked with it from way back at its very beginning. It allows me to do things with a different mindset than C does but it is kinda like the difference between a city boy and a country boy. A City boy - having always gone to the store to get his meat and milk and bread would be at a total loss if all of a sudden he couldn't do this anymore. Hell he'd starve. A country boy would think that the super market was wonderful but he would still know how to raise and milk a cow and butcher a pig and make biscuits. He would survive. A through knowledge of C and ASM ( any chip ) is almost essential to REALLY understand a language. Of course thats just MHO. Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
Richard Stringer wrote: Only because C++ is a superset of C. It's not a strict superset. Richard Stringer wrote: There is also nothing that you can do In C++ that I can't do in C. And I never claimed there was. Richard Stringer wrote: Forget the semantic differences and focus on performance and implementation of algorithms. But if you look at any low level operations in C++ it is in terms of C - not anything that was ADDED by the C++ baggage which trys its very best to hide low level operations. Strictly untrue. Again, I point you at Blitz and other such packages. Richard Stringer wrote: Most ( not all but most ) C++ programmers have no clue as to what is really going on under the hood because they are only exposed to the high level constructs and never have to deal with the machine itself. I can say the same for C programmers. In fact, Assembly language programmers DID say the same thing about C programmers. Richard Stringer wrote: They think that a pointer to an integer and a pointer to a double are different animals and void pointers are the work of the devil when in reality all pointers are void pointers. Uhm... no. All pointers are addresses, but in a strictly typed language, there is a definate difference between pointer types (and in this case, this includes void*, as any C++ programmer who's round tripped pointers to polymorphic types should be able to attest to). Other than that, this entire paragraph has no bearing on performance what so ever... so I see little (or no) point in arguing them for this "low level" topic? Richard Stringer wrote: A City boy - having always gone to the store to get his meat and milk and bread would be at a total loss if all of a sudden he couldn't do this anymore. Hell he'd starve. A country boy would think that the super market was wonderful but he would still know how to raise and milk a cow and butcher a pig and make biscuits. He would survive. I don't agree with this analogy. Only an ignorant city boy would starve to death. And an ignorant country boy would never be able to figure out how to use the self-checkout aisles in most modern groceries stores. Neither would fare better than the other out of their element, because they are ignorant. This is true of C and C++ as well. I've seen highly optimized C++ in about the same ratio as I've seen highly opti
-
Only because C++ is a superset of C. There is also nothing that you can do In C++ that I can't do in C. Forget the semantic differences and focus on performance and implementation of algorithms. But if you look at any low level operations in C++ it is in terms of C - not anything that was ADDED by the C++ baggage which trys its very best to hide low level operations. William E. Kempf wrote: People who make the claim you have usually mistake the presence of higher level constructs as an indication that the lower level constructs aren't there, which is not the case Now this is curious because it is my argument in reverse. Most ( not all but most ) C++ programmers have no clue as to what is really going on under the hood because they are only exposed to the high level constructs and never have to deal with the machine itself. They use features like virtual functions and have no idea how they work. They think that overloaded functions is something special about the C++ language and have no idea that its really a compiler trick and there are no REAL overladed functions. Ask most of them to write a sort from scratch and see what you get. They think that a pointer to an integer and a pointer to a double are different animals and void pointers are the work of the devil when in reality all pointers are void pointers. Don't get me wrong. I love C++ and have worked with it from way back at its very beginning. It allows me to do things with a different mindset than C does but it is kinda like the difference between a city boy and a country boy. A City boy - having always gone to the store to get his meat and milk and bread would be at a total loss if all of a sudden he couldn't do this anymore. Hell he'd starve. A country boy would think that the super market was wonderful but he would still know how to raise and milk a cow and butcher a pig and make biscuits. He would survive. A through knowledge of C and ASM ( any chip ) is almost essential to REALLY understand a language. Of course thats just MHO. Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
C++ code is more manageable than C code. Obviously, you can do everything in assembly as well. Richard Stringer wrote: Most ( not all but most ) C++ programmers have no clue as to what is really going on under the hood There are very few experts in any profession. Most people just go by standard practices. And expert software professionals can code in most languages easily with very little lead time. I am certain that you can program in Java or VBScript because the fundamental concepts are the same - and all that varies is what the language is capable of; and you understanding the constructs of the language. I would disagree that knowledge of C is essential to understand computing. But, assembly would defintely help in undersatnding how processors work. Considering that even processors are written in high-level languages like HDL these days, I wonder who has a good idea of what goes on underneath. But, at some point you have to trust your tools to do the right thing. While understanding what goes on under the hood is important, it should not be necessary that you HAVE to think about it all the time to do trivial programming tasks. In most programs I have written, manageability outweighs performance as the major factor. I would write unoptimized easy to read code in high level languages for tasks where the diffrence between 1 second and 5 ro 10 seconds is not of great concern. But, I do not hestitate to go to the lowest levels to optimize a piece of code on a server application that is called a few hundred times a second. My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
-
A slightly better description... but even that is full of FUD. Abstraction, by itself, does not equal performance degradation or over use of resources. You can create extremely efficient OOP designs. More over, C++ has proven to allow even greater flexibility and performance than C in many areas. For example, Blitz and other such numerical template libraries, out strip C and rival Fortran for complex scientific calculations. Are the high level features of C++ abused by the ignorant? You bet. But then, few developers produce efficient C code, as well. If you have the attitude that C++ is too high level, you shouldn't be using C. You should be coding in Assembler. As someone who's coded a lot in all three... I'll pick C++ over C every time, and C++ over Assembler in all but the most critical areas. William E. Kempf
William E. Kempf wrote: You can create extremely efficient OOP designs. Clickety[^] William E. Kempf wrote: More over, C++ has proven to allow even greater flexibility and performance than C in many areas. No, Bjarne created C++ to be more strict than C. His words, not mine. William E. Kempf wrote: For example, Blitz and other such numerical template libraries AFAIK that's not a standard library and not a part of the core language. And templates and classes are two different cookies. And, algorithms cannot be compared to calling conventions, OOP overhead, etc. As far as the rest, well I aggree with Richard. Jeremy Falcon
-
If you had to ask then you wouldn't understand the answer :) Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
Richard Stringer wrote: If you had to ask then you wouldn't understand the answer :wtf: Somehow, I don't think he is that ignorant.
-
William E. Kempf wrote: You can create extremely efficient OOP designs. Clickety[^] William E. Kempf wrote: More over, C++ has proven to allow even greater flexibility and performance than C in many areas. No, Bjarne created C++ to be more strict than C. His words, not mine. William E. Kempf wrote: For example, Blitz and other such numerical template libraries AFAIK that's not a standard library and not a part of the core language. And templates and classes are two different cookies. And, algorithms cannot be compared to calling conventions, OOP overhead, etc. As far as the rest, well I aggree with Richard. Jeremy Falcon
Jeremy Falcon wrote: William E. Kempf wrote: You can create extremely efficient OOP designs. Clickety[^] Do some more research. Modern compilers have little problem optimizing away the problems exposed by OOPACK. The trouble isn't with the abstractions, per se, but with the optimizations applied by the compiler. You also have to note that with OOPACK (and stepanov and other such bench tests) that they are testing a very specific design, so they aren't a universal representation in the first place. Even back in '92 the statement I gave above would have still held true despite these benchmarks. You just had to be cognizant of the issues and how to work around them. Jeremy Falcon wrote: William E. Kempf wrote: More over, C++ has proven to allow even greater flexibility and performance than C in many areas. No, Bjarne created C++ to be more strict than C. His words, not mine. Why Bjarne created C++ has nothing at all to do with what I just said, and you definately didn't refute it by quoting him here. After all, if C++ were only a stricter C, you'd lose your argument from the very beginning, as type safety has zero overhead or impact to the "low level" nature of a language. Jeremy Falcon wrote: William E. Kempf wrote: For example, Blitz and other such numerical template libraries AFAIK that's not a standard library and not a part of the core language. And templates and classes are two different cookies. And, algorithms cannot be compared to calling conventions, OOP overhead, etc. Why must it be part of the standard library to be evidence of my claims? And the Blitz code happens to be both templates and classes... so you're not making much of an argument here. Further, I never said anything to lead you to assume that ALL of the C++ language shouldn't be considered in this thread... and that includes templates. After all, the original complaint was with C++ and not OOP in general. And sorry, but I really can't figure out how to interpret your last sentence about algorithms with regards to this discussion? William E. Kempf
-
Jeremy Falcon wrote: William E. Kempf wrote: You can create extremely efficient OOP designs. Clickety[^] Do some more research. Modern compilers have little problem optimizing away the problems exposed by OOPACK. The trouble isn't with the abstractions, per se, but with the optimizations applied by the compiler. You also have to note that with OOPACK (and stepanov and other such bench tests) that they are testing a very specific design, so they aren't a universal representation in the first place. Even back in '92 the statement I gave above would have still held true despite these benchmarks. You just had to be cognizant of the issues and how to work around them. Jeremy Falcon wrote: William E. Kempf wrote: More over, C++ has proven to allow even greater flexibility and performance than C in many areas. No, Bjarne created C++ to be more strict than C. His words, not mine. Why Bjarne created C++ has nothing at all to do with what I just said, and you definately didn't refute it by quoting him here. After all, if C++ were only a stricter C, you'd lose your argument from the very beginning, as type safety has zero overhead or impact to the "low level" nature of a language. Jeremy Falcon wrote: William E. Kempf wrote: For example, Blitz and other such numerical template libraries AFAIK that's not a standard library and not a part of the core language. And templates and classes are two different cookies. And, algorithms cannot be compared to calling conventions, OOP overhead, etc. Why must it be part of the standard library to be evidence of my claims? And the Blitz code happens to be both templates and classes... so you're not making much of an argument here. Further, I never said anything to lead you to assume that ALL of the C++ language shouldn't be considered in this thread... and that includes templates. After all, the original complaint was with C++ and not OOP in general. And sorry, but I really can't figure out how to interpret your last sentence about algorithms with regards to this discussion? William E. Kempf
William E. Kempf wrote: After all, if C++ were only a stricter C, you'd lose your argument from the very beginning, as type safety has zero overhead or impact to the "low level" nature of a language. My claim was on the grounds of OOP overhead. I never said C++ was a "stricter C". You are putting words in my mouth to falsify a point. The greater flexibility you spoke of goes against what I read of Bjarne when he created C++ to have strict rules on type checking, etc. So, I don't see how you can claim greater flexibility. As far as performance gains, I say prove it. This largely depends on the compiler. William E. Kempf wrote: Why must it be part of the standard library to be evidence of my claims? Do you have the source to Blitz? If not, then you don't know for sure what the underlying algorithms are coded with (maybe inline asm for all you know). If so, then this doesn't matter. William E. Kempf wrote: And sorry, but I really can't figure out how to interpret your last sentence about algorithms with regards to this discussion? Because OOP will always add an extra layer of overhead. What goes in a member function and how the member function is accessed are not the same things. Jeremy Falcon
-
Richard Stringer wrote: If you had to ask then you wouldn't understand the answer :wtf: Somehow, I don't think he is that ignorant.
I didn't think he was or I would not have answered like that. Its kinda like someone going to buy a Rolls Royce and asking what the gas mileage is. If you can afford the car you can afford the gas. If he knew enough about the differences between C and C++ to defend his position he knew enough to understand the answer . He and I disagree on a silly little point of functionality thats all. I think I'm right - he thinks he's right - and the rest of the world really doesn't care very much. Richard In Italy for thirty years under the Borgias they had warfare, terror, murder and bloodshed but they produced Michelangelo, Leonardo da Vinci and the Renaissance. In Switzerland, they had brotherly love; they had five hundred years of democracy and peace and what did that produce? The cuckoo clock. Orson Welles
-
William E. Kempf wrote: After all, if C++ were only a stricter C, you'd lose your argument from the very beginning, as type safety has zero overhead or impact to the "low level" nature of a language. My claim was on the grounds of OOP overhead. I never said C++ was a "stricter C". You are putting words in my mouth to falsify a point. The greater flexibility you spoke of goes against what I read of Bjarne when he created C++ to have strict rules on type checking, etc. So, I don't see how you can claim greater flexibility. As far as performance gains, I say prove it. This largely depends on the compiler. William E. Kempf wrote: Why must it be part of the standard library to be evidence of my claims? Do you have the source to Blitz? If not, then you don't know for sure what the underlying algorithms are coded with (maybe inline asm for all you know). If so, then this doesn't matter. William E. Kempf wrote: And sorry, but I really can't figure out how to interpret your last sentence about algorithms with regards to this discussion? Because OOP will always add an extra layer of overhead. What goes in a member function and how the member function is accessed are not the same things. Jeremy Falcon
Jeremy Falcon wrote: Do you have the source to Blitz? If not, then you don't know for sure what the underlying algorithms are coded with (maybe inline asm for all you know). If so, then this doesn't matter. Blitz++ is shipped with the source (like all template libraries). And no, it has no inline asm - pure C++.
-
William E. Kempf wrote: After all, if C++ were only a stricter C, you'd lose your argument from the very beginning, as type safety has zero overhead or impact to the "low level" nature of a language. My claim was on the grounds of OOP overhead. I never said C++ was a "stricter C". You are putting words in my mouth to falsify a point. The greater flexibility you spoke of goes against what I read of Bjarne when he created C++ to have strict rules on type checking, etc. So, I don't see how you can claim greater flexibility. As far as performance gains, I say prove it. This largely depends on the compiler. William E. Kempf wrote: Why must it be part of the standard library to be evidence of my claims? Do you have the source to Blitz? If not, then you don't know for sure what the underlying algorithms are coded with (maybe inline asm for all you know). If so, then this doesn't matter. William E. Kempf wrote: And sorry, but I really can't figure out how to interpret your last sentence about algorithms with regards to this discussion? Because OOP will always add an extra layer of overhead. What goes in a member function and how the member function is accessed are not the same things. Jeremy Falcon
Jeremy Falcon wrote: My claim was on the grounds of OOP overhead. I never said C++ was a "stricter C". No, but you quoted Bjarne with an implication that that's all *he* intended C++ to be. Jeremy Falcon wrote: You are putting words in my mouth to falsify a point. Not intentionally, and what you have next makes me believe that at best we have a misunderstanding of what the other is saying. At least it certainly appears that you're still making the claim I state above. Jeremy Falcon wrote: The greater flexibility you spoke of goes against what I read of Bjarne when he created C++ to have strict rules on type checking, etc. How does strict type checking go against greater flexibility? Jeremy Falcon wrote: So, I don't see how you can claim greater flexibility. I've given the example of Blitz. Jeremy Falcon wrote: William E. Kempf wrote: Why must it be part of the standard library to be evidence of my claims? Do you have the source to Blitz? If not, then you don't know for sure what the underlying algorithms are coded with (maybe inline asm for all you know). If so, then this doesn't matter. http://www.oonumerics.org/blitz/[^] There's also Boost libraries that achieve many of the same things. Jeremy Falcon wrote: William E. Kempf wrote: And sorry, but I really can't figure out how to interpret your last sentence about algorithms with regards to this discussion? Because OOP will always add an extra layer of overhead. What goes in a member function and how the member function is accessed are not the same things. Absolutely not. Non-virtual member functions add no more overhead than stand alone functions in C (and with modern compilers, virtual member functions add very little overhead, and no more overhead than equivalent constructs in C... though the very nature of polymorphic calls does imply some overhead, and as such should only be used when necessary). The OOPACK benchmark is very specifically illustrating issues with small object abstractions. An OO design need not use small object abstractions. Further, modern C++ compilers are finding ways to optimize small object abstractions so that there is no penalty involved here. William E. Kempf
-
Jeremy Falcon wrote: My claim was on the grounds of OOP overhead. I never said C++ was a "stricter C". No, but you quoted Bjarne with an implication that that's all *he* intended C++ to be. Jeremy Falcon wrote: You are putting words in my mouth to falsify a point. Not intentionally, and what you have next makes me believe that at best we have a misunderstanding of what the other is saying. At least it certainly appears that you're still making the claim I state above. Jeremy Falcon wrote: The greater flexibility you spoke of goes against what I read of Bjarne when he created C++ to have strict rules on type checking, etc. How does strict type checking go against greater flexibility? Jeremy Falcon wrote: So, I don't see how you can claim greater flexibility. I've given the example of Blitz. Jeremy Falcon wrote: William E. Kempf wrote: Why must it be part of the standard library to be evidence of my claims? Do you have the source to Blitz? If not, then you don't know for sure what the underlying algorithms are coded with (maybe inline asm for all you know). If so, then this doesn't matter. http://www.oonumerics.org/blitz/[^] There's also Boost libraries that achieve many of the same things. Jeremy Falcon wrote: William E. Kempf wrote: And sorry, but I really can't figure out how to interpret your last sentence about algorithms with regards to this discussion? Because OOP will always add an extra layer of overhead. What goes in a member function and how the member function is accessed are not the same things. Absolutely not. Non-virtual member functions add no more overhead than stand alone functions in C (and with modern compilers, virtual member functions add very little overhead, and no more overhead than equivalent constructs in C... though the very nature of polymorphic calls does imply some overhead, and as such should only be used when necessary). The OOPACK benchmark is very specifically illustrating issues with small object abstractions. An OO design need not use small object abstractions. Further, modern C++ compilers are finding ways to optimize small object abstractions so that there is no penalty involved here. William E. Kempf
William E. Kempf wrote: No, but you quoted Bjarne with an implication that that's all *he* intended C++ to be. But that's just it, you spawned off an "implication" that you assumed I made. William E. Kempf wrote: I've given the example of Blitz. Lemme take a look at it, and I'll get back to ya. Jeremy Falcon
-
William E. Kempf wrote: No, but you quoted Bjarne with an implication that that's all *he* intended C++ to be. But that's just it, you spawned off an "implication" that you assumed I made. William E. Kempf wrote: I've given the example of Blitz. Lemme take a look at it, and I'll get back to ya. Jeremy Falcon
Jeremy Falcon wrote: William E. Kempf wrote: No, but you quoted Bjarne with an implication that that's all *he* intended C++ to be. But that's just it, you spawned off an "implication" that you assumed I made. Not intentionally, but that's the only meaning I could glean from the quote. Care to explain further? William E. Kempf
-
Jeremy Falcon wrote: William E. Kempf wrote: No, but you quoted Bjarne with an implication that that's all *he* intended C++ to be. But that's just it, you spawned off an "implication" that you assumed I made. Not intentionally, but that's the only meaning I could glean from the quote. Care to explain further? William E. Kempf
William E. Kempf wrote: Care to explain further? Well, I had type checking in my head at the time; however, it didn't seem to come out on paper (err, bytes). :-O I'll be the first to admit (well maybe second ;P) that my experience with C is much greater than C++. Even when I use C++ I tend to stay with the "C style" and use classes if I "need" them. Yes, I know OOAD, but I think OOP is just another buzz term. In fact I heard something new that's supposed to be called "Application Oriented." What's next, we use "Procedure Oriented" and we go back to the way I we all did things in the first place? :) I don't use much STL, but rather the standard libs. Even with my Windows programming I use the pure API calls because I don't think they were poorly designed – just not OO. I can achieve encapsulation simply by staying modular with my functions. And, it's just as easy to reuse a well-written function as it is a class. Anyway, I've always read since the dawn of ages that C++ incurs overhead simply because of it's extra functionality. To me that makes sense. Now, if compilers these days are closing the bridge on that - that's great. But, I'd like to see stats. P.S. When I get a chance, I still intend on checking out the Blitz library just to see what kind of magic you say they are pulling off. Jeremy Falcon