[ On Wednesday, February 27, 2002 at 12:35:18 (-0800), Thomas S. Urban wrote: ] > Subject: Re: OT: C++, yuck! > > On Wed, Feb 27, 2002 at 13:55:35 -0600, Mark A. Flacy sent 0.8K bytes: > > >>>>> "Thomas" == Thomas S Urban <[EMAIL PROTECTED]> writes: > > Thomas> > > Thomas> On Wed, Feb 27, 2002 at 12:59:48 -0500, Greg A. Woods sent 2.8K bytes: > > >> "dynamic binding" isn't a feature you could ever possibly decide on > > >> needing up front for any kind of project you'd ever even get close to > > >> justifying C for! Get real! > > Thomas> > > Thomas> You're wrong. Read what I wrote again. Projects I am working on satisfy > > Thomas> the description I gave. Then again, I'm not real, but I'm working on > > Thomas> it. > > > > In this case, he's correct. After all, if you need dynamic binding, then > > you can't use C and therefore can't justify using it for said project. :-) > > He's only possible correct in the context left after my original words > are removed. This is what I wrote: > > <snip> > > > > That is silly. What if you could justify C, except you need > > > > dynamic binding too? Then could you justify C++? What about you > > > > need all the features of C, with generic programming as well? > > > > Then is C++ back in > <snip> > > Emphasis on the word *except*. Is your parser broken, or is my mastery > of the english langauge failing me?
Either you're not saying what you mean or you're intentionally trying to mislead the reader. You cannot possibly justify C for any project that would require dynamic binding (late binding, yes, and even "dynamic late binding", but not pure dynamic binding), and conversely you cannot possibly need dynamic binding for any project where C is otherwise 100% appropriate. I.e. what I said was that you cannot even get close to the mere idea of thinking you'll need dynamic binding if you've gotten anywhere close to justifying C based on the merits of language alone. C is a quite simple procedural language that's (usually) compiled and which has a rather basic storage model and only the basic "number-like" data types and a limited manner of defining extended, or more properly aggregate, data types using a model where a block of storage for such an object is treated as an aggregate of sub-fields in a fixed order, each having either a basic type, or some other aggregate type. You cannot have pure dynamic binding unless either: (a) the data defines the code used to manipulate it based on what type it is, and unless the type is not examined until runtime (i.e. you have an OO language); or maybe (b) if the data and the code have identical representations and you have full dynamic programming (eg. as in lisp). BTW, I also have a fundamental problem with this idea of "requiring" dynamic binding, and certainly not at a functional requirements level. While I can perhaps eventually think of applications where dynamic binding may greatly simplify the implementation, I cannot even begin to imagine an application with a functional requirement of being implemented with dynamic binding. That thinking just does not compute. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs