Topic: forward declaration language extension
Author: Jens Theisen <jth02@arcor.de>
Date: Mon, 23 Oct 2006 16:49:49 CST Raw View
Hello,
I have this simple idea for a language extension and am wondering what
would speak against it.
Allow that any type name T can be forward declared with
typename T;
For the parser, it should be enough to know that it's a type. Later
this can be defined as an
- enum
- class/struct/union
- typedef (especially template specialisations)
I admit that I know next to nothing about what the repercussions might
be, but it would obviously be quite useful and also solve the problem
of not being able to forward declare enums under the hood of a more
general feature.
--
Cheers, Jens
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: Mon, 23 Oct 2006 18:05:33 CST Raw View
In article <87lkn6204d.fsf@arcor.de>, Jens Theisen <jth02@arcor.de>
writes
>Hello,
>
>I have this simple idea for a language extension and am wondering what
>would speak against it.
>
>Allow that any type name T can be forward declared with
>
>typename T;
>
>For the parser, it should be enough to know that it's a type. Later
>this can be defined as an
>
>- enum
>- class/struct/union
>- typedef (especially template specialisations)
>
>I admit that I know next to nothing about what the repercussions might
>be, but it would obviously be quite useful and also solve the problem
>of not being able to forward declare enums under the hood of a more
>general feature.
Quite apart from the fact that it is too late for new proposals (we are
triaging the ones we already have) It suffers from exactly the same
problem that forward declaring an enum has, we would not know the size
of a pointer to the type and if pointers do not work there seems little
point in having it.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
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.comeaucomputing.com/csc/faq.html ]
Author: "Pierre Barbier de Reuille" <pierre.barbierdereuille@gmail.com>
Date: Tue, 24 Oct 2006 01:16:22 CST Raw View
Francis Glassborow a crit :
> In article <87lkn6204d.fsf@arcor.de>, Jens Theisen <jth02@arcor.de>
> writes
> >Hello,
> >
> >I have this simple idea for a language extension and am wondering what
> >would speak against it.
> >
> >Allow that any type name T can be forward declared with
> >
> >typename T;
> >
> >For the parser, it should be enough to know that it's a type. Later
> >this can be defined as an
> >
> >- enum
> >- class/struct/union
> >- typedef (especially template specialisations)
> >
> >I admit that I know next to nothing about what the repercussions might
> >be, but it would obviously be quite useful and also solve the problem
> >of not being able to forward declare enums under the hood of a more
> >general feature.
> Quite apart from the fact that it is too late for new proposals (we are
> triaging the ones we already have) It suffers from exactly the same
> problem that forward declaring an enum has, we would not know the size
> of a pointer to the type and if pointers do not work there seems little
> point in having it.
Just for the sake of understanding, how can you not know the size of a
pointer ? Is the size of a pointer to structure or a pointer to enum
different ? If yes, why is that ?
Thanks,
Pierre
>
>
> --
> Francis Glassborow ACCU
> Author of 'You Can Do It!' and "You Can Program in C++"
> 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.comeaucomputing.com/csc/faq.html ]
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: jdennett@acm.org (James Dennett)
Date: Tue, 24 Oct 2006 06:34:12 GMT Raw View
Pierre Barbier de Reuille wrote:
> Francis Glassborow a =E9crit :
>=20
>> In article <87lkn6204d.fsf@arcor.de>, Jens Theisen <jth02@arcor.de>
>> writes
>>> Hello,
>>>
>>> I have this simple idea for a language extension and am wondering wha=
t
>>> would speak against it.
>>>
>>> Allow that any type name T can be forward declared with
>>>
>>> typename T;
>>>
>>> For the parser, it should be enough to know that it's a type. Later
>>> this can be defined as an
>>>
>>> - enum
>>> - class/struct/union
>>> - typedef (especially template specialisations)
>>>
>>> I admit that I know next to nothing about what the repercussions migh=
t
>>> be, but it would obviously be quite useful and also solve the problem
>>> of not being able to forward declare enums under the hood of a more
>>> general feature.
>> Quite apart from the fact that it is too late for new proposals (we ar=
e
>> triaging the ones we already have) It suffers from exactly the same
>> problem that forward declaring an enum has, we would not know the size
>> of a pointer to the type and if pointers do not work there seems littl=
e
>> point in having it.
>=20
> Just for the sake of understanding, how can you not know the size of a
> pointer ?
Without knowing the type pointed to, the pointer type is not
required to be known.
> Is the size of a pointer to structure or a pointer to enum
> different ?=20
Sometimes, yes.
> If yes, why is that ?
To allow for efficient implementations. On some platforms there
will be a trade-off between (for example) using single bytes for
enum values and being able to use fast/small pointers for
addressing them. Pointers to objects of class type are all
required to be the same type, but pointers to char (and hence
void* also) can certainly be larger (and that's not the only
flexibility permitted).
-- James
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: "kanze" <kanze@gabi-soft.fr>
Date: Tue, 24 Oct 2006 11:39:49 CST Raw View
Francis Glassborow wrote:
> In article <87lkn6204d.fsf@arcor.de>, Jens Theisen <jth02@arcor.de>
> writes
> >I have this simple idea for a language extension and am wondering what
> >would speak against it.
> >Allow that any type name T can be forward declared with
> >typename T;
> >For the parser, it should be enough to know that it's a type. Later
> >this can be defined as an
> >- enum
> >- class/struct/union
> >- typedef (especially template specialisations)
> >I admit that I know next to nothing about what the repercussions might
> >be, but it would obviously be quite useful and also solve the problem
> >of not being able to forward declare enums under the hood of a more
> >general feature.
> Quite apart from the fact that it is too late for new proposals (we are
> triaging the ones we already have) It suffers from exactly the same
> problem that forward declaring an enum has, we would not know the size
> of a pointer to the type and if pointers do not work there seems little
> point in having it.
Independantly of the pointer problem: every implementation I
know of uses name mangling to implement type safe linking, and
must be able to mangle the name seeing just the function
declaration. So given something like:
typename T ;
void f( T* ) ;
how do you mangle T, not knowing whether it is a simple class,
or maybe a typedef for std::basic_string< double >, or
std::vector< MyClass >.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
---
[ 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.comeaucomputing.com/csc/faq.html ]
Author: Robert Mabee <rmabee@comcast.net>
Date: Tue, 24 Oct 2006 13:09:17 CST Raw View
kanze wrote:
> Francis Glassborow wrote:
>>In article <87lkn6204d.fsf@arcor.de>, Jens Theisen <jth02@arcor.de>
>>writes
>>>Allow that any type name T can be forward declared with
>>>typename T;
>> It suffers from exactly the same
>>problem that forward declaring an enum has, we would not know the size
>>of a pointer to the type and if pointers do not work there seems little
>>point in having it.
> Independantly of the pointer problem: every implementation I
> know of uses name mangling to implement type safe linking, and
> must be able to mangle the name seeing just the function
> declaration.
OP seems to imply a full definition will occur within the compilation
unit, so these objections do not make compilation impossible, "merely"
requiring a compiler organization that delays the actions mentioned
until the information is available. In other words, this requires a
pass through (some form of) the input that may not now be required by
other language features.
I'm too far out of current compiler technology to know if a one-pass
C++ compiler is even possible, but suspect that it isn't practical
because of all the optimizations that use forward knowledge. Would
and should the language be constrained to permit compilation on a
tiny computer if there are no vendors providing such a compiler?
---
[ 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.comeaucomputing.com/csc/faq.html ]