4 ms·

actually: auto obj = [ x=1, y="foo" ]{};

reubenmorais 12y ago
This just declares a lambda with two parameters with default values. You can't do obj.x, you can't declare "objects" inside of obj, you can't return obj in the parent scope. Why would you ever do: [x=1, y="foo"]{ // use x, y }(); When you can just do: auto x = 1; auto y = "foo"; // use x, y ?
- matt42 12y ago
  I have no idea if it is in the standard, but this actually compile with gcc 4.9 -std=c++1y auto obj = [ x=1, y="foo" ]{}; obj.x; obj.y;
- matt42 12y ago
  It is in the C++14 standard: For every init-capture a non-static data member named by the identifier of the init-capture is declared in the closure type. This member is not a bit-field and not mutable. http://isocpp.org/files/papers/N3648.html http://isocpp.org/files/papers/N3648.html
  - thwest 12y ago
    Actually the member can still be declared `private:` and the `obj.a.name` would not be portable. It appears GCC's implementation to make these members `public:` is conforming to c++11 but do not rely on this behavior. I've been told in ##C++ that the current C++14 draft says: `An init-capture behaves as if it declares and explicitly captures a variable of the form “auto init-capture ;” whose declarative region is the lambda-expression’s compound-statement` This change would make the named member access non-conforming
matt42 12y ago
Amazing :) I did not know that you could access lambda capture expressions. This can indeed reproduce parts of iod's features. However, this syntax does not provides static introspection, and does not support nesting properly : auto obj = [ name = 1, a = [name = 1]{} ]{}; obj.a.name; test.cc: In function ‘int main()’: test.cc:5:38: warning: already captured ‘name’ in lambda expression auto obj = [ name = 1, a = [name = 1]{} ]{}; ^ test.cc:7:9: error: ‘struct main()::<lambda()>’ has no member named ‘name’ obj.a.name;
- yyyymmdd 12y ago
  that's not syntax not supporting nesting, that's gcc having bugs with nested captures. clang++ does not error on this. (strange, but this does not compile with gcc and clang versions I have currently at hand. It did compile a few weeks ago when I tried it...)

This just declares a lambda with two parameters with default values. You can't do obj.x, you can't declare "objects" inside of obj, you can't return obj in the parent scope. Why would you ever do: [x=1, y="foo"]{ // use x, y }(); When you can just do: auto x = 1; auto y = "foo"; // use x, y ?

matt42 12y ago
I have no idea if it is in the standard, but this actually compile with gcc 4.9 -std=c++1y auto obj = [ x=1, y="foo" ]{}; obj.x; obj.y;
matt42 12y ago
It is in the C++14 standard: For every init-capture a non-static data member named by the identifier of the init-capture is declared in the closure type. This member is not a bit-field and not mutable. http://isocpp.org/files/papers/N3648.html http://isocpp.org/files/papers/N3648.html
- thwest 12y ago
  Actually the member can still be declared `private:` and the `obj.a.name` would not be portable. It appears GCC's implementation to make these members `public:` is conforming to c++11 but do not rely on this behavior. I've been told in ##C++ that the current C++14 draft says: `An init-capture behaves as if it declares and explicitly captures a variable of the form “auto init-capture ;” whose declarative region is the lambda-expression’s compound-statement` This change would make the named member access non-conforming

matt42 12y ago

Amazing :) I did not know that you could access lambda capture expressions. This can indeed reproduce parts of iod's features. However, this syntax does not provides static introspection, and does not support nesting properly : auto obj = [ name = 1, a = [name = 1]{} ]{}; obj.a.name; test.cc: In function ‘int main()’: test.cc:5:38: warning: already captured ‘name’ in lambda expression auto obj = [ name = 1, a = [name = 1]{} ]{}; ^ test.cc:7:9: error: ‘struct main()::<lambda()>’ has no member named ‘name’ obj.a.name;

yyyymmdd 12y ago
that's not syntax not supporting nesting, that's gcc having bugs with nested captures. clang++ does not error on this. (strange, but this does not compile with gcc and clang versions I have currently at hand. It did compile a few weeks ago when I tried it...)