"kwikius" <andy@servocomm.freeserve.co.uk> wrote in message
news:2873fa46.0407241512.58c3c2e1@posting.google.com...
> Usenet@aristeia.com (Scott Meyers) wrote in message
news:<MPG.1b5e67da917bb68d989775@news.hevanet.com>...
>
> Concepts.
> Basically template parameters that conform to a set of requirements.
> One day Concepts will replace types as C++ primitives IMO.

They're not really a replacement for types. Rather, they're a way of
grouping related types together (such as all types that are Assignable, for
example). As you said, template parameters (instantiated with types) that
conform to a set of requirements.

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                       ]

Usenet@aristeia.com (Scott Meyers) wrote in message news:<MPG.1b5e67da917bb68d989775@news.hevanet.com>...
> C++0x will offer new features compared to C++03+TC1+TR1.  We don't know for
> sure what those features will be, but presumably some are much more likely
> than others.  As a non-member of the standardization committee who follows
> the process only informally but who is responsible for trying to help
> practicing programmers keep an eye on what is likely to happen in the
> future, I'd be interested in others' guesses as to what language and
> library features are likely to make it into C++0x.
>
> FWIW, this is my list, bearing in mind that I'm treating TR1 as already
> included, even though I know that it's not:
>   - forwarding constructors
>   - something like typeof (maybe auto, maybe both)
>   - move constructors
>   - no need to define const static integral members whose address is not
>     taken
> Should any of these not be on the list?  What other things should be?
>
> I'm primarily interested in "big" features as opposed to "little"
> refinements to existing features.  Forwading constructors qualify.
> Typeof/auto qualifies.  Move constructors qualify.  The const static
> definition thing doesn't qualify, but it's on my list, because, hey, it's
> my list, so I can break the rules if I want to :-)
>
> All help appreciated.  Again, I know that we can't predict the future, but
> some things are a lot more likely than others.  I'd just like to know what
> they are so that I can tell people who ask me.

Concepts.
Basically template parameters that conform to a set of requirements.
One day Concepts will replace types as C++ primitives IMO.

And BTW STATIC_ASSERT  ...no   Make this a TrueConcept || FalseConcept

regards
Andy Little
                     ]

---
[ 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                       ]

"Andrei Alexandrescu (See Website for Email)" wrote:
>
> Here are some syntactic forms. LISP aficionados will love that:
>
> using! "filename";
>
> because traditionally in LISP mutating functions terminate in a bang. One
> that adds a special word that has a meaning only in this context (it's
> called keyword as opposed to reserved words):

Would I be able to write

 using not "filename";

as an equivalent form?

---
[ 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                       ]

""Ken Hagan"" <K.Hagan@thermoteknix.co.uk> wrote in message
news:opsbj64djum60l4k@aries.lan...
> "Andrei Alexandrescu (See Website for Email)" wrote:
> >
> > Here are some syntactic forms. LISP aficionados will love that:
> >
> > using! "filename";
> >
> > because traditionally in LISP mutating functions terminate in a bang.
One
> > that adds a special word that has a meaning only in this context (it's
> > called keyword as opposed to reserved words):
>
> Would I be able to write
>
> using not "filename";
>
> as an equivalent form?

:oD

Out the window goes one possible form. Besides, it takes a lot of
imagination to associate"mutation" with "multiple inclusions"...

I have come to like:

using "filename" *;

because "*" is "multiplication" ("multiple times") in C++ and also Kleene
closure ("zero or many") in regular expressions...

Now really, is there any proposal out there to integrate file inclusion in
the language? I think it would a small easy useful step towards shifting
work from the preprocessor to the compiler.


Andrei


---
[ 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                       ]

Andrei Alexandrescu (See Website for Email) wrote:
> Now really, is there any proposal out there to integrate file inclusion in
> the language? I think it would a small easy useful step towards shifting
> work from the preprocessor to the compiler.

    The general idea with

 using "file specifier";

has been roughly as follows:

    1.  Inclusion occurs only once per content being included.
    2.  "using" inclusion is only allowed in a top-level declaration
        context.
    3.  Implementations may support "using" of preprocessed content
        such as precompiled declarations.
    4.  The "file specifier" field may contain forms which request
        a search for the file.

Open questions are:

    -- How portable should "file specifier" be?
    -- Should "file specifer" have suffixes (.h, .hpp, etc.)?
    -- How is "once" defined?  Same name?  Same location in
       file system?  Identical content?
    -- Are there scope issues to be resolved?
       Is "using" allowed inside "namespace", and if so, does
       it put the content in that namespace?
    -- Are preprocessor commands allowed in content included
       with "using"?
    -- The notion of "search for the file" needs to be
       clarified.

Looking ahead, as file systems become more database-oriented
and search functions improve, should we simply say that

 using namespace foo;

imples finding the definitions for namespace foo and bringing
them in?

    John Nagle

---
[ 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                       ]

dave@boost-consulting.com (David Abrahams) writes:
[snip]
> Just to clarify -- I wasn't trying to make any judgements about XTI
> other than that it's got very little going for it in the "liklihood
> of standardization" department other than that it's Bjarne's
> project.  At this point there's little reason to be surprised if it
> isn't part of the next standard... especially if it uses a tool
> external to the regular compiler.
[snip]

I can't help but note the preprocessor began life as a tool external to
    the regular compiler - and as far as I know, most unix C++
    implemantations still make the preprocessor availible as a
    stand-alone executable, and still accept pre-processed input from
    an external tool (though the default compile mode usually uses an
    integrated preprocessor).


---
[ 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                       ]

dave@boost-consulting.com (David Abrahams) writes:

[...]

