Re: C++'s 'export' Keyword?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Simon G Best <simon.g.best@btinternet.com> writes:

| Gabriel Dos Reis wrote:
| > Oh yeah, it is a big project.  Something that may probably span two
| > major GCC release cycles as it would need us
| >    (1) to clear up communications between the parser and the rest of
| >        semantics analysis -- e.g. have an infrastructure that makes us
| >        repressent C++ programs in their most abstract/generic forms
| >    (2) to modularize the compiler -- this part may prove politically
| >        involved;    (3) to have support in binutils and some build
| > tools.
|  >
| [...]
| 
| Doing all the work necessary (and doing it well) for 'export' to be
| properly implemented really does seem like an awful lot of work for
| just 'export'.  But if it was not just for C++'s 'export', but
| something that was more generally useful for various languages...

In fact poinst (1), (2) and (3) have merits in their owns and useful
elsewhere; they just appear to be necessary in the scheme I have in
mind.  But, I do not doubt that a bright people may turn non-local
gotos into use in GCC/g++ or some other combination of incantiations
in an export implementations. 
 
Here at the Pararol Lab (TAMU), we've been working on an
infrastructure  that represents C++ programs (and a bit beyond) in
C++. Most information we need for that are already available in the
compiler. Previous designs and implementations of XTI were done with
GCC-3.0.  However, it was found most productive (think of PhD
student's time) to use a well structured, modular and documented
front-end.  That directly led the choice to abandon GCC in favor of a
competing well-known compiler. 
(I suppose that I'll be the natural victim for having support for that
in GCC, assuming I still have interest in GCC after the project is
completed). 

That infrastructure lets do you do just about any high-level manipulations
on C++ programs, in C++.  I believe Matt had written some XML-based
tool based on a previous design of that tool in past.  

So, as Greg Comeau put it: 

  I believe that this is a key issue that document N1426 doesn't
  expose, and hence becomes misleading. In other words, even if export
  is removed, underlying problems in C++ remain. That means problems,
  which are not just with export, still exist, some hurtfully dormant,
  some blatantly not.

Even if the the GCC SC choses to reject any implementation of export
in GCC, we would still need points (1), (2) and (3) for various
reasons. 

| Now, where would be the right place for me to post my vision of how
| compilers, assemblers and linkers for the future might be?

If that vision is unprintable on this mailing list, please drop me a
line. 

Thanks,

-- Gaby