N2673 question
restor
Can anyone confirm if my observation is correct?
According to N2673, I will not be able to write:
class Parser
{
auto member = func();
};
but I will be able to write (according to the current Standard Draft):
class Parser
{
decltype( func() ) member = func();
};
Which eventually will encourage me to write and use a macro:
class Parser
{
DECLARE_AUTO_MEMBER( member, func() );
};
I have one particular usage in mind, which is the Boost.Spirit, where
the grammar rules are implemented with class non-static members.
Regards,
&rzej
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jeff Koftinoff
> Hi,
> Can anyone confirm if my observation is correct?
> According to N2673, I will not be able to write:
>
> class Parser
> {
> auto member = func();
> };
>
> but I will be able to write (according to the current Standard Draft):
>
> class Parser
> {
> decltype( func() ) member = func();
> };
>
> Which eventually will encourage me to write and use a macro:
>
> class Parser
> {
> DECLARE_AUTO_MEMBER( member, func() );
> };
>
> I have one particular usage in mind, which is the Boost.Spirit, where
> the grammar rules are implemented with class non-static members.
>
> Regards,
> &rzej
I believe that you are correct. I was hoping that someone more
knowledgeable about N2673 would speak up before me though.
My theory is that the proposal for 'auto' and the proposal for
initialization of member variables were handled completely separately
and the people involved did not meet to see that they should affect
one another. Just from an orthogonal view what you ask for should be
acceptable.
Your desire to use non-static members for Boot.Sprit is similiar to
the reason that I would like to use them. For instance, I want
advanced expression templates with state and I want to be able to
easily expand on existing expressions to make new expression objects
easily.
Currently I can only use the 'const reference to a temporary is valid
until the const reference goes out of scope' trick to allow for a
virtual method call to my more complex expression handler function.
But even that only works within a function/method and I can't have it
stored in an object to be handled by a state machine, for instance,
and it also requires a virtual method call when I'd prefer it to be
inlined/vectorized.
it looks like your 'DECLARE_AUTO_MEMBER' macro is the only way to do
this in c++0x. At least we can do this. But in my opinion, every place
where you must use the preprocessor #define like this indicates some
sort of language deficiency. Perhaps having auto members will become
a common language extension. Is it too late for c++0x? I can't imagine
that there would be unintended consequences to it.
--jeffk++
www.jdkoftinoff.com
restor
> initialization of member variables were handled completely separately
> and the people involved did not meet to see that they should affect
> one another. Just from an orthogonal view what you ask for should be
> acceptable.
In fact, the authors did propose this 'auto' extension to member
initializers. They later refrained, fowever, because one of the
international bodies found it unacceptable to have the size of the
class determined by the 2-phase name lookup and ADL (I read it in
N2673).
It sounds fair enough to say that we make the programmers' life a bit
harder to avoid some implementation problems, but if I read the
decltype proposal correctly, we are going to have the size of the
class determined by the 2-phase name lookup and ADL anyway. Thus, we
will end up with making the programmers' life a bit harder, and avoid
no implementation problems in exchange.
I may be wrong in interpreting the decltype proposal, though, therfore
I hoped that someone competent would explained the above.
Regards,
&rzej