| > | Don't be; AFAIK Bjarne hasn't done anything with that project for
| > | quite a while
| >
| > That is untrue -- that is a subject of active, daily, discussions between
| > him, me and his students. :-)
| >
| > |                and he's never brought a paper before the committee.
| >
| > Agreed.
| >
| > | The world at large has never even seen a prototype.  Furthermore,
| > | Bjarne's work is not an in-language solution -- it relies on external
| > | tools to generate XML from GCC's debug info.
| >
| > We're working -- on daily basis -- on that project and things are
| > evolving -- maybe not as fast as you'd like, but progress has been
| > made.  You're quite right that it is not a language  built-in
| > solution.  As of today, it is a library solution and it can represent
| > all existing C++ notions (classes, functions, templates, ...).
|
| Just to clarify -- I wasn't trying to make any judgements about XTI

I wasn't saying you were making any judgements.  I was just bringing
complementary information for those who were wondering about that
project or would believe or would talk others into believing that
nothing has been done with that project for quite a while.  After all,
if one doesn't know about the existence of something, it is reasonable
to assume it doesn't exist -- what you don't know won't hurt you ;-/

| other than that it's got very little going for it in the "liklihood
| of standardization" department other than that it's Bjarne's
| project.  At this point there's little reason to be surprised if it
| isn't part of the next standard... especially if it uses a tool
| external to the regular compiler.

I'm not surprised about anything [except maybe the fact that people
seem to have good memory ;-)], especially about it not being
standardized.  I can't speak for Bjarne, but I think that working on
several standardization projects at the same time AND completing
daytime job requires a deat deal of time.

