While it *can* be context sensitive, I don't think it's *necessary* for it to be context sensitive. Java generates compareTo methods on our structs that just performs an arbitrary (but stable) comparison. This means that you don't need to provide an implementation. If you want to, you can, by implementing your own Comparator as needed.
On Mon, Jul 26, 2010 at 4:34 PM, Basu Chaudhuri <[email protected]>wrote: > I'd rather say using structures as set elements isn't uncommon :-). It's > just that a predicate typically involves context-sensitive information, and > adding auto-generated code for that doesn't make sense. > > Basu > > > -----Original Message----- > From: Raghava Mutharaju [mailto:[email protected]] > Sent: Monday, July 26, 2010 3:42 PM > To: [email protected] > Subject: Re: C++ thrift code -- operator < not defined > > Thank you Basu & David. > > ThriftTest_extras.cpp is the file that David was referring to. After I > included it, the linker errors were resolved. > Isn't using structures as set elements common because Rush & David indicate > that they don't use operator< even though they have complicated structures. > > Regards, > Raghava. > > On Mon, Jul 26, 2010 at 6:14 PM, David Reiss <[email protected]> wrote: > > > You only get a link error if you try to use operator<, including by using > > a structure type as a set element or map key. > > > > The test code has another source file that defines the operator for the > > structures it uses. > > > > --David > > > > Raghava Mutharaju wrote: > > > Hi Rush, > > > > > > Thank you for the reply :). I was thinking that the compiler can do > > > something on the lines of what it does for operator ==. It checks for > the > > > equality of all the fields. Similarly, may be operator <() can compare > > all > > > the fields or provide an option for a comparator. > > > > > > If you don't provide the definition for operator <, then I might be > > missing > > > something here because I get linker errors due to that. I tried the > > thrift > > > test classes that come with the source. They also generate the same > kind > > of > > > linker errors. Errors from one of the tests that come with thrift is > > given > > > below. I do include boost & thrift libs and provide -lthrift option to > > g++. > > > > > > > > > Undefined symbols: > > > "thrift::test::Insanity::operator<(thrift::test::Insanity const&) > > const", > > > referenced from: > > > > > std::less<thrift::test::Insanity>::operator()(thrift::test::Insanity > > > const&, thrift::test::Insanity const&) constin ThriftTest_types.o > > > bool std::operator< <thrift::test::Insanity const, > > > std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >> (std::pair<thrift::test::Insanity const, std::basic_string<char, > > > std::char_traits<char>, std::allocator<char> > > const&, > > > std::pair<thrift::test::Insanity const, std::basic_string<char, > > > std::char_traits<char>, std::allocator<char> > > const&)in > > > ThriftTest_types.o > > > bool std::operator< <thrift::test::Insanity const, > > > std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >> (std::pair<thrift::test::Insanity const, std::basic_string<char, > > > std::char_traits<char>, std::allocator<char> > > const&, > > > std::pair<thrift::test::Insanity const, std::basic_string<char, > > > std::char_traits<char>, std::allocator<char> > > const&)in > > > ThriftTest_types.o > > > ld: symbol(s) not found > > > collect2: ld returned 1 exit status > > > make: *** [ThriftTest] Error 1 > > > > > > > > > Regards, > > > Raghava. > > > > > > On Mon, Jul 26, 2010 at 5:40 PM, Rush Manbert <[email protected]> > wrote: > > > > > >> Hi Raghava, > > >> > > >> I'm surprised that none of the developers have chimed in, but I'll > give > > it > > >> a try. > > >> > > >> The compiler declares the operator, but it can't define it for you > > because, > > >> in general, it can't know what "less than" means for your thrift > struct. > > But > > >> the compiler does know that you'll need to define this operator if you > > want > > >> to put your structure into a set, or use it as a key in a map, so it > > >> helpfully provides the declaration. You need to provide the > definition. > > >> > > >> I would imaging that we are like many other thrift users. We use it > for > > >> many things, and have lots of fairly complicated structures defined, > but > > I > > >> have yet to need to write an implementation for operator<, because we > > don't > > >> use the thrift classes in a way that requires it. > > >> > > >> - Rush > > >> > > >> On Jul 26, 2010, at 2:18 PM, Raghava Mutharaju wrote: > > >> > > >>> Hi, > > >>> > > >>> I got the answer on why overloading of operator < is required. > std::set > > >>> orders its elements, so "<" operator is required for comparison on > the > > >> type > > >>> of elements it is holding. > > >>> > > >>> But I haven't got answer to my other question -- why doesn't thrift > > >> compiler > > >>> generate code for this? Does the thrift community write their own > > >>> implementations for "operator <" ? > > >>> > > >>> Thank you. > > >>> > > >>> Regards, > > >>> Raghava. > > >>> > > >>> On Mon, Jul 26, 2010 at 4:09 PM, Raghava Mutharaju < > > >>> [email protected]> wrote: > > >>> > > >>>> Hello all, > > >>>> > > >>>> In the code that thrift generates for C++, in all the classes, it > > >> overloads > > >>>> 3 operators, ==, != and <. Implementations for == and != are > provided > > >> but > > >>>> there won't be any implementation for < operator. Why is this so? > How > > >> come > > >>>> it doesn't generate any compilation errors? (except in one case I > got > > a > > >>>> linker error -- mentioned in my previous post). How are these > > overloaded > > >>>> operators used? > > >>>> > > >>>> Thank you. > > >>>> > > >>>> Regards, > > >>>> Raghava. > > >>>> > > >> > > > > > >
