eval type

[mar]

Yes, they should standardize it (instead of adding useless bloat) since all mainstream compilers seem to support anonymous structs anyway and they are useful.

One side note, I guess there's a typo and assignment operators should return a reference; not that it would matter because one will usually use one += per expression.

[Rein Halbersma]

3/ portable C++
Package two int in some structure and define operators. Either of:

Code: Select all

typedef int[2] eval_t;
typedef std::array<int, 2> eval_t;
struct eval_t { int op, eg; };
std::pair<int, int>;

Advantage: vectorized syntax
Disadvantage: you need to define tons of operators (+move semantic).

Why would you worry about move semantics? For a simple struct wrapper around a couple of builtins, the compiler generated move constructor/assignment operator will do the right thing.

Note also that you can write a macro to generate the operators for you. Just write an operator@= in-class and the corresponding operator@ out-of-class in terms of the former. So if T is your eval_t struct with internal data v[2], and you currently have a bunch of code for @=+,-,*,/ etc.

Code: Select all

struct T 
{
    T& operator@=(T const& other) { v[0] @= other[0]; v[1] @= other[1]; return *this; }
}; 

T operator@(T const& L, T const& R) { return T(L) @= R; }

Note that you don't have to be cute and use the comma operator and do all the assignments and the return in one statement. Generated code will be the same. In any case, you could rewrite this as

Code: Select all

struct T
{
     GENERATE_OP_ASSIGN(+) // repeat for -, *, / etc.
};

GENERATE_OP(+) // repeat for -, *, / etc.

Alternatively, you can use Boost.Operators, that will do the same but I think that's not your cup of tea

[mar]

Not a bad idea using macros, I don't do that but it makes sense as it avoids potential copy-paste errors
btw. why not

Code: Select all

T operator@(T L, T const& R) { return L @= R; }

As for boost, well, you know my opinion 100MB worth of code/1.1M lines (for comparison: Unreal Engine 4 has 1.2M loc,
but to be fair boost probably contains lots of generated code for pre-C++11 compatibility)
=> a nasty dependency if you ask me, they should break it into smaller pieces but I wouldn't use it anyway - YMMV.

[Rein Halbersma]

Not a bad idea using macros, I don't do that but it makes sense as it avoids potential copy-paste errors
btw. why not

Code: Select all

T operator@(T L, T const& R) { return L @= R; }

There are many variations on this theme, IIRC the best thing to do is to use the NRVO and write

Code: Select all

T operator@(T const& L, T const& R) { T nrv(L); nrv @= R; return nrv; }

There's some item on this in one of the Effective C++ books, but that was with very old compilers. Nowadays, gcc/clang should generate identical code for all forms above, so just write for clarity first I would say.

[mar]

I think all modern compilers do RVO.
The only exception is perhaps Microsoft compiler which has problems with custom dtors (even if the body does nothing):

Code: Select all

struct s {
    ~s() {}
};

The workaround is to disable exceptions
I'm not sure if they fixed this issue but IIRC 2012 had this problem. I bet gcc/clang won't have problems with this, but I haven't tried.

[lucasart]

One side note, I guess there's a typo and assignment operators should return a reference; not that it would matter because one will usually use one += per expression.

Are you sure about that? I've always thought that the result of += is an r-value, not an l-value, and that:

Code: Select all

a += b += c;

is equivalent to

Code: Select all

a += (b += c);

is that not how the associativity rules work?

Edit: You're right!
https://en.wikipedia.org/wiki/Operators ... nd_C%2B%2B