As of XTI or IPR, it is not unusual for people to believe that any
functionality sufficiently "powerful" should be built in the
language or compiler.  I'm not the right person to make a fair
judgement on that project.  But, what I can offer as a personal,
most certainly biased opinion is that it has more chance to be
accepted if it were compiler neutral rather than tied to a particular
one.  I'm not sure that if it were using a tool non-external to the
"regular compiler" (I don't know what a "regular compiler" is), it would
be likely to be part of the next standard.

Also, we've learnt some lessons about the "regularity" of formulation
of some rules in the Standard, and how some innocent looking, little
details can matter.

But, the most interesting part, I believe, is what IPR would bring to
the C++ community.  We're working hard to make it usable/available for
people, as soon as possible.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

gdr@cs.tamu.edu (Gabriel Dos Reis) writes:

> As of XTI or IPR, it is not unusual for people to believe that any
> functionality sufficiently "powerful" should be built in the
> language or compiler.

I'm not saying that XTI (IPR?) ought to be built into the C++
language.  The standard in question is the one for the C++ language,
so if XTI isn't part of the C++ language it's hard to see how it could
be part of the C++ language standard!

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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 Fri, 16 Jul 2004 17:08:37 +0000 (UTC), Gabriel Dos Reis wrote:
> But, the most interesting part, I believe, is what IPR would bring to
> the C++ community.

I hate being dense, but there's nothing I can do about it.  What's IPR?

Scott

---
[ 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 Fri, 16 Jul 2004 01:00:27 +0000 (UTC), dietmar_kuehl@yahoo.com wrote:
> The best guess is to look at what is currently more or less actively
> discussed. This information is publically available at
> <http://www.open-std.org/jtc1/sc22/wg21/>. Essentially you want to look
> at the list of papers, especially those in the Evolution section.

Can you be a little more precise about where to look?  The URL is for a
committee overview page, and it's not obvious how to figure out "what is
currently more or less actively discussed."  Regarding the "Evolution
section", where is that?  The word "evolution" doesn't appear to be on that
page anywhere.

I'm not trying to be a pain.  I've never been able to figure out how the
committee information is organized.  (Proposal papers seem to be organized
by year, for example, which isn't the easiest way to browse around to see
what's available.)

Semi-relatedly, the LWG issues list has been available as a self-contained
downloadable archive for a long time, but I've never been able to find such
a thing for the Core Language.  Is there a reason for this difference?

Thanks,

Scott

---
[ 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                       ]

Usenet@aristeia.com (Scott Meyers) writes:

> On Fri, 16 Jul 2004 01:00:27 +0000 (UTC), dietmar_kuehl@yahoo.com wrote:
>> The best guess is to look at what is currently more or less
>> actively discussed. This information is publically available at
>> <http://www.open-std.org/jtc1/sc22/wg21/>. Essentially you want to
>> look at the list of papers, especially those in the Evolution
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> section.
>
> Can you be a little more precise about where to look?  The URL is for a
> committee overview page, and it's not obvious how to figure out "what is
> currently more or less actively discussed."

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/

We generally discuss what's been in the pre-meeting mailing at the
meetings.  Post-meeting mailings tend to be editorial improvements of
pre-meeting papers, etc., and seem to get less attention.

> Regarding the "Evolution section", where is that?  The word
> "evolution" doesn't appear to be on that page anywhere.

Look for it here, for example:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/#post_sydney

> I'm not trying to be a pain.  I've never been able to figure out how the
> committee information is organized.  (Proposal papers seem to be organized
> by year, for example, which isn't the easiest way to browse around to see
> what's available.)
>
> Semi-relatedly, the LWG issues list has been available as a
> self-contained downloadable archive for a long time, but I've never
> been able to find such a thing for the Core Language.  Is there a
> reason for this difference?

Maybe the CWG chair doesn't build such an archive and submit it to
the webmaster; I dunno.

HTH,
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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                       ]

Usenet@aristeia.com (Scott Meyers) writes:

| On Fri, 16 Jul 2004 17:08:37 +0000 (UTC), Gabriel Dos Reis wrote:
| > But, the most interesting part, I believe, is what IPR would bring to
| > the C++ community.
|
| I hate being dense, but there's nothing I can do about it.  What's IPR?

XTI was an acronym for "eXtended Type Information".  IPR is for
"Internal Program Representation", a set of compiler-neutral
facitilies to represent C++ programs in C++.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

llewelly.at@xmission.dot.com (llewelly) writes:

| dave@boost-consulting.com (David Abrahams) writes:
| [snip]
| > Just to clarify -- I wasn't trying to make any judgements about XTI
| > other than that it's got very little going for it in the "liklihood
| > of standardization" department other than that it's Bjarne's
| > project.  At this point there's little reason to be surprised if it
| > isn't part of the next standard... especially if it uses a tool
| > external to the regular compiler.
| [snip]
|
| I can't help but note the preprocessor began life as a tool external to
|     the regular compiler - and as far as I know, most unix C++
|     implemantations still make the preprocessor availible as a
|     stand-alone executable, and still accept pre-processed input from
|     an external tool (though the default compile mode usually uses an
|     integrated preprocessor).

Indeed.  I don't think the message you're replying to is unique in its
belief. I've come to be surprised to see how the belief that "if it is
powerful, it ought to be a language built-in facility" is
fundamentally rooted in many programming communities.  Just have a
look other widely used programming languages and count what they offer
as built-ins.

C++ used to take a different standing point, in the tradition of
Classic C. As Andy Koenig put it once, "language design is library
design".  Maybe IPR should advertize some iterator facets and gadgets,
if it wanted to be taken seriously, if ever proposed for
standardization ;-)

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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 <MPG.1b61bc4e10aa2b46989777@news.hevanet.com>, Scott Meyers
<Usenet@aristeia.com> writes
>Can you be a little more precise about where to look?  The URL is for a
>committee overview page, and it's not obvious how to figure out "what is
>currently more or less actively discussed."  Regarding the "Evolution
>section", where is that?  The word "evolution" doesn't appear to be on that
>page anywhere.
>
>I'm not trying to be a pain.  I've never been able to figure out how the
>committee information is organized.  (Proposal papers seem to be organized
>by year, for example, which isn't the easiest way to browse around to see
>what's available.)

Unfortunately it is organised by mailings however if you go to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/

You will find each mailing lists the papers supplied for it and the
right hand column gives the relevant work group.


>

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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                       ]

Scott Meyers wrote:
> Can you be a little more precise about where to look?

Well, sure, although I have no real head start on this at all...
Essentially, all papers discussed by the committee can be seen in the
"papers" section (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/>).
The papers are organized by their distribution time, i.e. their "mailing".
This is not particularly useful if you want to find when something was
discussed but it is quite good at locating what is currently or resently
discussed.

Starting with the pre-sydney mailings (and hopefully continued in the
future), each paper is attributed with the group it is discussed in plus
other useful information like the reference number (this is the official
immutable number under which the paper is always referenced; if a new
revision of a paper becomes available, it gets a new number and one of the
new attributes apparently points to earlier versions of a paper). The papers
under discussion for the next standard are mostly in the Evolution group.
Some of the new stuff also goes into papers discussed by the Library group,
namely those which can clearly be implemented as a library without any help
from the compiler.

> The URL is for a
> committee overview page, and it's not obvious how to figure out "what is
> currently more or less actively discussed."

This is effectively reflected by the respective mailings: things discussed
in multiple mailings are typically more actively discussed while things
showing up in just one mailing either didn't need much discussion or there
is no active interest. Sorry, there is no record on what people actually
discuss - especially as much of the discussion of new topics is actually
done during non-official times like the beer at the bar.

> Regarding the "Evolution
> section", where is that?  The word "evolution" doesn't appear to be on
> that page anywhere.

There is no evolution section but the newer mailings include an association
with its respective group: have a look e.g. at the post-sydney mailings and
look at the last column.

> I'm not trying to be a pain.  I've never been able to figure out how the
> committee information is organized.  (Proposal papers seem to be organized
> by year, for example, which isn't the easiest way to browse around to see
> what's available.)

Are you volunteering to add another view on the data...? The mailings are
important in that they form the basis of the meetings discussion (the
pre-mailings) or some form of material which was volunteered to provide
soon after the meetings (the post-mailing). The papers are just sent to
whoever volunteered to gather them and sent them on. I think it is quite
good that they are attributed to the group they are most relevant to...
For the people working in the committee the current organization is quite
sufficient because the persons normally know from somewhere which papers
are relevant to them, e.g. from being pointed at it, from a discussion
over a beer and then browsing the topics, or from a reference in one of the
issue lists.

This approach is not necessarily the most accessible but it seems to work.
The processes with the committee are actually constantly changing to create
less overhead or to accommodate new situations. Suggestions how to improve
things are generally welcome - especially if the reduce the work.

> Semi-relatedly, the LWG issues list has been available as a self-contained
> downloadable archive for a long time, but I've never been able to find
> such
> a thing for the Core Language.  Is there a reason for this difference?

I guess the major reason is that the issue lists are handled by different
persons or that the people in the respective groups asked for different
things.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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                       ]

I just noticed Herb Sutter's June CUJ column that addresses this topic more
or less directly.  For non-subscribers, I assume that it will be available
at Herb's web site a few months from now.

Scott

---
[ 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                       ]

gdr@cs.tamu.edu (Gabriel Dos Reis) writes:

> Indeed.  I don't think the message you're replying to is unique in its
> belief. I've come to be surprised to see how the belief that "if it is
> powerful, it ought to be a language built-in facility" is
> fundamentally rooted in many programming communities.  Just have a
> look other widely used programming languages and count what they offer
> as built-ins.

Please.  You continue to misread what I wrote.  I'm saying "if it is
standardizable, it has to be a language built-in facility".  Maybe
that's not true, but if so I don't see how that could work.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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 Sat, 17 Jul 2004 05:06:33 +0000 (UTC), Gabriel Dos Reis wrote:
> XTI was an acronym for "eXtended Type Information".  IPR is for
> "Internal Program Representation", a set of compiler-neutral
> facitilies to represent C++ programs in C++.

Yow, flashback.  Check out the call for participation in the Advanced
Topics Workshop associated with the 1992 Usenix C++ Technical Conference at
http://compilers.iecc.com/comparch/article/92-06-126.  It includes this:

  The focus of this year's workshop will be support for C++ software
  development tools. Many people are beginning to experiment with the idea
  of having such tools work off a data structure that represents parsed C++,
  leaving the parsing task to a single specialized tool that generates the
  data structure. To date, over a half-dozen different representations for
  parsed C++ have been developed.

  This workshop will provide a forum for representation developers to
  explain their design decisions and for tool developers to describe what
  an ideal representation for C++ should offer.

  Extracting the data to put into a representation is a challenge in its own
  right, and the workshop will also offer participants the opportunity to
  discuss different approaches to parsing.

Having been at the workshop (God I'm old), here's my executive summary of
the conclusions, or at least my conclusions: The preprocessor makes life
unimaginably miserable for tool vendors :-|

I really hope you guys can crack this nut, because one of the lessons I've
taken away from Java is that language design should take into account how
easy or hard it is for people to develop tools to support it, and it's very
hard to develop good tools if lexical analysis, parsing, and semantic
analysis of the language are extremely difficult.

Scott

---
[ 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                       ]

Usenet@aristeia.com (Scott Meyers) writes:

| On Sat, 17 Jul 2004 05:06:33 +0000 (UTC), Gabriel Dos Reis wrote:
| > XTI was an acronym for "eXtended Type Information".  IPR is for
| > "Internal Program Representation", a set of compiler-neutral
| > facitilies to represent C++ programs in C++.
|
| Yow, flashback.  Check out the call for participation in the Advanced
| Topics Workshop associated with the 1992 Usenix C++ Technical Conference at
| http://compilers.iecc.com/comparch/article/92-06-126.  It includes this:

Woaw!  I'm so young ;-)
BTW, thanks for the reference.

|   The focus of this year's workshop will be support for C++ software
|   development tools. Many people are beginning to experiment with the idea
|   of having such tools work off a data structure that represents parsed C++,
|   leaving the parsing task to a single specialized tool that generates the
|   data structure. To date, over a half-dozen different representations for
|   parsed C++ have been developed.
|
|   This workshop will provide a forum for representation developers to
|   explain their design decisions and for tool developers to describe what
|   an ideal representation for C++ should offer.
|
|   Extracting the data to put into a representation is a challenge in its own
|   right, and the workshop will also offer participants the opportunity to
|   discuss different approaches to parsing.
|
| Having been at the workshop (God I'm old), here's my executive summary of
| the conclusions, or at least my conclusions: The preprocessor makes life
| unimaginably miserable for tool vendors :-|

And I wholeheartly agree with you -- Cpp must be abolished :-)

The #nospam proposal is a way to limit the damage Cpp can cause.

I, personally, find it quite curious that, to date, the only
practical avenue (to abolishing Cpp) that seems to face less
resistance is to make Cpp more powerful -- in the quest of making it
less harmful.

| I really hope you guys can crack this nut, because one of the lessons I've

We hope too :-)

| taken away from Java is that language design should take into account how
| easy or hard it is for people to develop tools to support it, and it's very
| hard to develop good tools if lexical analysis, parsing, and semantic
| analysis of the language are extremely difficult.

Agreed.  In fact a "simple minded implementation" criteria has always
been a rule for C++ design.  How we end up here is an interesting
question :-)

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

"Gabriel Dos Reis" <gdr@cs.tamu.edu> wrote in message
> Agreed.  In fact a "simple minded implementation" criteria has always
> been a rule for C++ design.  How we end up here is an interesting
> question :-)

