Please suggest use-cases for introspective code generation

On Sep 6, 11:29 am, Mathieu Mazerolle <mathieu.mazero...@gmail.com>
wrote:
> Introspection is very useful, and has applications such as binding C++
> to scripting languages, marshalling objects for RPC, and debugging. In
> fact, if your compiler did not generate introspective information about
> your program, your debugger would not be very useful.

Salut,

W.R.T. debugging, introspection is a bit oxymoronic. Why would there
be a need to inspect into something for which total knowledge is
already available? When a debugger generates meta-data, let's call
it, there is no introspection. It can see all at will. That is
distinctly different from a program ascertaining the type structure of
its classes at run-time.

> It should be a simple matter to define a standard way of inspecting the
> static object model and type system of a C++ program. Why has this not
> been done yet?

What would do the inspecting? The running program or an external
tool? If it is the former, C++ would need to fundamentally change as
a language. If it is the latter, the the information would not be
usesable unless C++ were fundamentally changed as a language.

So all roads would lead to fundamentally changing C++ as a
language.

-Le Chaud Lapin-


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 7, 5:30 am, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Sep 6, 11:29 am, Mathieu Mazerolle <mathieu.mazero...@gmail.com>
> wrote:
>
> > Introspection is very useful, and has applications such as binding C++
> > to scripting languages, marshalling objects for RPC, and debugging. In
> > fact, if your compiler did not generate introspective information about
> > your program, your debugger would not be very useful.
>
> Salut,
>
> W.R.T. debugging, introspection is a bit oxymoronic. Why would there
> be a need to inspect into something for which total knowledge is
> already available? When a debugger generates meta-data, let's call
> it, there is no introspection. It can see all at will. That is
> distinctly different from a program ascertaining the type structure of
> its classes at run-time.

I believe the point is simply that debug info is a counter-example
where compilers have that information and encode it in standard
formats (stabs, COFF, XCOFF, DWARF...) for other systems. It would be
possible to compile one translation unit with debug information, have
a code generation utility read the debug information and generate
further code, then compile that code and link it all up, and you'd
have a very clumsy and indirect but functional introspective
capability. The C++ language wouldn't change at all (addressing the
idea you present below)... C++ could be used to implement the
generation utility: both the core part reading/presenting the debug
information (lots of libraries available), and also the application-
specific use of that information to generate more C++ code. I'm not
suggesting this - other approaches are much more convenient to use and
more powerful - but I'm saying the above is clearly achievable and
Mathieu's example valid.

> > It should be a simple matter to define a standard way of inspecting the
> > static object model and type system of a C++ program. Why has this not
> > been done yet?
>
> What would do the inspecting? The running program or an external
> tool? If it is the former, C++ would need to fundamentally change as
> a language.

Agreed... it would require the kind of change that I believe Walter
Bright made for D: the ability to run some of the code at compiler
time. Then there's the need to coordinate the insertion of the
generated code back into the compilation process. Scary stuff ;-P.

> If it is the latter, the the information would not be
> usesable unless C++ were fundamentally changed as a language.

Wrong. C++ code can already specify and access tree data structures,
look up multimaps, accept vectors of parameters: everything needed to
coordinate the generation of code from a declaration tree made
available by the utility. It simply requires that some developer-
provided C++ code be run during preprocessing. This code can be
specified inside the source code, or calls can be made to precompiled
functions meeting the requisite prototype, which are accessed on
demand using dlopen/dlsym. These functions generate the additional
code to be presented to the compiler. C++ itself is not changed one
iota.

> So all roads would lead to fundamentally changing C++ as a
> language.

Only if it took off in such a big way that compiler vendors wanted to
offer an optimised process, or some extensions.

Tony


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 7, 6:18 am, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
> On Sep 7, 5:30 am, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> I believe the point is simply that debug info is a counter-example
> where compilers have that information and encode it in standard
> formats (stabs, COFF, XCOFF, DWARF...) for other systems. It would be
> possible to compile one translation unit with debug information, have
> a code generation utility read the debug information and generate
> further code, then compile that code and link it all up, and you'd
> have a very clumsy and indirect but functional introspective
> capability. The C++ language wouldn't change at all (addressing the
> idea you present below)... [snip]

Saying that C++ would not change is like declaring that Hebrew will be
integrated into English, but English will not be changed because
nothing in English will be "touched".

