On 20 Feb 2006 05:33:40 -0500, "Greg Herlihy" <greghe@[EMAIL PROTECTED]
>
wrote:
>Rich Grise wrote:
>> On Sat, 18 Feb 2006 00:37:18 -0800, Le Chaud Lapin wrote:
>> ...
>> > expert who has participated in the standards process, Stan Lippman,
>> > called "Pure C++".
>> > (http://msdn.microsoft.com/msdnmag/issues/05/02/PureC/default.aspx)
The
>> > first thing you notice about the code written in this column is that
it
>> > is anything but pure C++. Instead, there is .NET fecal matter
>>
>> I never got to anything like "C++"; this stopped me:
>> " It sup****ts a static object model that is optimized for the speed
and
>> size of its executables. However, it doesn't sup****t runtime
modification
>> of the program other than heap allocation."
>>
>> Well, duh! That's kinda the _point_ of C++, isn't it?
>
>But C++ does allow program modification at compile-time, through
>programmatic code generation with templates. Extending that capability
>from compile-time to runtime would seem to be an obvious, and not
>particularly momentous, step. So the fact that C++ currently lacks
>runtime program modification I would view as a limitation of the
>current language - rather than to reflect a conscious design decision
>informed by some deeply-held, overaching philosophy. Moreover a
>philosophical basis for not sup****ting this feature would be completely
>moot. Since C++ has no underlying runtime with which to sup****t dynamic
>program modification, it's simply inconceivable that C++ could ever
>sup****t such a feature in a practical way. So any discussion about
>adding runtime program modification to C++ would - in almost all
>certainty - be no kind of a discussion at all.
>
>Now the word "limitation" in the paragraph above has a strictly neutral
>connotation. After all, this limitation may not be one that anyone who
>uses C++ has ever cared about. But by the same token, it is difficult
>to see how a limitation that some group of programmers do care about,
>is ever likely to be a net benefit for a programming language. After
>all there are at least some current language features in C++ (goto,
>macros, #defines come to mind) that are widely disdained by many C++
>programmers. Yet the fact that C++ does sup****t such unpopular language
>features probably does not deter large numbers of programmers from
>writing software in C++. And the explanation is simply that it is quite
>straightfoward to write a C++ program that simply avoids using these
>constructs. Likewise, even those adamently opposed to runtime program
>modification as a practice, could simply refrain from modifying their
>program at runtime were C++ suddenly (and somewhat magically) able to
>sup****t such behavior.
>
>And for the benefit of anyone who has dreamt of using runtime program
>modification in C++, it is certainly legitimate to point out that
>C++/CLI has such sup****t and that C++ does not. It would be extremely
>difficult for C++ advocates to criticize such language feature
>comparisons, precisely because one of the more effective (and quite
>legitimate) selling points used for years to promote C++ over C as a
>better programming language, has been to enumerate all of the language
>features that C++ sup****ts and which C does not.
C++ is complex and obscure enough already without adding runtime code
modification. Programming should be about producing reliable programs,
not playing complex mental games and poli****ng resumes.
But more im****tantly, the astoni****ng virus sensitivity of Windows is
largely due to the stack orientation of C-style languages combined
with the lack if I/D space separation. Code and data are so mixed up
that a stack overflow almost always pokes a hole into executable code,
and Microsoft is helpless to prevent it. The Windows attitude is "when
in doubt, execute it" when it should be "when in doubt, trap it."
Even a PDP-11 understood that code segments should be read-only, and
data segments should be unexecutable, and that code, data, and stack
should be in totally disjoint spaces.
None of my ROM-based embedded systems have ever had a virus.
John
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