My impression was that the philosophy, at least for a while, was "programmer
convenience takes over compiler writer effort, because the latter is done by
a few highly specialized professionals who can endure anything". That turned
out to be an imperfect strategy.

Indeed, looking back at some features, it looks the only concern about
implementation difficulty was, "Um, could this be used to solve the halting
problem? No? Good, then it's implementable". :o)


Andrei


---
[ 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 <m3acxyca98.fsf@merlin.cs.tamu.edu>, Gabriel Dos Reis
<gdr@cs.tamu.edu> writes
>And I wholeheartly agree with you -- Cpp must be abolished :-)

And the first step is to provide an alternative mechanism for
programmers who only want to make declaration and type definitions
available to the compiler. IOWs as long as the language relies on
#include there is little we can do to seriously limit the problems of
the cpp.

I remember the guideline 'do not pay for what you do not use',
unfortunately it is effectively impossible to write a program that does
not use #include with the consequence that we all pay for the cpp.

So what problems would we have by providing an 'import' directive (a C++
directive not a pre-processor one) and make it automatically ignore and
source code line in the imported file that starts with '#'?

Then people who want to can do whatever they like with the preprocessor
because I would no longer have to use it in all my programs.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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 Glassborow wrote:
> In article <m3acxyca98.fsf@merlin.cs.tamu.edu>, Gabriel Dos Reis
> <gdr@cs.tamu.edu> writes
>
>> And I wholeheartly agree with you -- Cpp must be abolished :-)

    I'm beginning to think that enhancing the preprocessor
would be better than the horrors emerging from the "template expander
as recursive rewrite rule engine" crowd.

> So what problems would we have by providing an 'import' directive (a C++
> directive not a pre-processor one) and make it automatically ignore and
> source code line in the imported file that starts with '#'?

    Religious issue.  Look back at the history of proposals in this
direction.  There's a "save the include guards" faction, a
"you'll never be able to distinguish between two names that
refer to the same file" faction, and a "C++ shouldn't know
what file names look like" faction.

    I've proposed

 using "filename";

    Go back and read the flames.

    John Nagle
    Animats

---
[ 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                       ]

David Abrahams wrote:

> gdr@cs.tamu.edu (Gabriel Dos Reis) writes:
>
>> Indeed.  I don't think the message you're replying to is unique in its
>> belief. I've come to be surprised to see how the belief that "if it is
>> powerful, it ought to be a language built-in facility" is
>> fundamentally rooted in many programming communities.  Just have a
>> look other widely used programming languages and count what they offer
>> as built-ins.
>
> Please.  You continue to misread what I wrote.  I'm saying "if it is
> standardizable, it has to be a language built-in facility".  Maybe
> that's not true, but if so I don't see how that could work.

