Opened 8 years ago

Closed 8 years ago

#10811 closed Feature Requests (fixed)

Add operators !=, <=, >, >=

Reported by: viboes Owned by: Antony Polukhin
Milestone: Boost 1.58.0 Component: variant
Version: Boost 1.57.0 Severity: Problem
Keywords: Cc:

Description

These operators are missing. It should be great if they are defined in function of the corresponding operators on the corresponding types.

Change History (9)

comment:1 by Antony Polukhin, 8 years ago

Milestone: To Be DeterminedBoost 1.58.0
Owner: changed from ebf to Antony Polukhin
Status: newassigned

Added missing operator to the develop branch.

comment:2 by gast128@…, 8 years ago

Isn't this the same as #8620?

comment:3 by viboes, 8 years ago

Thanks even if I expected that operator>= be defined in terms of operator>= :(

I find weird making private these kind of overloads.

 inline bool operator>=(const variant& rhs) const
 {
 return !(*this < rhs);
 }

Does it means that

variant< int, string> v = 1;
auto x = 1 < v;

would compile and

variant< int, string> v = 1;
auto x = v < 1;

wouldn't?

in reply to:  2 comment:4 by Antony Polukhin, 8 years ago

Replying to gast128@…:

Isn't this the same as #8620?

This ticket is more generic, #8620 requests only operator!=().

in reply to:  3 comment:5 by Antony Polukhin, 8 years ago

Replying to viboes:

Thanks even if I expected that operator>= be defined in terms of operator>= :(

Current approach reduces binary size. It also follows the Standard Library approach (for example std::vector implement comparisons in the same way) to reduce requirements for ValueTypes.

I find weird making private these kind of overloads.

 inline bool operator>=(const variant& rhs) const
 {
 return !(*this < rhs);
 }

Does it means that

variant< int, string> v = 1;
auto x = 1 < v;

would compile and

variant< int, string> v = 1;
auto x = v < 1;

wouldn't?

Both cases won't compile. I was following the existing schema and implemented those operators in the same way as operator== and operator< were implemented.

Though it could be useful to have comparison operators with types that are held in variant, just like in your example: (1 < v || v < 1). To do it in an effective way some metaprograming pretty close to one required by #547 must be done. Created a separate ticket #10845 for this feature.

comment:6 by viboes, 8 years ago

Sorry I meant

template <typename U>
 void operator>=(const U&) const
 {
 BOOST_STATIC_ASSERT( false && sizeof(U) );
 }

Why have you added this assertion so that the

auto x = v < 1;

doesn't compiles and the you add another ticket to allow it?

Am I missing something?

in reply to:  6 comment:7 by Antony Polukhin, 8 years ago

Replying to viboes:

Am I missing something?

Current implementation forbids such conversions because they could be very ineffective:

variant<int, std::sting> v(1);

// implicit construction of variant with a string in it
auto res = (v != "How you doin'? - (C) Joey");

Such approach was used long time ago for variant::operator== and variant::operator<.

Why separate ticket? Because:

  • I'm not sure that such comparisons could be implemented using C++03 in an efficient way, they could be enabled as an extension that requires C++11/C++14. There are some chances that #10845 will be resolved as 'wontfix', because of compiler limitations or some other issues.
  • Current implementation of comparison operators will remain (at least partially) even if the new one will be added
  • This ticket will be fixed in Boost 1.58. New comparison operators could take some time to implement and I'm not sure that they will make their way into Boost 1.58. My memory is lame and that's why some reminder (ticket) is added to trac to not forget about cool feature to implement :)

comment:8 by viboes, 8 years ago

std::experimental optional defines comparison between optional<T> and T so that it can be done more efficiently. What is wrong with this?

I would prefer to have a good c++11 interface that don't have one at all.

A std::less<variant<Args...>> specialization in function of std::less<Args>... is necessary in the cases where one of the Args don't defines operator <, but has the std::less specialization. I could create a new ticket for this, if you agree.

comment:9 by Antony Polukhin, 8 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.