http://groups.google.com/group/comp.lang.c++.moderated/msg/dca1e018039c79ff

quote:
—-
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.

—–

–jeffk++

Your example:

struct s { int i = 0; };

will be legal in C++0x

I would like for it to also allow:

struct s { auto i = 0; };

–jeffk++

…
* types without names (or hard-to-find names) ”

I even know where those hard-to-find names (or more exactly – types) will be came from:

auto i = …
…
auto j = i;
…
auto g = j;
…
auto v = g;
…
auto m = v;

Grats! We are going to get one more Basic.
Hope, I’m wrong.

The problem with your example is one of member initialisation and shouldn’t really be considered a limitation of ‘auto’. Consider the following (no use of auto, yet still illegal):

struct s { int i = 0; };

Type inferencing doesn’t _give_ you duck typing, but it’s certainly compatible with it. Although statically-typed languages (I’m thinking ML or Haskell) tend to give you a different flavour of duck, all the more sophisticated static type systems have some way of getting the expressivity and flexibility you’d use duck typing for without sacrificing type safety.

@Anocka:

I don’t see how that goes beyond the “inference just happens to let you declare variables in a style that can be similar to the way you do it all the time in a dynamically typed language”, which immediately follows the quote you’re disputing.

Yes, ACE.

“Again unlike a union, a variant can include essentially any kind of type.” I think you wanted to say “any can include”, not variant.

Never heard of POCO, are there any other great C++ libraries besides Boost?

ie:

class X
{
public:
X() {}
auto f = [](int x){ return x+2; };
};

int main()
{
X x;
std::cout << X.f(5) << “\n”;
return 0;
}

Of course this example is simplistic but there are numerous places where I’d love to be able to use this pattern with c++ expression template objects being directly within another object, and I don’t see why this pattern can’t be allowed.

–jeffk++

And a couple more facts:

boost::any has been ported to POCO
Poco::DynamicAny design was inspired by boost::any. It was not meant as a replacement for any, but rather as a complement, providing “softness” on the value extraction side
The downside of DynamicAny compared to boost::any is that it can not hold any value out-of-the-box (a holder specialization is needed)

There’s an article that should come out soon in Overload systematically comparing boost::any and boost::lexical_cast with Poco::DynamicAny. Stay tuned.

——————
WidgetBase* wb = new Widget();

if( dynamic_cast( wb ) ) { … }
——————

Wouldn’t wb’s dynamic type already be Widget* before the dynamic_cast?

Actually, boost::any can only be cast back to the exact type it holds. It works well for storing different types in an STL container. However, on the value retrieval side, it is even more rigid than the C++ language itself.

I would also disagree with Herb’s qualification of any_cast as flexible – boost::any is static and very rigid on the value extraction side. That’s where DynamicAny (see my reply above) comes handy.

One of the key verbosity-reducers of dynamic languages is duck typing. With boost’s “any”, you need to cast it to some concrete type before you can use it. “any” seems more like Java’s Object than anything from a dynamically typed language.

Type inference doesn’t give you duck typing, one of the key benefits of dynamic typing. It seems that, even with type inference, you can’t be “dynamic when needed” if that need is to call a method of a derived class, when all the compiler knows is that the object is of the base class.

In the ocaml object system, when a function calls the method m of type, say
m : unit -> int

on an object x, the inferred type of x is :
x : int; … >

Basically, the function accepts any object that has the m method. That’s close to the dynamic paradigm (except that the presence of the methods is checked at compile-time).

Sadly, I don’t know of any other similar typing system…

VecOp op = VecOp(op1, op2);

to

auto op = VecOp(op1, op2);

On an unrelated note, it’s interesting to see the reaction to Jeff’s use of var in C# over at refector my code. The first 3 out of five comments are complaints about it. It’ll be interesting to see if var in C# gets the same reaction as closures are getting in Java.

DynamicAny any(“42″);
int i = any; // i == 42
any = 65536;
std::string s = any; // s == “65536”
char c = any; // too big, throws RangeException

or this:

std::cout << RecordSet(session, “SELECT * FROM Table”);

All happening dynamically, behind the scene and (of course) in standard C++. See Poco::Data::Row and Poco::Data::RowFormatter sample for a more complete insight.