C++ is a human language used to define the form and processes of a
system. If it is to remain true to itself, this definition must remain
context-free, in the collaborative sense, within the minds of
engineers/designers/programmers. The moment any superfluous elements
are added to it, elements that redefine the means by which new form or
new processes are achieved, the language itself has changed. If a
programmer or group of programmers decide to use these new superfluous
elements among themselves, there will arise two distinct languages:

1. The old language - Pure C++
2. The new language - Pure C++ fettered by a requisite pre-compiler.

Users who adhere to "1" and only "1" will be oblivious to fact that
new language has been created and will continue to speak the old
language. Users of "2", no matter how small the group, will have the
option of speaking either language, and will have to make a
commitment, up front, which of language "1" or language "2" they will
use. There will never be a situation where they can continue using
"1" but sprinkle in a bit of "2" occasionally, while essentially
retaining "1". There will only be an extent to the prevalence of "2",
and each test of whether "1" or "2" is being used will be determined
on a highly specific case-by-case basis by the absence or existence of
the superfluous elements. For example, if I add a single C++/CLI
keyword to a 1,000,000 line translation unit, that translation unit
will no longer be C++, because a standards-compliant C++ compiler will
rightfully reject it.

Library design might be language design, but proposals like these
represent language transformations.

-Le Chaud Lapin-


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 8, 10:38 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Sep 7, 6:18 am, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
> > It would be
> > possible to compile one translation unit with debug information, have
> > a code generation utility read the debug information and generate
> > further code, then compile that code and link it all up, and you'd
> > have a very clumsy and indirect but functional introspective
> > capability. The C++ language wouldn't change at all (addressing the
> > idea you present below)... [snip]
>
> Saying that C++ would not change is like declaring that Hebrew will be
> integrated into English, but English will not be changed because
> nothing in English will be "touched".
>
> C++ is a human language used to define the form and processes of a
> system. If it is to remain true to itself, this definition must remain
> context-free, in the collaborative sense, within the minds of
> engineers/designers/programmers. The moment any superfluous elements
> are added to it, elements that redefine the means by which new form or
> new processes are achieved, the language itself has changed. If a
> programmer or group of programmers decide to use these new superfluous
> elements among themselves, there will arise two distinct languages:
>
> 1. The old language - Pure C++
> 2. The new language - Pure C++ fettered by a requisite pre-compiler.
>
> Users who adhere to "1" and only "1" will be oblivious to fact that
> new language has been created and will continue to speak the old
> language. Users of "2", no matter how small the group, will have the
> option of speaking either language, and will have to make a
> commitment, up front, which of language "1" or language "2" they will
> use.

In a very pedantic sense, this is true. In a practical sense, using a
preprocessor is like embracing dependency on a library - say boost
spirit. Initial change: for preprocessor "executable_name normal-
compiler-invocation". For Spirit "normal-compiler-invocation -I /some/
dir/include". Both allow some strange new notation that's not
recognisably C++, nor something that 99.999% of programmers could ever
hope to trace, debug or understand. Ultimately, it's a black box that
lets you do stuff, and if you start to use it, like any facility,
there's work to be done if you decide you shouldn't have. In the case
of the preprocessor, you've got standard C++ output code you can
modify directly without further preprocessor involvement. In the case
of Spirit, well - you'll probably have a complete rewrite to use some
tool outside C++. The fact Spirit's actually C++ is irrelevant to the
developer experience of programming in an environment that employs the
library, and chooses to install it. Also, not sure what you're
driving at re "up front commitment"... the decision of whether or not
to use the preprocessor can be made during your 5 year design stage,
or as you stumble along doing RAD... same as any language features or
design. The only way in which an "up front commitment" may seem more
tangible is if the preprocessor is commercial and you are
contemplating a license, then it's no different to a commercial
library.

> There will never be a situation where they can continue using
> "1" but sprinkle in a bit of "2" occasionally, while essentially
> retaining "1". There will only be an extent to the prevalence of "2",
> and each test of whether "1" or "2" is being used will be determined
> on a highly specific case-by-case basis by the absence or existence of
> the superfluous elements.