What's exactly the difference between "language built-in facility" and
library which uses external tools. After all, the standard can specify only
the reflection interface which you would use, and where exactly the data is
stored or how its produced is not so important. Requirement to run a
separate tool to convert debug info reflection data is probably not so
convenient, but it's a minor thing, IMO.

- Volodya

---
[ 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                       ]

Gabriel Dos Reis wrote:

> | > I would be surprised, and disappointed, if a reflection mechanism
> | > doesn't make its way into the next C++ standard. This is especially so
> | > since, as I understand it, Mr. Stroustrup is working on this.
> |
> | Don't be; AFAIK Bjarne hasn't done anything with that project for
> | quite a while
>
> That is untrue -- that is a subject of active, daily, discussions between
> him, me and his students. :-)

...

> | The world at large has never even seen a prototype.  Furthermore,
> | Bjarne's work is not an in-language solution -- it relies on external
> | tools to generate XML from GCC's debug info.
>
> We're working -- on daily basis -- on that project and things are
> evolving -- maybe not as fast as you'd like, but progress has been
> made.  You're quite right that it is not a language  built-in
> solution.  As of today, it is a library solution and it can represent
> all existing C++ notions (classes, functions, templates, ...).

It's great to know the project is being worked at. But... is there any
chance the code, or part of it, will be made public in near future? I think
a lot of people will be interested, and can become early users/helpers.

- Volodya




---
[ 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                       ]

ghost@cs.msu.su (Vladimir Prus) writes:

> David Abrahams wrote:
>
>> gdr@cs.tamu.edu (Gabriel Dos Reis) writes:
>>
>>> Indeed.  I don't think the message you're replying to is unique in its
>>> belief. I've come to be surprised to see how the belief that "if it is
>>> powerful, it ought to be a language built-in facility" is
>>> fundamentally rooted in many programming communities.  Just have a
>>> look other widely used programming languages and count what they offer
>>> as built-ins.
>>
>> Please.  You continue to misread what I wrote.  I'm saying "if it is
>> standardizable, it has to be a language built-in facility".  Maybe
>> that's not true, but if so I don't see how that could work.
>
> What's exactly the difference between "language built-in facility" and
> library which uses external tools. After all, the standard can specify only
> the reflection interface which you would use, and where exactly the data is
> stored or how its produced is not so important. Requirement to run a
> separate tool to convert debug info reflection data is probably not so
> convenient, but it's a minor thing, IMO.

Are you saying that the library that manipulates the reflection data
could become standard?  Yes, that's a real possibility.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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                       ]

> I would be surprised, and disappointed, if a reflection mechanism doesn't
> make its way into the next C++ standard. This is especially so since, as I
> understand it, Mr. Stroustrup is working on this. Also a reflection
> mechanism is needed to allow effective C++ RAD programming environments
> without the extensions found in C++ Builder and Managed C++. I would hope
> the C++ committee would see the value of adding reflection to C++ to allow
> these possibilities as both C++ Builder and Managed C++ have proved strong
> environments for component based C++ programming and the ability to set
> properties and event handlers at design time.
>

As a matter of fact, although I'd probably like reflection, I don't
think it's that important. As a proof, try:
http://www.torjo.com/win32gui/ - it's a GUI library and it offers very
nice event handling, with no need for reflection.
Not to say that you could build a very cute wrapper over it to allow
even cuter GUI.

(unfortunately there are no docs at this time - but please contact me
privately for more details)

Best,
John

John Torjo
Freelancer
-- john@torjo.com

Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/

Professional Logging Solution for FREE
-- http://www.torjo.com/code/logging.zip (logging           - C++)
-- http://www.torjo.com/logview/         (viewing/filtering - Win32)
-- http://www.torjo.com/logbreak/        (debugging         - Win32)
                                         (source code available)

---
[ 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                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:4WHKc.12520$yA6.3671@newssvr25.news.prodigy.com...
> Francis Glassborow wrote:
> > In article <m3acxyca98.fsf@merlin.cs.tamu.edu>, Gabriel Dos Reis
> > <gdr@cs.tamu.edu> writes
> >
> >> And I wholeheartly agree with you -- Cpp must be abolished :-)
>
>     I'm beginning to think that enhancing the preprocessor
> would be better than the horrors emerging from the "template expander
> as recursive rewrite rule engine" crowd.

Heh. :o) I am not sure what you refer to.

To add my $.02 in, I think the one effective way to phase the preprocessor
out is to provide cleaner facilities that provide similar functionality.
Then, for a while, the preprocessor would coexist in a deprecated state with
the new facilities; then, it would go from deprecation to decrepitude, where
the new features will have had proven their superiority and using the
preprocessor will be considered gauche. Compilers will offer switches to NOT
run the preprocessor, and later they would offer switches to DO run the
preprocessor because the default will become to not run it. And so on.

This all will take about 50 years if we're lucky. :o) At any rate, I believe
something more, not less powerful than the preprocessor is the only device
that could effectively dislodge it. The preprocessor is powerful in just a
couple of odd ways (like __FILE__/__LINE__ and the token pasting stuff) and
replacing it really means biting the bullet and defining a better facility
that allows token pasting etc.

By the way, here's a nice preprocessor for Java. http://jse.sourceforge.net/
Meta by the way, I get an acute impression that a lot of good folks fiddle
with Java because (1) it's typesafe (2) is easier to work with, in
particular to parse. There are a plethora of excellent parsers for Java that
are publically available, are easy to use, and make it possible to do a lot
of language-related work. C++ doesn't, which is odd because it's an older
language.

