C++/Fido.net/Memories
-
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
-
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
Jeremy Falcon wrote: Yes, I know OOAD, but I think OOP is just another buzz term. Buzz terms don't have life spans of the length that OOP has already endured ;). I think you're falling afoul of the initial "buzz" over OOP being that it was a silver bullet that would solve all of our problems. Obviously it's not, as there is no such thing as a silver bullet. So, because of this "buzz", you've mentally aligned yourself to think that OOP is bad. There are two problems with this, as it pertains to this thread. First, OOP *IS* a very good solution for many problems... including some problems not easily solvable with other paradigms, such as you're favored procedural. Secondly, C++ is *NOT* an OOP language, or at least not exclusively. It actually lets you program using many different methodologies, including your preferred procedural. Good C++ developers make use of each paradigm, choosing the most appropriate one for the task at hand (of course, that's not always an easy thing to determine). Jeremy Falcon wrote: In fact I heard something new that's supposed to be called "Application Oriented." I believe you're referring to AO, which is Aspect Oriented (http://aosd.net/[^]), not Application Oriented. Jeremy Falcon wrote: What's next, we use "Procedure Oriented" and we go back to the way I we all did things in the first place? When it's appropriate. BTW, you've missed several other methodologies/paradigms which can be used in C++. Functional is one of the more intersting ones being explored right now. Jeremy Falcon wrote: I don't use much STL, but rather the standard libs. Depending on how you use the term "STL", it *IS* part of the standard libs. Jeremy Falcon wrote: And, it's just as easy to reuse a well-written function as it is a class. Absolutely. But it's more difficult to achieve things like lifetime management, for instance. Both methodologies have their strengths and weaknesses. The nice thing about C++ is it let's me choose ;). Jeremy Falcon wrote: 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. Act
-
Jeremy Falcon wrote: Yes, I know OOAD, but I think OOP is just another buzz term. Buzz terms don't have life spans of the length that OOP has already endured ;). I think you're falling afoul of the initial "buzz" over OOP being that it was a silver bullet that would solve all of our problems. Obviously it's not, as there is no such thing as a silver bullet. So, because of this "buzz", you've mentally aligned yourself to think that OOP is bad. There are two problems with this, as it pertains to this thread. First, OOP *IS* a very good solution for many problems... including some problems not easily solvable with other paradigms, such as you're favored procedural. Secondly, C++ is *NOT* an OOP language, or at least not exclusively. It actually lets you program using many different methodologies, including your preferred procedural. Good C++ developers make use of each paradigm, choosing the most appropriate one for the task at hand (of course, that's not always an easy thing to determine). Jeremy Falcon wrote: In fact I heard something new that's supposed to be called "Application Oriented." I believe you're referring to AO, which is Aspect Oriented (http://aosd.net/[^]), not Application Oriented. Jeremy Falcon wrote: What's next, we use "Procedure Oriented" and we go back to the way I we all did things in the first place? When it's appropriate. BTW, you've missed several other methodologies/paradigms which can be used in C++. Functional is one of the more intersting ones being explored right now. Jeremy Falcon wrote: I don't use much STL, but rather the standard libs. Depending on how you use the term "STL", it *IS* part of the standard libs. Jeremy Falcon wrote: And, it's just as easy to reuse a well-written function as it is a class. Absolutely. But it's more difficult to achieve things like lifetime management, for instance. Both methodologies have their strengths and weaknesses. The nice thing about C++ is it let's me choose ;). Jeremy Falcon wrote: 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. Act
William E. Kempf wrote: Buzz terms don't have life spans of the length that OOP has already endured Explain "HaXoR", "1337", and "Visual Basic". William E. Kempf wrote: I think you're falling afoul of the initial "buzz" over OOP being that it was a silver bullet that would solve all of our problems. You're assuming again, and no I am not falling afoul as you put it. Funny how you aggreed with Richard that there's nothing I can't do in C that can be done in C++. And yes you shoot down my choice (that coincides with his) of saying OOP is not the gratest things since sliced bread. And, as far as marketing nuts, rookies, etc. OOP is a buzz word still. William E. Kempf wrote: Depending on how you use the term "STL", it *IS* part of the standard libs. I meant as in "non-templatized". Since your perception is so keen, I figured you'd pick up on it. William E. Kempf wrote: Actually, it doesn't make that much sense. Here's a very common C way of doing things: Don't confuse "as much experience" with "no experience". This is extremely rookie crap you're showing me here. And furthermore, I've never referred to coding when talking about overhead, but rather what the computer must endure (taxation-wise) to account for this methodology. William E. Kempf wrote: but no more so than similar techniques employed by C libraries such as the Win32 API. As an FMI, can you name a technique the Win32 API uses that has as much overhead? William E. Kempf wrote: http://www.oonumerics.org/MailArchives/oon-list/msg00073.php\[^\]. There has to be a lot more info than this, but I found this one with a 10 second Google search. These stats are crap. You're quick to argue, but slow to search. What gives? Jeremy Falcon
-
William E. Kempf wrote: Buzz terms don't have life spans of the length that OOP has already endured Explain "HaXoR", "1337", and "Visual Basic". William E. Kempf wrote: I think you're falling afoul of the initial "buzz" over OOP being that it was a silver bullet that would solve all of our problems. You're assuming again, and no I am not falling afoul as you put it. Funny how you aggreed with Richard that there's nothing I can't do in C that can be done in C++. And yes you shoot down my choice (that coincides with his) of saying OOP is not the gratest things since sliced bread. And, as far as marketing nuts, rookies, etc. OOP is a buzz word still. William E. Kempf wrote: Depending on how you use the term "STL", it *IS* part of the standard libs. I meant as in "non-templatized". Since your perception is so keen, I figured you'd pick up on it. William E. Kempf wrote: Actually, it doesn't make that much sense. Here's a very common C way of doing things: Don't confuse "as much experience" with "no experience". This is extremely rookie crap you're showing me here. And furthermore, I've never referred to coding when talking about overhead, but rather what the computer must endure (taxation-wise) to account for this methodology. William E. Kempf wrote: but no more so than similar techniques employed by C libraries such as the Win32 API. As an FMI, can you name a technique the Win32 API uses that has as much overhead? William E. Kempf wrote: http://www.oonumerics.org/MailArchives/oon-list/msg00073.php\[^\]. There has to be a lot more info than this, but I found this one with a 10 second Google search. These stats are crap. You're quick to argue, but slow to search. What gives? Jeremy Falcon
Jeremy Falcon wrote: Funny how you aggreed with Richard that there's nothing I can't do in C that can be done in C++. And yes you shoot down my choice (that coincides with his) of saying OOP is not the gratest things since sliced bread. And, as far as marketing nuts, rookies, etc. OOP is a buzz word still. I see no contradictions in anything I said. And I certainly did not "shoot down your choice... of saying OOP is not the greatest things (sic) since sliced bread." We'll have to agree to disagree about OOP being a buzzword, but regardless, it's a well proven methodology. Jeremy Falcon wrote: Don't confuse "as much experience" with "no experience". I never assumed anything along these lines. Jeremy Falcon wrote: This is extremely rookie crap you're showing me here. And furthermore, I've never referred to coding when talking about overhead, but rather what the computer must endure (taxation-wise) to account for this methodology. The code I presented was meant to show there's nothing "the computer must endure (taxation-wise) to account for this methodology." The resulting overhead should have been identical for both the procedural design as well as the OOP design for my simplistic example. Jeremy Falcon wrote: William E. Kempf wrote: but no more so than similar techniques employed by C libraries such as the Win32 API. As an FMI, can you name a technique the Win32 API uses that has as much overhead? Certainly. WNDPROCs are a C way of getting polymorphic behavior, with the same amount of overhead as most C++ implementations of polymorphism (i.e. a vtable with a single level of indirection). Jeremy Falcon wrote: William E. Kempf wrote: http://www.oonumerics.org/MailArchives/oon-list/msg00073.php\[^\]. There has to be a lot more info than this, but I found this one with a 10 second Google search. These stats are crap. You're quick to argue, but slow to search. What gives? How are they crap? And why should I do your research? I don't have a vested interest in this. I showed that a simple Google search can get you the data you want, so go do the search. (BTW, I did find other sites showing similar figures.) Why are you taking this so personal? This is getting very close to degenerating into a flame war. William E. Kempf
-
William E. Kempf wrote: Buzz terms don't have life spans of the length that OOP has already endured Explain "HaXoR", "1337", and "Visual Basic". William E. Kempf wrote: I think you're falling afoul of the initial "buzz" over OOP being that it was a silver bullet that would solve all of our problems. You're assuming again, and no I am not falling afoul as you put it. Funny how you aggreed with Richard that there's nothing I can't do in C that can be done in C++. And yes you shoot down my choice (that coincides with his) of saying OOP is not the gratest things since sliced bread. And, as far as marketing nuts, rookies, etc. OOP is a buzz word still. William E. Kempf wrote: Depending on how you use the term "STL", it *IS* part of the standard libs. I meant as in "non-templatized". Since your perception is so keen, I figured you'd pick up on it. William E. Kempf wrote: Actually, it doesn't make that much sense. Here's a very common C way of doing things: Don't confuse "as much experience" with "no experience". This is extremely rookie crap you're showing me here. And furthermore, I've never referred to coding when talking about overhead, but rather what the computer must endure (taxation-wise) to account for this methodology. William E. Kempf wrote: but no more so than similar techniques employed by C libraries such as the Win32 API. As an FMI, can you name a technique the Win32 API uses that has as much overhead? William E. Kempf wrote: http://www.oonumerics.org/MailArchives/oon-list/msg00073.php\[^\]. There has to be a lot more info than this, but I found this one with a 10 second Google search. These stats are crap. You're quick to argue, but slow to search. What gives? Jeremy Falcon
Jeremy Falcon wrote: William E. Kempf wrote: Depending on how you use the term "STL", it *IS* part of the standard libs. I meant as in "non-templatized". Since your perception is so keen, I figured you'd pick up on it. I missed this part in my first reply. What does "non-templatized" have to do with anything? If you choose not to use templates, that's your choice (though I can't see any rationale reason for the choice), but I see no bearing to this subject? William E. Kempf
-
Jeremy Falcon wrote: William E. Kempf wrote: Depending on how you use the term "STL", it *IS* part of the standard libs. I meant as in "non-templatized". Since your perception is so keen, I figured you'd pick up on it. I missed this part in my first reply. What does "non-templatized" have to do with anything? If you choose not to use templates, that's your choice (though I can't see any rationale reason for the choice), but I see no bearing to this subject? William E. Kempf
William E. Kempf wrote: though I can't see any rationale reason for the choice Personal preference. Jeremy Falcon
-
Jeremy Falcon wrote: Funny how you aggreed with Richard that there's nothing I can't do in C that can be done in C++. And yes you shoot down my choice (that coincides with his) of saying OOP is not the gratest things since sliced bread. And, as far as marketing nuts, rookies, etc. OOP is a buzz word still. I see no contradictions in anything I said. And I certainly did not "shoot down your choice... of saying OOP is not the greatest things (sic) since sliced bread." We'll have to agree to disagree about OOP being a buzzword, but regardless, it's a well proven methodology. Jeremy Falcon wrote: Don't confuse "as much experience" with "no experience". I never assumed anything along these lines. Jeremy Falcon wrote: This is extremely rookie crap you're showing me here. And furthermore, I've never referred to coding when talking about overhead, but rather what the computer must endure (taxation-wise) to account for this methodology. The code I presented was meant to show there's nothing "the computer must endure (taxation-wise) to account for this methodology." The resulting overhead should have been identical for both the procedural design as well as the OOP design for my simplistic example. Jeremy Falcon wrote: William E. Kempf wrote: but no more so than similar techniques employed by C libraries such as the Win32 API. As an FMI, can you name a technique the Win32 API uses that has as much overhead? Certainly. WNDPROCs are a C way of getting polymorphic behavior, with the same amount of overhead as most C++ implementations of polymorphism (i.e. a vtable with a single level of indirection). Jeremy Falcon wrote: William E. Kempf wrote: http://www.oonumerics.org/MailArchives/oon-list/msg00073.php\[^\]. There has to be a lot more info than this, but I found this one with a 10 second Google search. These stats are crap. You're quick to argue, but slow to search. What gives? How are they crap? And why should I do your research? I don't have a vested interest in this. I showed that a simple Google search can get you the data you want, so go do the search. (BTW, I did find other sites showing similar figures.) Why are you taking this so personal? This is getting very close to degenerating into a flame war. William E. Kempf
William E. Kempf wrote: WNDPROCs are a C way of getting polymorphic behavior I can see your point with the callback schema. But, considering this is a Win32 and not a C issue (directly) this overhead would apply to all Windows applications. So, you wouldn't really get a benefit from using C++ (in this manner) over C when coding for Win32 (or many other GUIed/message-based OSes as they implement similar techniques). William E. Kempf wrote: How are they crap? And why should I do your research? I thought you were trying to prove the point of C++ supremacy? It takes some work ya know. ;) William E. Kempf wrote: BTW, I did find other sites showing similar figures. Fine then, but if they present things like the other one I don't think I'll be thoroughly convinced. As they did not present the grandiose pile of information that I was hoping for. William E. Kempf wrote: Why are you taking this so personal? I'm not. I have a certain "style" of writing if you will. For instance, I call a lot of things crap. Don't take offense. William E. Kempf wrote: This is getting very close to degenerating into a flame war. By whom? Jeremy Falcon
-
William E. Kempf wrote: WNDPROCs are a C way of getting polymorphic behavior I can see your point with the callback schema. But, considering this is a Win32 and not a C issue (directly) this overhead would apply to all Windows applications. So, you wouldn't really get a benefit from using C++ (in this manner) over C when coding for Win32 (or many other GUIed/message-based OSes as they implement similar techniques). William E. Kempf wrote: How are they crap? And why should I do your research? I thought you were trying to prove the point of C++ supremacy? It takes some work ya know. ;) William E. Kempf wrote: BTW, I did find other sites showing similar figures. Fine then, but if they present things like the other one I don't think I'll be thoroughly convinced. As they did not present the grandiose pile of information that I was hoping for. William E. Kempf wrote: Why are you taking this so personal? I'm not. I have a certain "style" of writing if you will. For instance, I call a lot of things crap. Don't take offense. William E. Kempf wrote: This is getting very close to degenerating into a flame war. By whom? Jeremy Falcon
Jeremy Falcon wrote: I can see your point with the callback schema. But, considering this is a Win32 and not a C issue (directly) this overhead would apply to all Windows applications. So, you wouldn't really get a benefit from using C++ (in this manner) over C when coding for Win32 (or many other GUIed/message-based OSes as they implement similar techniques). I don't think you understand the point I was making. There's no "benefit" to using C++ in this case. What I'm pointing out is that you can do no better in C when implementing a polymorphic call than occurs in C++. The myth of virtual method overhead lies in two factors. The first is simply that the overhead is no different from any such techniques you'd employ for polymorphism even in Assembler. The second is in the fact that polymorphic calls are usually abused by beginners in OOP, which leads to the mistaken belief that they add uneccessary overhead. Jeremy Falcon wrote: William E. Kempf wrote: How are they crap? And why should I do your research? I thought you were trying to prove the point of C++ supremacy? It takes some work ya know. 1) You didn't answer the first question. 2) I'm not trying to prove C++'s supremacy. I don't believe in such forms of advocacy. Use the right tool for the job, and when multiple tools will do just as well, choose the one you're more comfortable with. I'm only trying to dispell the notion that C++ causes unecessary overhead. Jeremy Falcon wrote: William E. Kempf wrote: BTW, I did find other sites showing similar figures. Fine then, but if they present things like the other one I don't think I'll be thoroughly convinced. As they did not present the grandiose pile of information that I was hoping for. Again, you have to answer my question before I can hope to provide the data you want. After all, the link I sent you shows the actual output of running OOPACK, so I can't fathom what else you'd want? William E. Kempf
-
Jeremy Falcon wrote: I can see your point with the callback schema. But, considering this is a Win32 and not a C issue (directly) this overhead would apply to all Windows applications. So, you wouldn't really get a benefit from using C++ (in this manner) over C when coding for Win32 (or many other GUIed/message-based OSes as they implement similar techniques). I don't think you understand the point I was making. There's no "benefit" to using C++ in this case. What I'm pointing out is that you can do no better in C when implementing a polymorphic call than occurs in C++. The myth of virtual method overhead lies in two factors. The first is simply that the overhead is no different from any such techniques you'd employ for polymorphism even in Assembler. The second is in the fact that polymorphic calls are usually abused by beginners in OOP, which leads to the mistaken belief that they add uneccessary overhead. Jeremy Falcon wrote: William E. Kempf wrote: How are they crap? And why should I do your research? I thought you were trying to prove the point of C++ supremacy? It takes some work ya know. 1) You didn't answer the first question. 2) I'm not trying to prove C++'s supremacy. I don't believe in such forms of advocacy. Use the right tool for the job, and when multiple tools will do just as well, choose the one you're more comfortable with. I'm only trying to dispell the notion that C++ causes unecessary overhead. Jeremy Falcon wrote: William E. Kempf wrote: BTW, I did find other sites showing similar figures. Fine then, but if they present things like the other one I don't think I'll be thoroughly convinced. As they did not present the grandiose pile of information that I was hoping for. Again, you have to answer my question before I can hope to provide the data you want. After all, the link I sent you shows the actual output of running OOPACK, so I can't fathom what else you'd want? William E. Kempf
William E. Kempf wrote: I don't think you understand the point I was making. You are making assumptions again. Furthermore, I do understand the point. That's why I said "I can see your point." I was merely stating the C or C++ irrelevence so that A: I could lay it out in English for confirmation and B: for the readers (if there are any left) of this thread. William E. Kempf wrote: You didn't answer the first question. What question? The one about Bjarne's quote? I already did answer that. If it's not that question, then I'm afraid I have no idea what your question is. William E. Kempf wrote: I'm not trying to prove C++'s supremacy. No, but you are going back and forth between OOP's performance (in C++) versus its overall validity in the first place. My stance is I don't think OOP solves any problems that programming languages didn't solve before - period. The issues programmers faced when coming from ASM to C are not the same ones when the time came to merge from C to C++. I used the OOPACK reference when on the topic of performance, but overall and performance aside I believe OOP is not my savior. (Also take no implications from that because I did not say it was yours either - you seem to assume a lot). As far as performance, I still don't see any gains over C when using C++, even in a non-OOP fashion. I do agree, however, that C++ does allow you to use both when the need arises, and I'll use it if my job requires it. But, personally I prefer not to. Jeremy Falcon
-
William E. Kempf wrote: I don't think you understand the point I was making. You are making assumptions again. Furthermore, I do understand the point. That's why I said "I can see your point." I was merely stating the C or C++ irrelevence so that A: I could lay it out in English for confirmation and B: for the readers (if there are any left) of this thread. William E. Kempf wrote: You didn't answer the first question. What question? The one about Bjarne's quote? I already did answer that. If it's not that question, then I'm afraid I have no idea what your question is. William E. Kempf wrote: I'm not trying to prove C++'s supremacy. No, but you are going back and forth between OOP's performance (in C++) versus its overall validity in the first place. My stance is I don't think OOP solves any problems that programming languages didn't solve before - period. The issues programmers faced when coming from ASM to C are not the same ones when the time came to merge from C to C++. I used the OOPACK reference when on the topic of performance, but overall and performance aside I believe OOP is not my savior. (Also take no implications from that because I did not say it was yours either - you seem to assume a lot). As far as performance, I still don't see any gains over C when using C++, even in a non-OOP fashion. I do agree, however, that C++ does allow you to use both when the need arises, and I'll use it if my job requires it. But, personally I prefer not to. Jeremy Falcon
Jeremy Falcon wrote: William E. Kempf wrote: I don't think you understand the point I was making. You are making assumptions again. Read the quote again. I very explicitly said "I don't think". I'm not making an assumption, I'm trying to understand what you've said. Jeremy Falcon wrote: William E. Kempf wrote: You didn't answer the first question. What question? The one about Bjarne's quote? I already did answer that. If it's not that question, then I'm afraid I have no idea what your question is. The first question in the full quote you just made. To whit, why do you find the numbers to be crap. Jeremy Falcon wrote: William E. Kempf wrote: I'm not trying to prove C++'s supremacy. No, but you are going back and forth between OOP's performance (in C++) versus its overall validity in the first place. No, I haven't been. Jeremy Falcon wrote: I used the OOPACK reference when on the topic of performance, but overall and performance aside I believe OOP is not my savior. (Also take no implications from that because I did not say it was yours either - you seem to assume a lot). (You asked earlier why I thought this was degenerating into a flame. Constant implications that I assume a lot and other language you use has been escalating from the first posts, and is nearing the point of being offensive. I may drop out of this discussion very soon because of this, and because I have no vested interest in where the argument is going.) Obviously OOP isn't your savior. No one has ever suggested that it should be. The fact that you continually go back to this is more of an indication that you're the one "going back and forth between OOP's performance (in C++) versus its overall validity in the first place". OOP *is* valid. The reasons for it's validity have nothing to do with performance, however, and it's validity does not mean that it's the magical silver bullet that will solve all of our problems. I've not made this argument, so there's no reason to continually try and go back to this. Jeremy Falcon wrote: As far as performance, I still don't see any gains over C when using C++, even in a non-OOP fashion. Blitz and other libraries provide a speed benefit that you'll be hard to get from C. This occurs because of the compile time constructs (as opposed to runtime calculations) that can be achieved using templates. But I've not be