Sorry, but wrong. (I feel like I have an unfair example here, because
you're imagining abstract things that you believe are impossible, and
I've got a real system providing counter examples.) My system isn't
much different to PHP... where you're in an HTML document most of the
time, and you explicitly denote the sections for the PHP interpreter.
Substitute C++ and preprocessor. There is never any blurring of the
lines. Within both the C++ code outside the preprocessor and the C++
code specified for on-the-fly compilation, there are no new language
rules or hidden transformations (the closest is the implicit wrapping
of in-line code into a function with required prototype and argument
names). So far I have found no need- unlike in OpenC++ where it's a
requirement of the super-classing idiom - is transformation of
existing C++ code. In my experiments so far, it's been entirely
adequate to simply inject new code as required, and the locations for
this in typically at the point of invocation, but at worst is another
location explicitly marked by preprocessor escaping and a linking
identifier.

> For example, if I add a single C++/CLI
> keyword to a 1,000,000 line translation unit, that translation unit
> will no longer be C++, because a standards-compliant C++ compiler will
> rightfully reject it.

And if you put in a single Spirit library usage, your compiler will
reject it if you don't install and provide the path to the library.
Ummm... so?

> Library design might be language design, but proposals like these
> represent language transformations.

As mentioned... not in any meaningful or destructive way. I don't
advocate hidden transformation, only generation of clean C++.

> -Le Chaud Lapin-

Perhaps you would care to contribute some suggested use, or having
transitioned from telling me I'm dreaming about the impossible to
planning to undermine C++ as a language, there's still some other
criticism you'd care to make...? ;-P

Tony


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> 1. The old language - Pure C++
> 2. The new language - Pure C++ fettered by a requisite pre-compiler.

I don't think a pre-compiler is needed to have a reflective object model of
a static type system. A single pass can suffice, and should incur almost no
compile-time overhead, and only executable image-size overhead (to store
data about the program's type system). IE: reflection should cost as much
as exception handling does now.

Being able to browse a program's type heirarchy in a standard way is not a
useless extension in my view. In fact, it's a shame that this was not
stardardized ever since the first versions of C++ (which were implemented
with pre-compilers, and would have found this task trivial).

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 8, 3:28 pm, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
> On Sep 8, 10:38 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> Sorry, but wrong. (I feel like I have an unfair example here, because
> you're imagining abstract things that you believe are impossible, and
> I've got a real system providing counter examples.) My system isn't
> much different to PHP... where you're in an HTML document most of the
> time, and you explicitly denote the sections for the PHP interpreter.
> Substitute C++ and preprocessor. There is never any blurring of the
> lines. Within both the C++ code outside the preprocessor and the C++
> code specified for on-the-fly compilation, there are no new language
> rules or hidden transformations (the closest is the implicit wrapping
> of in-line code into a function with required prototype and argument
> names). So far I have found no need- unlike in OpenC++ where it's a
> requirement of the super-classing idiom - is transformation of
> existing C++ code. In my experiments so far, it's been entirely
> adequate to simply inject new code as required, and the locations for
> this in typically at the point of invocation, but at worst is another
> location explicitly marked by preprocessor escaping and a linking
> identifier.

Let me understand correctly. I _thought_:

1. You take a Pure C++ program.
2. Your preprocessor process that program, analyzes it, generates
extra code.
3. For example, extra code might be generated as a library.
4. Your Pure C++ code can employ functions from that library.

If this is the case, it is "4" that I am concerned with. Even if not
one line of the Pure C++ code is changed, and you have a Pure C++
library that you can now use, the semantic issue still exists. What
is the generated code for, what will it do?

My assertion is that, because computers cannot think, whatever is done
with those libraries will not be automatic. You cannot, for example,
in general, generate correct code for serialization of a class without
annotating the orginal Pure C++ code. The annotation can be done
using one of two methods:

1. Use standard C++ constructs.
2. Use new keywords.

If "1" is used, the tedium involved will require the programmer to
think. But the whole reason for doing it was to relieve the programmer
of thinking. So if the programmer has to think too much while not
thinking, then the purpose is defeated.

If "2" is used, then it is a new language.

So only "1" needs to be considered. So as strange as it sounds, the
answer to your request is your request itself.

"Please suggest use-cases for introspective code generation"

could be reinterpreted as

"Please suggest use-cases for introspective code generation that is
compatible with C++ and does not require the programmer to deal with
tedium any more than he would have without such a facility."

If someone achieved this objective, in the context of serialization,
for example, I would be most impressed. If someone were to do this to
"auto-bind" member fields of objects to their corresponding GUI
controls, I would be impressed.

I guess what I am saying is...I would like to see an example, where,
after the thing to be concocted has been concocted, the programmer
really did save time by doing it using your pre-processing tool,
versus just accomplishing the same thing in Pure C++.

-Le Chaud Lapin-


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 9, 2:58 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Sep 8, 3:28 pm, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
>
>
>
> > On Sep 8, 10:38 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> > Sorry, but wrong. (I feel like I have an unfair example here, because
> > you're imagining abstract things that you believe are impossible, and
> > I've got a real system providing counter examples.) My system isn't
> > much different to PHP... where you're in an HTML document most of the
> > time, and you explicitly denote the sections for the PHP interpreter.
> > Substitute C++ and preprocessor. There is never any blurring of the
> > lines. Within both the C++ code outside the preprocessor and the C++
> > code specified for on-the-fly compilation, there are no new language
> > rules or hidden transformations (the closest is the implicit wrapping
> > of in-line code into a function with required prototype and argument
> > names). So far I have found no need- unlike in OpenC++ where it's a
> > requirement of the super-classing idiom - is transformation of
> > existing C++ code. In my experiments so far, it's been entirely
> > adequate to simply inject new code as required, and the locations for
> > this in typically at the point of invocation, but at worst is another
> > location explicitly marked by preprocessor escaping and a linking
> > identifier.
>
> Let me understand correctly. I _thought_:
>
> 1. You take a Pure C++ program.
> 2. Your preprocessor process that program, analyzes it, generates
> extra code.
> 3. For example, extra code might be generated as a library.
> 4. Your Pure C++ code can employ functions from that library.

No... the tool replaces its invocations sprinkled within the C++ input
- though clearly demarcated - with generated code, then submits that
to the compiler.

> If this is the case, it is "4" that I am concerned with. Even if not
> one line of the Pure C++ code is changed, and you have a Pure C++
> library that you can now use, the semantic issue still exists. What
> is the generated code for, what will it do?

Functionally, I listed half a dozen things I've either implemented or
plan to in the original post, and asked for suggestions.

> My assertion is that, because computers cannot think, whatever is done
> with those libraries will not be automatic. You cannot, for example,
> in general, generate correct code for serialization of a class without
> annotating the orginal Pure C++ code. The annotation can be done
> using one of two methods:
>
> 1. Use standard C++ constructs.
> 2. Use new keywords.
>
> If "1" is used, the tedium involved will require the programmer to
> think. But the whole reason for doing it was to relieve the programmer
> of thinking. So if the programmer has to think too much while not
> thinking, then the purpose is defeated.
>
> If "2" is used, then it is a new language.
>
> So only "1" needs to be considered. So as strange as it sounds, the
> answer to your request is your request itself.
>
> "Please suggest use-cases for introspective code generation"
>
> could be reinterpreted as
>
> "Please suggest use-cases for introspective code generation that is
> compatible with C++ and does not require the programmer to deal with
> tedium any more than he would have without such a facility."
>
> If someone achieved this objective, in the context of serialization,
> for example, I would be most impressed. If someone were to do this to
> "auto-bind" member fields of objects to their corresponding GUI
> controls, I would be impressed.
>
> I guess what I am saying is...I would like to see an example, where,
> after the thing to be concocted has been concocted, the programmer
> really did save time by doing it using your pre-processing tool,
> versus just accomplishing the same thing in Pure C++.

All reasonable concerns. I could illustrate what I consider to be
optimal simplicity of annotation for serialisation, but that's not
really the point. As you say there's a threshold and whether it's
crossed will depend on the application. I'm positive the threshold is
such that automated code generation will prove commonly useful, but
it's certainly not a magic solution. As with actual C++ features,
benefit will be as varied as current C++ usage itself.

I plan to release this by the end of the year, so you'll get to see
then.

(BTW, if anyone's wondering what happened to my promised BENUM macros
for enum identifier streaming (
http://groups.google.com/group/comp....48bf1e8af7da7b
) - they've working (including the enriched masking functionality) and
I've signed off for release. The co-author's busy but trying to get
to them. Definitely not vapour ware and will be released this month ;-
P).

Cheers,

Tony

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Le Chaud Lapin wrote:
[snip]
> My assertion is that, because computers cannot think, whatever is done
> with those libraries will not be automatic. You cannot, for example,
> in general, generate correct code for serialization of a class without
> annotating the orginal Pure C++ code. The annotation can be done
> using one of two methods:
>
> 1. Use standard C++ constructs.
> 2. Use new keywords.
>
> If "1" is used, the tedium involved will require the programmer to
> think. But the whole reason for doing it was to relieve the programmer
> of thinking. So if the programmer has to think too much while not
> thinking, then the purpose is defeated.
>
> If "2" is used, then it is a new language.

What is wrong with creating a new language? Being able to create a new
language in a systematic manner is quite useful. It isn't by accident
that a lot of the faster evolving languages like Python, Java, C# (I use
faster quite loosely here!) use annotations to add meaning to a program.
Here are some possible annotations/extensions to the language that would
be made possible by a programmable representation* of the language:

- Final classes
- Contracts
- Serialization
- Security
- Multiple dispatch

If you can guarantee correct behaviour for each of these things just by
adding annotations, that is a great time saver.

I thank the OP for bringing up this topic. I look forward to reading the
rest of this thread!

Sohail

* I don't like Open C++.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 9, 6:58 am, Sohail Somani <soh...@taggedtype.net> wrote:
> What is wrong with creating a new language? Being able to create a new
> language in a systematic manner is quite useful.

But only as long as it is clear to everyone that it is, in fact, a new
language. Perhaps you remember in 2006 that Microsoft tried extremely
hard to get the world to believe that C++/CLI was just C++ with a bit
of sugar. They even sponsored an article called "Pure C++" by Stan
Lippman:

http://msdn.microsoft.com/en-us/magazine/cc163852.aspx

....deliberately calling it "Pure C++", perhaps through power of
suggestive psychology, to counteract any suspicion in the readers
minds' that gross, non-standard, deviations away from C++ were being
made.

The problem is not with new languages. They are created all the time.
The problem is taking your entire stock of aluminum, and infusing it
with reinforced carbon, because you learned through experiment that
reinforced carbon is *really really* awesome.

We, as engineers, deliberately choose the tools we employ to construct
systems. There are always trade-offs when choosing one over the
other. A feature of a tool or primitive will be beneficial in one
context, and detrimental in another.

For example, instead of throwing an exception for irrecoverable error,
some "languages" will put up a message box to the user. This gentle
message box uis wonderful, and the users of those languages love it.
Is that something that should be done in C++?

Programming languages are not pots of soup. It is not a good idea to
take as many "beneficial" features of tools and primitives at same
level of abstraction and throw them all together. To do so in any
language, not just C++, would ruin its spirit, if such a spirit
exist.

Take Scheme for example. It is a nice, soft, language. You can write
code and let it execute, and when it crashes, the softness is like a
marshmallow falling on a pillow, with no exceptions. But as we all
know from C++, exceptions are good. So we should add exceptions to
Scheme?

Scheme is also a favorite in computer science research, number theory
included. But Scheme is slow. Maybe we should add the _asm statement
from C++ to Scheme. After all, it would not change the language. It's
just a new keyword that would not interfere with existing Scheme
code. Would that be good? Imagine expecting every Scheme-conformant
interpreter to suppport _asm.

But why stop there. C++ is not the only good language. BASIC has some
nice features too. So does Pascal. So does Forth. FORTRAN,
COBOL....How about adding code where super-documentation can be
generated directly from the code, not like Doxygen, but something that
could go straight to 4-colour printer?

What we _could_ do is go to each programming language, look at each
feature of it, and ask whether C++ contains something similar. If not,
then we could add it to C++. Would that be prudent, even if it is
feasible?

Right now, fortunately, C++ is good at a few things. If we "mash" in
features from other languages, we might violate the spirit of it make
it good at nothing.

> It isn't by accident
> that a lot of the faster evolving languages like Python, Java, C# (I use
> faster quite loosely here!) use annotations to add meaning to a program.
> Here are some possible annotations/extensions to the language that would
> be made possible by a programmable representation* of the language:
>
> - Final classes
> - Contracts
> - Serialization
> - Security
> - Multiple dispatch

> If you can guarantee correct behaviour for each of these things just by
> adding annotations, that is a great time saver.

Just make sure it is called something else, not C++.

> I thank the OP for bringing up this topic. I look forward to reading the
> rest of this thread!
>
> Sohail
>
> * I don't like Open C++.

I had never heard of it until yesterday.

Note that I have no problem with something like OpenC++. I think there
_should_ be a place others can go to experiment with a new language,
that, from a distance, looks vaguely like C++, but really is not.

That way, if it turns out that such gross changes to the language
does, indeed, erode its integrity, no harm is done.

Those that have changed it will have what they want, and those that
have stayed with C++ will have what they want, and if it is true that
the existence of the new "++C++" is inconsequential to "C++", as the
proponents of change seem to imply, then there will be no reason for
objection to this equal-but-not-equal approach.

-Le Chaud Lapin-


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 10, 7:14 am, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Sep 9, 6:58 am, Sohail Somani <soh...@taggedtype.net> wrote:
>
> > What is wrong with creating a new language? Being able to create a new
> > language in a systematic manner is quite useful.
>
> But only as long as it is clear to everyone that it is, in fact, a new
> language. Perhaps you remember in 2006 that Microsoft tried extremely
> hard to get the world to believe that C++/CLI was just C++ with a bit
> of sugar. [...]
> ...deliberately calling it "Pure C++", perhaps through power of
> suggestive psychology, to counteract any suspicion in the readers
> minds' that gross, non-standard, deviations away from C++ were being
> made.

Disgraceful. I knew they'd tried to hijack Java developers into
writing platform-dependent code unawares, but I didn't know about this
C++/CLI thing.

> The problem is not with new languages. They are created all the time.
> The problem is taking your entire stock of aluminum, and infusing it
> with reinforced carbon, because you learned through experiment that
> reinforced carbon is *really really* awesome.
>
> We, as engineers, deliberately choose the tools we employ to construct
> systems. There are always trade-offs when choosing one over the
> other. A feature of a tool or primitive will be beneficial in one
> context, and detrimental in another.

I'd point out that in many physical systems, there are necessary
compromises. Your reinforced aluminium may be stronger but more
brittle. Some applications may require it to break at a particular
stress, or to flex or compress by a particular amount under certain
load. Different density might make it too light or heavy for
substitution in some existing application.

But in software systems, it doesn't really matter if your tool can do
something you don't ask it to. The extra code doesn't need to affect
the existing uses of the tool. Adding a nail-removing claw to a
hammer might affect it's centre of mass, weight, moment of inertia or
whatever. But a backwards-compatible language extension doesn't have
any affect on code that doesn't use it.

[snip]
> What we _could_ do is go to each programming language, look at each
> feature of it, and ask whether C++ contains something similar. If not,
> then we could add it to C++. Would that be prudent, even if it is
> feasible?

No. But it is prudent to look at other languages and ask "would that
be useful, would it fit in, would it help people solve problems well".

> Right now, fortunately, C++ is good at a few things. If we "mash" in
> features from other languages, we might violate the spirit of it make
> it good at nothing.

Maybe you could, if you let it happen in an uncontrolled way.

> > It isn't by accident
> > that a lot of the faster evolving languages like Python, Java, C# (I use
> > faster quite loosely here!) use annotations to add meaning to a program.
> > Here are some possible annotations/extensions to the language that would
> > be made possible by a programmable representation* of the language:
>
> > - Final classes
> > - Contracts
> > - Serialization
> > - Security
> > - Multiple dispatch
> > If you can guarantee correct behaviour for each of these things just by
> > adding annotations, that is a great time saver.
>
> Just make sure it is called something else, not C++.

C++ is evolving, not stagnant. Do you approve of the proposed C++0x?
Will it still be C++? How did that change occur? I suggest that it's
appropriate to postulate new features/abilities that we'd like to have
in C++. It's appropriate to talk and reason about them. It's even
better to hack up compilers/pre-processors to support non-Standard
experimental features, apply them to legacy code to see if it improves
things, tell others about it, invite them to try it, and agitate for
inclusion in C++0x or beyond. It's what keeps C++ at the forefront of
languages.

Don't mistake what I'm doing - or Sohail's suggestions above - for
something distinct from this process. Granted I'm not on the
Standards Committee pushing from the inside... but so what? That's
not required or expected. Boost libraries are being adopted and I
can't imagine all their authors are in the Committee. I wouldn't
bother programming C++ if I didn't have respect for the integrity of
vision of the people who're shaping it. Demonstrate utility, and a
general understanding of backwards compatibility and practical issues,
and I'm confident people will pay attention in proportion to the
benefits (pressure builds up if they don't ;-)). Of course my hope is
that an introspective facility will be adopted in C++1x or whatever
it'll be called. So, as a community, we've got to get tangible
offerings out there, gather a wealth of real-world experience, and
start evolving something worthy.

So, perhaps I can summarise your second argument (post "that's
impossible") as saying my post is off topic? My contention is that
evolution of C++ is on topic, and my post is ultimately directed
towards that.

Cheers,
Tony

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]