Speaking of inclusion, we need to provide both "include once" (the default
mode, when a file's second inclusion is ignored) and "include many" because
there are a few projects that rely on the ability of including the same file
several times, like:

#define SOMETHING
#include "wyda.h"
#undef SOMETHING
#include "wyda.h"

>     Religious issue.  Look back at the history of proposals in this
> direction.  There's a "save the include guards" faction, a
> "you'll never be able to distinguish between two names that
> refer to the same file" faction, and a "C++ shouldn't know
> what file names look like" faction.

Well you gotta have an implementation-defined string somewhere. There is a
precedent (asm). I don't know how the latter camp's outrage is assuaged by
the preprocessor being aware of the file names format.

>     I've proposed
>
> using "filename";

Looks cool. By default, the second using for the same filename would be
ignored. But if you use a special form, the file will be included
regardless.

Here are some syntactic forms. LISP aficionados will love that:

using! "filename";

because traditionally in LISP mutating functions terminate in a bang. One
that adds a special word that has a meaning only in this context (it's
called keyword as opposed to reserved words):

using "filename" again;

But C++ doesn't have keywords, only reserved words, so this is not in the
spirit of C++. It should be added, though, that C++/CLI does have keywords.

Some jokey syntaxes based on the existing reserved words:

using "filename" double; // two or more times, heh
using "filename" explicit; // I really want this included
using "filename" union; // union this file with the existing content
using "filename" continue; // continue inclusion no matter what :o)
using "filename"++; // increment usage for a file

Finally, a regular notation:

using "filename"+; // one or more times

You gotta love all that. :o)


Andrei


---
[ 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                       ]

John Torjo wrote:
>> I would be surprised, and disappointed, if a reflection mechanism
>> doesn't make its way into the next C++ standard. This is especially
>> so since, as I understand it, Mr. Stroustrup is working on this.
>> Also a reflection mechanism is needed to allow effective C++ RAD
>> programming environments without the extensions found in C++ Builder
>> and Managed C++. I would hope the C++ committee would see the value
>> of adding reflection to C++ to allow these possibilities as both C++
>> Builder and Managed C++ have proved strong environments for
>> component based C++ programming and the ability to set properties
>> and event handlers at design time.
>>
>
> As a matter of fact, although I'd probably like reflection, I don't
> think it's that important. As a proof, try:
> http://www.torjo.com/win32gui/ - it's a GUI library and it offers very
> nice event handling, with no need for reflection.

Event handling doesn't need reflection, as Doug Gregor's boost::signals
proves. However design time setting of properties and events, ala Managed
C++/.NET and C++ Builder, does need reflection in order to set values and
event handling addresses automatically at run-time from names.

---
[ 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                       ]

C++0x will offer new features compared to C++03+TC1+TR1.  We don't know for
sure what those features will be, but presumably some are much more likely
than others.  As a non-member of the standardization committee who follows
the process only informally but who is responsible for trying to help
practicing programmers keep an eye on what is likely to happen in the
future, I'd be interested in others' guesses as to what language and
library features are likely to make it into C++0x.

FWIW, this is my list, bearing in mind that I'm treating TR1 as already
included, even though I know that it's not:
  - forwarding constructors
  - something like typeof (maybe auto, maybe both)
  - move constructors
  - no need to define const static integral members whose address is not
    taken
Should any of these not be on the list?  What other things should be?

I'm primarily interested in "big" features as opposed to "little"
refinements to existing features.  Forwading constructors qualify.
Typeof/auto qualifies.  Move constructors qualify.  The const static
definition thing doesn't qualify, but it's on my list, because, hey, it's
my list, so I can break the rules if I want to :-)

All help appreciated.  Again, I know that we can't predict the future, but
some things are a lot more likely than others.  I'd just like to know what
they are so that I can tell people who ask me.

Thanks,

Scott

---
[ 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                       ]

Scott Meyers wrote:
>
> FWIW, this is my list, bearing in mind that I'm treating TR1 as already
> included, even though I know that it's not:
>   - forwarding constructors
>   - something like typeof (maybe auto, maybe both)
>   - move constructors
>   - no need to define const static integral members whose address is not
>     taken
> Should any of these not be on the list?  What other things should be?

The last one - about const static integral members - is already in the
standard. It was included in TC1, although it is formulated differently.

TC1 changes the definition of what constitutes a "use" of an object.
According to TC1 (3.2/2), appearance of an object in an integral
constant expression (ICE) does not constitute a "use" of that object.
Unused object require no definition. I.e. in TC1'ed version of the
language there's no need to provide definitions for const static
integral/enum members that appear only in ICEs (which is pretty much
what is usually meant by "address is not taken", if I understood you
correctly).

--
Best regards,
Andrey Tarasevich

---
[ 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                       ]

Scott Meyers wrote:
> C++0x will offer new features compared to C++03+TC1+TR1.  We don't
> know for sure what those features will be, but presumably some are
> much more likely than others.  As a non-member of the standardization
> committee who follows the process only informally but who is
> responsible for trying to help practicing programmers keep an eye on
> what is likely to happen in the future, I'd be interested in others'
> guesses as to what language and library features are likely to make
> it into C++0x.
>
> FWIW, this is my list, bearing in mind that I'm treating TR1 as
> already included, even though I know that it's not:
>   - forwarding constructors
>   - something like typeof (maybe auto, maybe both)
>   - move constructors
>   - no need to define const static integral members whose address is
>     not taken
> Should any of these not be on the list?  What other things should be?

I would be surprised, and disappointed, if a reflection mechanism doesn't
make its way into the next C++ standard. This is especially so since, as I
understand it, Mr. Stroustrup is working on this. Also a reflection
mechanism is needed to allow effective C++ RAD programming environments
without the extensions found in C++ Builder and Managed C++. I would hope
the C++ committee would see the value of adding reflection to C++ to allow
these possibilities as both C++ Builder and Managed C++ have proved strong
environments for component based C++ programming and the ability to set
properties and event handlers at design time.


---
[ 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                       ]

Scott Meyers wrote:

