thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrique Mendonça <henri...@apache.org>
Subject Re: C++ operator<
Date Fri, 08 Nov 2013 16:08:25 GMT
I think a default operator would be nice. To don't break the back
compatibility, we could add either a compiler parameter or a pre-compiler
switch (#ifdef), but we already have many of those. That's just my opinion,
but we do not need to be completely back compatible with older versions of
the libraries and I think this patch would be quite acceptable.
It's your guys call. If you have the patch already you can always upload it
to a Jira ticket and we can discuss it further there.

Cheers,
Henrique


On 8 November 2013 15:11, Ben Craig <ben.craig@ni.com> wrote:

> Unless I'm misunderstanding, providing a default implementation will cause
>
> multiply defined symbols (virtual or otherwise) for clients that currently
>
> have an implementation of op< for their code generated structures.
>
> What are you trying to do?  Is the current approach of providing a
> declaration of op< (but no definition) blocking you?  Is the lack of a
> default implementation causing significant development pain?
>
> Bryan Pham <bryan@cloudtenna.com> wrote on 11/07/2013 05:20:20 PM:
>
> > From: Bryan Pham <bryan@cloudtenna.com>
> > To: user@thrift.apache.org,
> > Date: 11/07/2013 05:20 PM
> > Subject: Re: C++ operator<
> >
> > Thanks all,
> >
> > Ben & Henrique,
> >
> > Would you guys take a virtual implementation of operator< (aka default
> > implimentation) that can still be overload that will not break existing
> > testing functionalities ?   I can make a patch.
> >
> > Best,
> > Bryan
> >
> >
> > On Thu, Nov 7, 2013 at 6:45 AM, Ben Craig <ben.craig@ni.com> wrote:
> >
> > > As Henrique mentioned, the generated C++ code generates a declaration
> for
> > > op<, but it doesn't provide an implementation.  Some of Thrift's tests
> > > provide an implementation in a separate C++ file.  Thrift does not
> > > currently code generate a definition for op<.  Generating an op< in
> the
> > > same C++ files that we currently generate would be a breaking change
> > > (multiply defined symbols).
> > >
> > > So Brian, you can provide an implementation for the code generated
> op<,
> > > and you can do so without modifying the generated code.  We already
> > > provide implementations of op== and op!=.
> > >
> > > > From: Henrique Mendonça <henrique@apache.org>
> > > > To: user@thrift.apache.org,
> > > > Date: 11/07/2013 07:57 AM
> > > > Subject: Re: C++ operator<
> > > > Sent by: hmendonca@gmail.com
> > > >
> > > > If I'm not wrong the < is defined but not implemented, so you can
> > > implement
> > > > it in any other cpp file and linker will do the job. It's like the
> part
> > > > file on C# but also kind of a hack. Hopefully someone has a better
> idea.
> > > >
> > > > I think we would be able to generate the operator too, just calling
> the
> > > > same operator of every member in other of declaration? What you
> think?
> > > >  Just let us know if you have a patch.
> > > >
> > > > Cheers,
> > > > Henrique
> > > >
> > > >
> > > > On 7 November 2013 08:50, Jens Geyer <jensgeyer@hotmail.com> wrote:
> > > >
> > > > > Generated code should not be modified for the very reason you
> > > mentioned.
> > > > > Some languages like C# generate partial classes that can be
> > > easilyextended.
> > > > >
> > > > > It could be worth a look if specifically this operator overload
> > > > > could/should be generated as well. One of the C++ people may chime
>
> in
> > > here.
> > > > > ______________________
> __________
> > > > > Von: Bryan Pham
> > > > > Gesendet: 07.11.2013 05:26
> > > > > An: user@thrift.apache.org
> > > > > Betreff: C++ operator<
> > > > >
> > > > > I was wondering what's the best practice for editing generated
> code. I
> > > > > want to enable operator< but everytime we generate code, I'd have
> to
> > > > > remember to edit the same code over.
> > > > >
> > >
> > >
> >
> >
> > --
> > Best,
> > Bryan Pham
> > Co-Founder and CTO, CloudTenna Inc.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message