In article <cefd6cde.0306170153.b5960a5@posting.google.com>,
 on Fri, 20 Jun 2003 19:35:54 +0000 (UTC),
 Michiel.Salters@cmg.nl (Michiel Salters) wrote:

> francis@robinton.demon.co.uk (Francis Glassborow) wrote in message
> news:<1rnIubAQ7f7+EwNy@robinton.demon.co.uk>...
> >
> > Yes, but there are a lot of members of NBs represented on WG21 that are
> > not compiler implementors. For example, the UK vote is certainly not
> > 'controlled' by implementors.
>
> IIRC all compiler vendors are American, right?
> (I'm intentionally excluding GCC)

No, there are non-American compiler vendors (I am aware of at least
two who are UK based, for instance). I'm not sure how many of them
attend ISO meetings though (e.g. I'm not aware of either of the two UK
vendors I mention at any ISO meeting I've attended - or even a UK
panel meeting come to that)

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) wrote in message
news:<1rnIubAQ7f7+EwNy@robinton.demon.co.uk>...
> In article <8h0rev8vtdf4f57ocr91jp9aei0946h4e8@4ax.com>, Gennaro Prota
> <gennaro_prota@yahoo.com> writes
> >Yep. But I also imagine "comparatively little code" depends a lot on
> >how the compiler code is (dis)organized. Since, AFAIK, the
> >standardization process works "by vote" and since not all compiler
> >vendors are passionate like you (though I'm sure you aren't the only
> >one either) I imagine it may also happen that vendor xyz goes
> >examining his codebase and sees that a given proposal would require,
> >to him, a lot of code refactoring and re-testing; thus he could vote
> >against it, even if it is in theory a simple addition. Is it so?

> Yes, but there are a lot of members of NBs represented on WG21 that
> are not compiler implementors. For example, the UK vote is certainly
> not 'controlled' by implementors.

Strictly speaking, none of the NBs represent compiler implementors.
They represent committees; who is in the committee depends on the
national body, as each body is free to make its own rules.

Practically speaking, I don't think that compiler implementors represent
a majority of the voting members in any national body.  Practically
speaking, however, compiler implementors seem to be the only people
willing to do the work.  (I'm exagerating, of course, but I don't think
anyone would want to minimize the contributions of the implementors in
terms of work done.)  If, for example, compiler implementors had an
enormous say concerning the rules of template name lookup, it's not
because they had more votes, or because the committee wouldn't listen to
anyone else, it is because no one else was willing to invest the
man-years of effort necessary to work out a proposal.

In the end, I don't think it is a great problem, either.  All of the
compiler implementors I've met make a tremendous effort to understand
what their users want and need, and generally speaking, try to represent
their users as much as themselves.  Even when it means more work for
them.  I am sure that there are exceptions, but I don't think that they
are (or were) very active in the committee.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel.Salters@cmg.nl (Michiel Salters) wrote in message news:<cefd6cde.0306170153.b5960a5@posting.google.com>...
> francis@robinton.demon.co.uk (Francis Glassborow) wrote in message news:<1rnIubAQ7f7+EwNy@robinton.demon.co.uk>...
> > In article <8h0rev8vtdf4f57ocr91jp9aei0946h4e8@4ax.com>, Gennaro Prota
> > <gennaro_prota@yahoo.com> writes
> > >I imagine it may also happen that vendor xyz goes
> > >examining his codebase and sees that a given proposal would require,
> > >to him, a lot of code refactoring and re-testing; thus he could vote
> > >against it, even if it is in theory a simple addition. Is it so?
> >
> > Yes, but there are a lot of members of NBs represented on WG21 that are
> > not compiler implementors. For example, the UK vote is certainly not
> > 'controlled' by implementors.
>
> IIRC all compiler vendors are American, right?
> (I'm intentionally excluding GCC)

I obviously was forgetting a number of companies, including Fujitsu-Siemens
and some EDG licensees.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) wrote in message news:<1rnIubAQ7f7+EwNy@robinton.demon.co.uk>...
> In article <8h0rev8vtdf4f57ocr91jp9aei0946h4e8@4ax.com>, Gennaro Prota
> <gennaro_prota@yahoo.com> writes
> >I imagine it may also happen that vendor xyz goes
> >examining his codebase and sees that a given proposal would require,
> >to him, a lot of code refactoring and re-testing; thus he could vote
> >against it, even if it is in theory a simple addition. Is it so?
>
> Yes, but there are a lot of members of NBs represented on WG21 that are
> not compiler implementors. For example, the UK vote is certainly not
> 'controlled' by implementors.