> [...]
> FWIW, this is my list, bearing in mind that I'm treating TR1 as already
> included, even though I know that it's not:
>   - forwarding constructors
>   - something like typeof (maybe auto, maybe both)
>   - move constructors
>   - no need to define const static integral members whose address is not
>     taken
> Should any of these not be on the list?  What other things should be?
> [...]

How about template aliases?  (I hope!)

Dave

---
[ 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                       ]

> Should any of these not be on the list?  What other things should be?

I hope

1) Proper support for static asserts

2) Some formal langauge support for all the template tricks used to
determine whether certain features are available or not. This would be
useful to compiler vendors as it means they can issue some comprehensible
error messages.

Stephen Howe


---
[ 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 wrote:

> I would be surprised, and disappointed, if a reflection mechanism doesn't
> make its way into the next C++ standard. This is especially so since, as I
> understand it, Mr. Stroustrup is working on this.

Don't be; AFAIK Bjarne hasn't done anything with that project for quite
a while and he's never brought a paper before the committee.  The world
at large has never even seen a prototype.  Furthermore, Bjarne's work is
not an in-language solution -- it relies on external tools to generate
XML from GCC's debug info.

> Also a reflection
> mechanism is needed to allow effective C++ RAD programming environments
> without the extensions found in C++ Builder and Managed C++. I would hope
> the C++ committee would see the value of adding reflection to C++ to allow
> these possibilities as both C++ Builder and Managed C++ have proved strong
> environments for component based C++ programming and the ability to set
> properties and event handlers at design time.

Many of us see the value, but I wouldn't assume what you're looking for
is going to show up in the language standard unless someone like you,
who really cares about it, leads the charge to put it there.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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                       ]

"Scott Meyers" <Usenet@aristeia.com> wrote in message
news:MPG.1b5e67da917bb68d989775@news.hevanet.com...
> C++0x will offer new features compared to C++03+TC1+TR1.  We don't know
for
> sure what those features will be, but presumably some are much more likely
> than others.  As a non-member of the standardization committee who follows
> the process only informally but who is responsible for trying to help
> practicing programmers keep an eye on what is likely to happen in the
> future, I'd be interested in others' guesses as to what language and
> library features are likely to make it into C++0x.
>
> FWIW, this is my list, bearing in mind that I'm treating TR1 as already
> included, even though I know that it's not:
>   - forwarding constructors
>   - something like typeof (maybe auto, maybe both)
>   - move constructors
>   - no need to define const static integral members whose address is not
>     taken
> Should any of these not be on the list?  What other things should be?
>

  Type-safe, portable enums.

Joe Gottman

---
[ 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                       ]

Hi,
"Edward Diener" wrote:
> I would be surprised, and disappointed, if a reflection mechanism
doesn't
> make its way into the next C++ standard.

Standardization works quite simple: somebody cares about something, he
does the work involved in getting it standardized. That is, if you want
reflection, work on this stuff! There is no need to be a member of the
committee, although it admittedly would help to get a better feeling on
how a proposal should look like and what is required. Also, somebody at
in the committee will have to push the issue but I think there are
several people who would be willing to bring something like this
forward
and discuss it in the process of creating a papber. However, apparently
nobody is currently sufficiently interested to write a proposal on this
issue.

> This is especially so since, as I understand it, Mr. Stroustrup is
> working on this.

It is a while since I heard anything of XTI (eXtended Type
Information).
Also, I'm not sure whether it was intended to do what I would like it
to
do. In any case, if you want reflection (or whatever it will be called)
in the next standard, you should not rely on others doing the work.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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 Wed, 14 Jul 2004 17:18:53 +0000 (UTC), Usenet@aristeia.com (Scott
Meyers) wrote:

>C++0x will offer new features compared to C++03+TC1+TR1.  We don't know for
>sure what those features will be, but presumably some are much more likely
>than others.  As a non-member of the standardization committee who follows
>the process only informally but who is responsible for trying to help
>practicing programmers keep an eye on what is likely to happen in the
>future, I'd be interested in others' guesses as to what language and
>library features are likely to make it into C++0x.
>
>FWIW, this is my list, bearing in mind that I'm treating TR1 as already
>included, even though I know that it's not:
>  - forwarding constructors
>  - something like typeof (maybe auto, maybe both)
>  - move constructors
>  - no need to define const static integral members whose address is not
>    taken
>Should any of these not be on the list?  What other things should be?
>
>I'm primarily interested in "big" features as opposed to "little"
>refinements to existing features.  Forwading constructors qualify.
>Typeof/auto qualifies.  Move constructors qualify.  The const static
>definition thing doesn't qualify, but it's on my list, because, hey, it's
>my list, so I can break the rules if I want to :-)

This gives a list of all the proposals:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1598.html

Personally, in addition to your list I'd like to see variadic
templates, better compile-time reflection, overloading operator. and
improved string classes (const_string, string and rope - include a way
of detecting a string literal at compile time to avoid copying it). A
separate standard on C++ threading, including a memory model and a
library including atomic primitives (hopefully) would be nice, but
this possibly comes under POSIX's remit, not C++'s.

Tom

---
[ 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                       ]

Hi,
Scott Meyers wrote:
> As a non-member of the standardization committee who follows
> the process only informally but who is responsible for trying to help
> practicing programmers keep an eye on what is likely to happen in the
> future, I'd be interested in others' guesses as to what language and
> library features are likely to make it into C++0x.

The best guess is to look at what is currently more or less actively
discussed. This information is publically available at
<http://www.open-std.org/jtc1/sc22/wg21/>. Essentially you want to look
at the list of papers, especially those in the Evolution section. When
inspected more closely this should even give you a good impression on
how things are intended to be done. ... and you can even participate by
pointing out problems, possible resolutions to problems, create own
proposals, etc.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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                       ]

Hi,
David Abrahams wrote:
> Furthermore, Bjarne's work is
> not an in-language solution -- it relies on external tools to
generate
> XML from GCC's debug info.

