Hacker News Reader

Comment by temac | Hacker News Reader

WTF? Just use a struct. And interop with existing tuples; maybe conversion constructor and operator cast. 10 lines everybody can understand, not some crazy shit.

View on HN

Indeed, a structure is a named tuple. I think there's a subset of C++ users who pride themselves on creating massively complex solutions, as if they're trying to use as much of the features of the language as they can, instead of going for the simple, straightforward solution. AFAIK std::tuple does compile into the same code as if you declared a struct yourself, but I'd like to see what this convoluted solution compiles to... if I'm reading it correctly, this turns into an O(n) structure member access!?

What if You by mistake switch ‘GPA’ and ‘grade’ inside your function? Nothing will happen to inform You that something went wrong.

I don't know if there's a specific name for it, but "what if you did X" arguments like this fail to convince me.

Does O(n) even matter when you only store a small number of elmeents in the tuple anyway?

That variadic expansion happens at compile time, so it's still O(1) access. In my experience, the effects of something like this won't be immediately visible. You might start to notice compile times creeping up as the project grows. YMMV.

This does seem a bit crazy, but it's worth remembering that the named tuple is copied from Python. Although I suppose the excuse there is a lack of structs.

I think the difference is that you can't (afaik) generate a struct with metaprogramming.

But you can generate them with macros. The Boost preprocessor library can help a lot.

At work we use kind of a hybrid approach. We have generator macros that spit out named tuple classes that use a bunch of magic and template meta-programming.

It should go without saying that the macro implementation is ugly and only a few people understand it very well, but we don't have to change them much any more, and the resulting named tuples are easy to use and generally work exactly as expected.

Yes, lots of people do named tuples with preprocessor logic of one kind or another (protoc and a variety of serialization libraries basically give this to you). It's much cleaner if you can use the type system to do the job for you.

It's been a while since I even considered doing something like this, but you could probably generate them by recursively inheriting from a chain of generated base classes.

That said, most everyone who's looked at the problem has ended up going with macros instead. :-)

I'm not sure you could do what this does and give the members of the struct a user-supplied name though.

Can you create a named struct on the fly? Don't you have to define struct before?

return (firstPlayer:localPlayer, secondPlayer:connectedPlayer).

You'd have to create the struct before you can use it? Tuples allows usage a couple of times before you'd define a struct/class.

Why would you want to create a named tuple by invoking convoluted code (and arguable with the end result being also not trivial to use) instead of just declaring a structure?

This article is interesting to explore the technical capabilities of modern C++, but not to use the result...

Lightweight, low-overhead to use, iterable, self-documenting object

Given the implementation, there is nothing lightweight and low-overhead to use at build time, and at runtime how exactly is this lighter than a struct? As for self-documenting, I don't even know what it would mean here.

Remains "iterable". Given how modern compiler works, I'm still convinced you should convert plain tuples back and to a struct for source code simplicity and build time speed -- because it won't even do extra copies in most cases (and even if it does, who cares?)

Because I don't know what I want until I want it. I do a similar Tuple a couple of times I know I am going to need a container class/struct to avoid rewriting the same Tuple over and over again and it would also make things clearer as I know got a class/struct for that particular use case.

Now until I know I need one, it's unnecessary to clutter the namespace with yet another container class/struct.

Named Tuple has a few benefits, that's all. Until they don't.

You can do this in C++ 14.

   auto f() -> decltype(auto) {
     ...
     return (struct {
       int firstPlayer;
       int secondPlayer;
     }) {localPlayer, connectedPlayer};
   }

One great use of named tuples would be named function arguments. I've grown tired of seeing functions that take a bunch of doubles and always checking which argument is which.

This would be a case where C99 style designated initializers would come in handy in C++.

For example if you have a struct like:

  struct data {
      double w;
      double x;
      double y;
      double z;
  };

You can then create a struct of that type using syntax like:

  struct data d = {.w = 1.0, .x = 1.0, .y = 1.0, .z = 1.0};

Then you could have your functions take a struct data as a parameter, and use designated initializers to have syntax for keyword parameters.

I'm not sure why this feature never made its way into a C++ standard over the years.

Don't forget that you can also have functions return a struct.

I'd rather have something like Strong Typdef for that. Maybe we will get it eventually.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p010...

You can iterate on the tuple and know it size, not on the struct (unless you use Boost.Fusion or something equivalent).

Yeah, tuples make sense sometimes, that's why they are introduced. I think iterating through a tuple only makes sense if you store in some kind "similar" elements in there (not necessarily same type but same trait class). It could indeed be great for generic programming where your tuple have variadic length (depending on template parameters).

Just don't use it to replace structs, it doesn't make sense.

Reply on news.ycombinator.com