
Named tuple for C++ - ingve
http://vitiy.info/named-tuple-for-cplusplus/
======
cbsmith
Yup. I reached the same idea a while ago. I didn't use a hash for the fields
though. If you think about it, you don't need a hash function at all. A hash
function actually slows down compile times! At compile time, you just resolve
all the names to offsets in the tuple (simpler, and the added benefit of no
hash collisions). I created a "Symbol" type for string constexpr's and used a
user defined literal for them.

It seems to me like Boost.Hana is the natural way to do it.

~~~
daemin
So you effectively make an enum out of the names in the tuple. That way you
can even use the enum to use as the index into the get<> function calls.

~~~
cbsmith
Yes, that is one way of looking at it, though enums don't use string
constants.

------
temac
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.

~~~
userbinator
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.

~~~
tcbawo
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.

------
gnuvince
I don't know C++, so sorry if this is a dumb question: what's the difference
between a tuple with named fields and a struct?

~~~
plorkyeran
You can do metaprogramming things like iterate over the fields of a tuple or
unpack it into the arguments of a function, but you can't with a struct
(without manually defining an array of fields).

------
jbandela1
Looks very nice. The nice thing about tuples is they can be manipulated
generically to do some really cool stuff like destructuring and pattern
matching, serialization, remote marshalling, etc. Making them easier to use is
a win for all.

------
bnastic
I always shy away from clever solutions that involve semantics that's not
obvious to the reader. If something using this code lends on your lap you are
going to spend hours tracking its source, figuring out what the author was
trying to say, etc.

I know, I've been there. Making my coworkers' lives harder than it needed to
be with clever template magic didn't help anyone. I ripped that code out soon
after.

But if the code like this is well contained, and is there to solve a very
specific problem that maintainers will be able to handle, then go for it.

------
bobmoretti
The std::tie function can also solve this problem in most situations, if you
are stuck with C++ 11.

~~~
cbsmith
Not really. You don't get the names of your fields from std::tie.

std::tie is more of a way to map non-named tuples to and from other data
structures.

------
makecheck
Just use two parallel containers: one for names, and one for values. It is
dead simple to check that they have the same size and iterate over both
simultaneously where needed. And the best part is, for code that does not
actually require both pieces of information, you can pass one of the lists and
pretend that the other does not exist. Code that only knows how to visit
values only has to deal with values and not weird hybrid name/value elements.

Seriously, _always_ try the simpler thing first. Do not go deeper into
templates and special syntax before seeing if any other construct will do the
job.

~~~
nhatbui
Is this only appropriate for the case where we want to iterate over all the
elements? Don't we lose the O(1) access using a name? I'm assuming you're
making 2 arrays.

~~~
makecheck
Yes. My point is to consider what is actually required before making complex
structures. It is often perfectly acceptable to combine two existing types and
handle what few interactions they actually have.

------
allending
From article:

> A lot of you now are thinking about making custom struct with named fields,
> than and passing typed result as this struct. This is good solution and
> there are a lot of cases when this will be actually better, but … this is
> not so simple. But what if you know that this temporary structure is rather
> limited in size and will be used just ‘here’ to pass results...

I'd still use a custom struct with named fields. I don't see the above being
anywhere close to justifying the additional complexity.

------
chris_wot
Why does this require C++14?