IIRC all compiler vendors are American, right?
(I'm intentionally excluding GCC)

It's perhaps not widely known, but in theory the US including EDG,
Microsoft, Intel and the other "heavies" has one vote just like
any other country represented when it comes to an ISO vote. If
one of them wants a proposal withdrawn, they'll have to present
solid arguments - that's when their voice counts most. That's
also why votes are rare and consensus is preferred.

Regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gennaro_prota@yahoo.com (Gennaro Prota) wrote:
> On Tue, 10 Jun 2003 20:01:25 +0000 (UTC), google@vandevoorde.com
> (Daveed Vandevoorde) wrote:
>
> >It is true that the metacode extension I'm working on is
> >much more than just compile-time function evaluation.
> >However, if the added mechanisms are implementable with
> >comparatively little code, it may be a more compelling
> >extension because it solves a considerably larger problem.
>
> Yep. But I also imagine "comparatively little code" depends a lot on
> how the compiler code is (dis)organized.

It might in theory, though for the front ends whose source code
I'm familiar with the "order of magnitude" is not very different
when it comes to code size.

> Since, AFAIK, the
> standardization process works "by vote" and since not all compiler
> vendors are passionate like you (though I'm sure you aren't the only
> one either) I imagine it may also happen that vendor xyz goes
> examining his codebase and sees that a given proposal would require,
> to him, a lot of code refactoring and re-testing; thus he could vote
> against it, even if it is in theory a simple addition. Is it so?

In theory it could be, and occasionally this might have happened.
However, most of the time my impression is that most vendors vote
according to "what seems right for programmers" even when it might
mean considerably more work for them (or they abstain).

> >(Note that I'm not sure the "metacode extension" is a
> >must-have for C++.  It's still an experiment at this point;
> >not a proposal.  That said, the experiment is showing much
> >promise so far.)
>
> Great! :-) FWIW, I heartily encourage you to continue on it. BTW, if
> we can help in some way (with testing, for instance) I'm pretty sure
> it won't be hard to find volunteers, e.g. on c.l.c++.m or at boost :-)

Thanks.  I certainly intend to continue completing the
implementation, even though it is an after-hours project
(and takes a back seat to various family activities; hence
progress is slow).  I also intend to report any significant
advance on my web-page (vandevoorde.com).

A small group of people have the current state of my
implementation (some of them are Boosters), but at this
point you need an EDG source license to have access to
that.  (My implementation is not endorsed in any way by
EDG, but it builds on top of the EDG front end.)

        Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 10 Jun 2003 20:01:25 +0000 (UTC), google@vandevoorde.com
(Daveed Vandevoorde) wrote:

>It is true that the metacode extension I'm working on is
>much more than just compile-time function evaluation.
>However, if the added mechanisms are implementable with
>comparatively little code, it may be a more compelling
>extension because it solves a considerably larger problem.

Yep. But I also imagine "comparatively little code" depends a lot on
how the compiler code is (dis)organized. Since, AFAIK, the
standardization process works "by vote" and since not all compiler
vendors are passionate like you (though I'm sure you aren't the only
one either) I imagine it may also happen that vendor xyz goes
examining his codebase and sees that a given proposal would require,
to him, a lot of code refactoring and re-testing; thus he could vote
against it, even if it is in theory a simple addition. Is it so?

>(Note that I'm not sure the "metacode extension" is a
>must-have for C++.  It's still an experiment at this point;
>not a proposal.  That said, the experiment is showing much
>promise so far.)

Great! :-) FWIW, I heartily encourage you to continue on it. BTW, if
we can help in some way (with testing, for instance) I'm pretty sure
it won't be hard to find volunteers, e.g. on c.l.c++.m or at boost :-)


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <8h0rev8vtdf4f57ocr91jp9aei0946h4e8@4ax.com>, Gennaro Prota
<gennaro_prota@yahoo.com> writes
>Yep. But I also imagine "comparatively little code" depends a lot on
>how the compiler code is (dis)organized. Since, AFAIK, the
>standardization process works "by vote" and since not all compiler
>vendors are passionate like you (though I'm sure you aren't the only
>one either) I imagine it may also happen that vendor xyz goes
>examining his codebase and sees that a given proposal would require,
>to him, a lot of code refactoring and re-testing; thus he could vote
>against it, even if it is in theory a simple addition. Is it so?

Yes, but there are a lot of members of NBs represented on WG21 that are
not compiler implementors. For example, the UK vote is certainly not
'controlled' by implementors.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

algrant@myrealbox.com (Al Grant) wrote in message news:<5765b025.0306030112.48016420@posting.google.com>...
> It's annoying that a macro can't be replaced by an equivalent
[...]

Hi Al.
  Currently, We (myself and a group in a local university) are working
on a prototype for an    interpreted compile time   , exactly the
   precomp    modifier.
