C++/Fido.net/Memories
-
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