Although I consider it questionable to use GCC's debug info for this,
the
general approach is valid: for reflection a la Java you would need an
interface to access the information which is essentially some form of
library plus the implementation thereof. The implementation can be
generated from suitable compiler output and bound to the executable
with
the effect that programs not using the reflection mechanism are not
affected at all. This form of reflection is, of course, useless for
template programming. However, I would expect different approaches for
RAD and template programming anyway...

Since proposals are supposed to be backed up with an implementation
before
they are accepted into the standard (but an implementation is not a
requirement for a proposal itself), it may be reasonable to create an
implementation based on gccxml (see <http://www.gccxml.org>): this
seems
to provide the necessary information for some form of reflection.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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                       ]

dave@boost-consulting.com (David Abrahams) writes:

| Edward Diener wrote:
|
| > I would be surprised, and disappointed, if a reflection mechanism doesn't
| > make its way into the next C++ standard. This is especially so since, as I
| > understand it, Mr. Stroustrup is working on this.
|
| Don't be; AFAIK Bjarne hasn't done anything with that project for
| quite a while

That is untrue -- that is a subject of active, daily, discussions between
him, me and his students. :-)

|                and he's never brought a paper before the committee.

Agreed.

| The world at large has never even seen a prototype.  Furthermore,
| Bjarne's work is not an in-language solution -- it relies on external
| tools to generate XML from GCC's debug info.

We're working -- on daily basis -- on that project and things are
evolving -- maybe not as fast as you'd like, but progress has been
made.  You're quite right that it is not a language  built-in
solution.  As of today, it is a library solution and it can represent
all existing C++ notions (classes, functions, templates, ...).

However, we're not -- momentarily I hope -- using tools that rely on
GCC.  GCC's debug ouput is currently far too incomplete and unsuitable
for getting some specific information (XTI as presented at the ACCU
Spring Conference 2002 was mainly concerned with types, IPR represents
whole translation/instantiation units).  But it gets you somewhere.
We're, at the moment, using competing compiler to generate the
information we need.

But IPR itself is a compiler-neutral component (and it ought to be).

It is my hope that at some point GCC/g++ would accept competition.
Students are currently, succesfully, using competing compiler.  I see
no technical, fundamental reasons why one could not do the same with
GCC, and it is the project aim to be compiler neutral.

Recent discussions on GCC mailing list makes me confident that
the situation is changing on that front, and the fierce resistance I
met a couple of months ago would no longer be an issue.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

gdr@cs.tamu.edu (Gabriel Dos Reis) writes:

> dave@boost-consulting.com (David Abrahams) writes:
>
> | Edward Diener wrote:
> |
> | > I would be surprised, and disappointed, if a reflection mechanism doesn't
> | > make its way into the next C++ standard. This is especially so since, as I
> | > understand it, Mr. Stroustrup is working on this.
> |
> | Don't be; AFAIK Bjarne hasn't done anything with that project for
> | quite a while
>
> That is untrue -- that is a subject of active, daily, discussions between
> him, me and his students. :-)
>
> |                and he's never brought a paper before the committee.
>
> Agreed.
>
> | The world at large has never even seen a prototype.  Furthermore,
> | Bjarne's work is not an in-language solution -- it relies on external
> | tools to generate XML from GCC's debug info.
>
> We're working -- on daily basis -- on that project and things are
> evolving -- maybe not as fast as you'd like, but progress has been
> made.  You're quite right that it is not a language  built-in
> solution.  As of today, it is a library solution and it can represent
> all existing C++ notions (classes, functions, templates, ...).

Just to clarify -- I wasn't trying to make any judgements about XTI
other than that it's got very little going for it in the "liklihood
of standardization" department other than that it's Bjarne's
project.  At this point there's little reason to be surprised if it
isn't part of the next standard... especially if it uses a tool
external to the regular compiler.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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                       ]

dietmar_kuehl@yahoo.com ("dietmar_kuehl@yahoo.com") writes:

> Hi,
> Scott Meyers wrote:
>> As a non-member of the standardization committee who follows
>> the process only informally but who is responsible for trying to help
>> practicing programmers keep an eye on what is likely to happen in the
>> future, I'd be interested in others' guesses as to what language and
>> library features are likely to make it into C++0x.
>
> The best guess is to look at what is currently more or less actively
> discussed. This information is publically available at
> <http://www.open-std.org/jtc1/sc22/wg21/>. Essentially you want to look
> at the list of papers, especially those in the Evolution section.

I agree with Dietmar.  With all due respect to those non-committee
members who have posted, most of their posts seem a lot more like
personal wishlists than accurate answers to the question you asked.
If it's not in recent or active papers, it's not particularly likely
to go in the next standard.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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                       ]

dietmar_kuehl@yahoo.com ("dietmar_kuehl@yahoo.com") writes:

| Hi,
| David Abrahams wrote:
| > Furthermore, Bjarne's work is
| > not an in-language solution -- it relies on external tools to
| generate
| > XML from GCC's debug info.
|
| Although I consider it questionable to use GCC's debug info for this,

Well, Bjarne and I, independently, have come to conclusions that GCC's
debu info is insufficient -- although it could be improved (I know how
I can do that).  Of course, Bjarne had been there before, and I
guess I should be listening ;-)

One fundamental problem with GCC's debug info is that it is
incomplete on some specific point, but that can be improved.
Another is lack of documentation and it is kind of frustrating to base
work on something that could suddenly change and varies from release
to release.

But, as I said, it is not an unsolvable problem.

| the
| general approach is valid: for reflection a la Java you would need an
| interface to access the information which is essentially some form of
| library plus the implementation thereof. The implementation can be
| generated from suitable compiler output and bound to the executable
| with

The aim of XTI was not just reflection -- reflection just happened to be
*an* area of application.  Once you have a data structure that can
represent a translation unit, you can do much more than just reflection.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]