When I saw Daveed   s presentation, I got very surprised because,
functionally it does -among other things- what we are trying to do.
However, this works a little bit different.

Conceptually, we add a new phase, after preprocessor and before
compiler, called "precompilation".
The output of the precompilation phase will be constant expressions
for the compilation phase.

The    precomp    modifier is about the code to be    interpreted    during
this phase, and is:
 -a class-level modifier
 -a function/method-level modifier
 -a variable/attribute level modifier

for example, you can provide somewhere

precomp single atan(single n)
{
   ...
}

and otherwhere:

void f()
{
   const single pi = atan(1)*4;
}

then pi will receive its value at compile time, while the atan(1) will
be executed in the precompilation phase.

The restrictions are:
 - a precomp function can only receive constant expression parameters
or precomp-declared variables as parameters
 - a precomp function can modify only global precomp-declared
variables
 - a precomp method can only modify precomp attributes
 - the precomp method modifier can act as overloading agent (you may
have your precomp and    non   precomp overladed methods)
 - during precompilation phase, only precomp functions/methods can be
invoked.
 - during compilation phase, if a non-overloaded precomp method
(meaning: ther   s no    non   precomp version) is invoked, it will be
considered as a regular method/function. Otherwise, non-precomp
function/method is preferred.
 - precomp code not used in compilation phase is discarded (so does
not generate bytecode).

Weaknesses: a precomp function may enter in an infinite loop (in our
prototype).

You may get the following error types during precompilation phase:
  - "precomp exceptions" thrown by precomp functions
  - errors during the execution of the precomp code
  - ... (sorry, don   t remember :( what else)

It   s part of a bigger project, called Dpp. In fact, it is a plug-in of
the Dpp.

Additionally, you can perform some checkings. For example, imagin

template <int min, int max> class Range
{
   precomp Range()
   {
      if(max<min)
        throw ...
   }
}

so declaring
  Range(3,1)
would throw a precomp exception and will abort the complete
compilation process, instead of checking it during run time and
avoiding    assert   s.

  Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

algrant@myrealbox.com (Al Grant) wrote:
> tslettebo@chello.no.nospam (Terje Sletteb   ) wrote in message news:<sBhDa.10058$KF1.143192@amstwist00>...
> > Daveed Vandevoorde has a proposal for just this:
>
> Daveed's metacode is not "just this", it is conceptually a much
> further step along the road to preprocessing - for example you
> can test a formal parameter to see whether the actual argument is
> an lvalue, you can look up string literals as names etc.
>
> I think my proposal is much simpler both conceptually and
> technically - in short, uncontroversial.

There are lots of extensions that are conceptually and
technically simple, yet are highly unlikely to become
part of the standard for other reasons.  E.g., the "bang
for the buck" factor may seem too small.  Or it may just
clash with the overall flavor of the language.  And so
on.

I.e., we're not looking for small solutions per se.
Instead, we're looking for efficient/elegant solutions to
large and/or embarassing problems.

It is true that the metacode extension I'm working on is
much more than just compile-time function evaluation.
However, if the added mechanisms are implementable with
comparatively little code, it may be a more compelling
extension because it solves a considerably larger problem.
(Note that I'm not sure the "metacode extension" is a
must-have for C++.  It's still an experiment at this point;
not a proposal.  That said, the experiment is showing much
promise so far.)

[...]

        Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

It's annoying that a macro can't be replaced by an equivalent
inline function when its result is used in constant-expression
contexts.  The definition of constant-expression seems too
syntactically oriented and prevents natural abstractions.

Is there any technical reason why, if the arguments to an inline
function are constant-expressions, and substituting them in the
function body would result in a constant-expression, the overall
call expression should not be a constant-expression?  Would it be
controversial to do this in the next standard?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Constant expressions are evaluated at compile time and not run-time.
"Inline" is just a suggestion to inline the function body, not a command to
do so. It is an implementation's decision whether or not to inline a
function. Naturally non-inlined function calls are resolved at run-time and
not compile-time, so they couldn't be used as constant expressions. Even if
"inline" were a guarantee to inline a function call, I believe the C++
standard would have to define what it means that a "function body is a
constant expression" in order to allow an inlined function to be used as
constant expression.

Al Grant wrote:
> It's annoying that a macro can't be replaced by an equivalent
> inline function when its result is used in constant-expression
> contexts.  The definition of constant-expression seems too
> syntactically oriented and prevents natural abstractions.
>
> Is there any technical reason why, if the arguments to an inline
> function are constant-expressions, and substituting them in the
> function body would result in a constant-expression, the overall
> call expression should not be a constant-expression?  Would it be
> controversial to do this in the next standard?]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Edward Diener"" <eldiener@earthlink.net> wrote in message
news:vb6Da.32439$Io.2774286@newsread2.prod.itd.earthlink.net...
> Constant expressions are evaluated at compile time and not run-time.
> "Inline" is just a suggestion to inline the function body, not a
command to
> do so. It is an implementation's decision whether or not to inline a
> function. Naturally non-inlined function calls are resolved at
run-time and
> not compile-time, so they couldn't be used as constant expressions.
Even if
> "inline" were a guarantee to inline a function call, I believe the C++
> standard would have to define what it means that a "function body is a
> constant expression" in order to allow an inlined function to be used
as
> constant expression.

Daveed Vandevoorde has a proposal for just this: To be able to mark a
function as "metacode", so it's executed at compile-time, and hence
should be possible to use in a context requiring an integral constant
expression. See here
(http://www.vandevoorde.com/Daveed/News/Archives/000015.html). He's been
working on implementing it in an internal version of the EDG compiler
front-end.


Regards,

Terje

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

algrant@myrealbox.com (Al Grant) wrote:
> It's annoying that a macro can't be replaced by an equivalent
> inline function when its result is used in constant-expression
> contexts.  The definition of constant-expression seems too
> syntactically oriented and prevents natural abstractions.
>
> Is there any technical reason why, if the arguments to an inline
> function are constant-expressions, and substituting them in the
> function body would result in a constant-expression, the overall
> call expression should not be a constant-expression?  Would it be
> controversial to do this in the next standard?

Your phrase
    "substituting them in the function body would
     result in a constant-expression"
has no meaning today.  After all, a function body
is not an expression.

So one sort-of-technical reason is that it would take
a lot of specification work to do this.

I've been working on a language extension that does what
you want (and much more!), but instead of using the
keyword "inline" you must use a new keyword "metacode".

E.g.:

  metacode int abs(int a) {
    if (a<0) return -a;
    else return a;
  }
  double x[abs(-7)];  // OK.

I have no doubt that such a sizable extension will
trigger at least some controversy.

         Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

tslettebo@chello.no.nospam (Terje Sletteb   ) wrote in message news:<sBhDa.10058$KF1.143192@amstwist00>...
> Daveed Vandevoorde has a proposal for just this:

Daveed's metacode is not "just this", it is conceptually a much
further step along the road to preprocessing - for example you
can test a formal parameter to see whether the actual argument is
an lvalue, you can look up string literals as names etc.

I think my proposal is much simpler both conceptually and
technically - in short, uncontroversial.  I'm not claiming
it's clever; it seems more like an obvious step to allow
inline functions to replace one of the remaining routine
uses of preprocessor macros.  I'm going for quantity, not power!
Think of it not about making inline functions more powerful but
about making the definition of "constant expression" less
arbitrary in terms of allowed syntax.

The only technical aspect I didn't mention (I think) was
recursion, but I don't think that's controversial either -
just have an implementation limit and a standardized minimum.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Al Grant" <algrant@myrealbox.com> wrote in message
news:5765b025.0306050101.377a8789@posting.google.com...
> tslettebo@chello.no.nospam (Terje Sletteb=F8) wrote in message
news:<sBhDa.10058$KF1.143192@amstwist00>...
> > Daveed Vandevoorde has a proposal for just this:
>
> Daveed's metacode is not "just this"

There appears to have been a misunderstanding. With "just this", I meant
"exactly this" (such an example, of using the result of a "metacode"
function as an integral constant expression, is in the notes of the
proposal). I didn't mean "only this". After all, that should be clear
from the link I gave.

> it is conceptually a much
> further step along the road to preprocessing - for example you
> can test a formal parameter to see whether the actual argument is
> an lvalue, you can look up string literals as names etc.

I know.

> I think my proposal is much simpler both conceptually and
> technically - in short, uncontroversial.

Have you talked with any standards committee members or compiler
implementers about it? On what do you base the opinion that it's
uncontroversial?

Currently, what constitutes an integral constant expression is very
limited. Extending that to quite arbitrary code is a quite major change,
and is some of what Daveed's proposal is about. That's also what seems
to be needed for what you suggest.

> I'm not claiming
> it's clever; it seems more like an obvious step to allow
> inline functions to replace one of the remaining routine
> uses of preprocessor macros.  I'm going for quantity, not power!
> Think of it not about making inline functions more powerful but
> about making the definition of "constant expression" less
> arbitrary in terms of allowed syntax.
>
> The only technical aspect I didn't mention (I think) was
> recursion, but I don't think that's controversial either -
> just have an implementation limit and a standardized minimum.

I can't really see how your proposal is different from Daveed's
"metacode" proposal (in other words, that part of his proposal, that you
can declare a function as "metacode")..


Regards,

Terje

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]