On Fri, Oct 15, 2010 at 8:06 AM, Hyrum K. Wright
wrote:
> On Fri, Oct 15, 2010 at 4:35 AM, Branko Čibej wrote:
>> On 14.10.2010 20:39, Hyrum K. Wright wrote:
>>> The following is a somewhat naïve implementation, but does it jive
>>> with your suggestion?
>>
>> Roughly yes, see the other comment.
On 15.10.2010 15:06, Hyrum K. Wright wrote:
> (I hope our C docs point this out explicitly, too.)
If not, you're bound to find out sooner or later. :)
-- Brane
On Fri, Oct 15, 2010 at 4:35 AM, Branko Čibej wrote:
> On 14.10.2010 20:39, Hyrum K. Wright wrote:
>> The following is a somewhat naïve implementation, but does it jive
>> with your suggestion?
>
> Roughly yes, see the other comment.
> On reflection, though, I like the suggestion of returning an
> Steinar Bang :
> Philipp Marek :
>> It might be easier for callers if this did
>> if (isNull)
>> return "";
>> so that the value could just be used in printf() and similar without
>> explicit checking.
> If that was ok to do, one might as well represent a NULL with an empty
> string.
> Branko Čibej :
> std::string also doesn't have any virtual functions, nor does a bool
> member require a destructor. Memory deallocation is OK. std::string is
> actually a POD and tricky rules apply that allow you do do this
> safely, IIRC ...
Nevertheless, deleting a derived object from a
On 14.10.2010 20:39, Hyrum K. Wright wrote:
> The following is a somewhat naïve implementation, but does it jive
> with your suggestion?
Roughly yes, see the other comment.
On reflection, though, I like the suggestion of returning an
std::pair. Make a typedef of that so that users can
declare ret
On 14.10.2010 20:39, Hyrum K. Wright wrote:
> inline operator bool() const
> {
> return !isNull;
> }
This bit seriously changes the semantics of std::string. I recommend not
to override operator bool() like this. Write a different accessor
function instead.
-- Brane
On 14.10.2010 21:32, Steinar Bang wrote:
>> Branko Čibej :
>> All right. Then derive svn::string from std::string, and add a .null()
>> method. You get to use all the standard string alogorithm
>> specializations, plus you get what you want.
> There is one known objection to this: std::string
> Philipp Marek :
> It might be easier for callers if this did
> if (isNull)
> return "";
> so that the value could just be used in printf() and similar without
> explicit checking.
If that was ok to do, one might as well represent a NULL with an empty
string.
Hello Hyrum!
On Thursday 14 October 2010, Hyrum K. Wright wrote:
> The following is a somewhat naïve implementation, but does it jive
> with your suggestion?
...
> inline const char *c_str() const
> {
> if (isNull)
> return NULL;
> else
> return std::string::c_s
> Original Message
> Subject: RE: object-model: Return by value, reference or pointer? (or
> something else?)
> From: "Bolstridge, Andrew"
> Date: Thu, October 14, 2010 5:24 am
> To:
[snip]
> Personally, I would stick to just returning a str
> Branko Čibej :
> All right. Then derive svn::string from std::string, and add a .null()
> method. You get to use all the standard string alogorithm
> specializations, plus you get what you want.
There is one known objection to this: std::string doesn't have a virtual
destructor, so if you h
On Thu, Oct 14, 2010 at 5:22 AM, Branko Čibej wrote:
> On 13.10.2010 16:10, Hyrum K. Wright wrote:
>> On Tue, Oct 12, 2010 at 5:06 PM, Branko Čibej wrote:
>>> On 12.10.2010 22:30, Hyrum K. Wright wrote:
On Tue, Oct 12, 2010 at 2:40 PM, Branko Čibej wrote:
> On 12.10.2010 20:35, Hyrum
-Original Message-
> From: Steinar Bang [mailto:s...@dod.no]
> Sent: 13 October 2010 21:16
> To: dev@subversion.apache.org
> Subject: Re: object-model: Return by value, reference or pointer? (or
something else?)
> Do you need the distrinction between an empty string and a
On 13.10.2010 22:05, Steinar Bang wrote:
> I'm divided on whether I would move the delete of the RefCounter object
> into the dec_ref method, or leave it where it is. On one hand it feels
> like good encapsulation to put it together with the dec_ref, on the
> other hand, I've always been wary of
On 13.10.2010 16:10, Hyrum K. Wright wrote:
> On Tue, Oct 12, 2010 at 5:06 PM, Branko Čibej wrote:
>> On 12.10.2010 22:30, Hyrum K. Wright wrote:
>>> On Tue, Oct 12, 2010 at 2:40 PM, Branko Čibej wrote:
On 12.10.2010 20:35, Hyrum K. Wright wrote:
> 1) Return everything by value
>
> "Hyrum K. Wright" :
> I don't want the caller to have to depend upon the lifetime of the
> source object, hence the desire to return something by value or a
> newly allocated pointer.
> Additionally, it still wouldn't work, since references have to point
> to some object, hence there is no
On 10/13/2010 12:51 PM, Hyrum K. Wright wrote:
At this point, it's my turn to get confused. I'm speaking
specifically of cases where we return STL classes. Brane's earlier
suggestion to create an implicit bool conversion works fine for our
custom classes. The problem I'm trying to solve is "
t, Ph.D.
s...@reibert.com
--
> Original Message
> Subject: Re: object-model: Return by value, reference or pointer? (or
> something else?)
> From: "Hyrum K. Wright"
> Date: Wed, October 13, 2010 2:47 pm
> To: dev@subversion.apache.org
&
How about returning a pointer to an empty string (zero length) at some fixed
address (eg. allocated statically), which is good enough for most callers,
but provide a function or symbol that compares against that address?
This way you'd get an empty string back; if you care whether the property
On Wed, Oct 13, 2010 at 3:16 PM, Steinar Bang wrote:
>> "Hyrum K. Wright" :
>
>> At this point, it's my turn to get confused. I'm speaking
>> specifically of cases where we return STL classes. Brane's earlier
>> suggestion to create an implicit bool conversion works fine for our
>> custom cl
> "Hyrum K. Wright" :
> At this point, it's my turn to get confused. I'm speaking
> specifically of cases where we return STL classes. Brane's earlier
> suggestion to create an implicit bool conversion works fine for our
> custom classes. The problem I'm trying to solve is "how does one
> r
> "Hyrum K. Wright" :
> This is an interesting approach...and parallels what has already been
> done. :)
> Out of curiosity, have you taken a chance to look at the
> existing code here:
> http://svn.apache.org/repos/asf/subversion/branches/object-model/subversion/bindings/c++/include/Types.h
On Wed, Oct 13, 2010 at 2:42 PM, Steinar Bang wrote:
>> "Hyrum K. Wright" :
>
>> Refcounting smartpointers are used to avoid duplication of the
>> underlying C structures, but they are completely private. I've got
>> serious reservations about exposing that complexity in the external
>> objec
> "Hyrum K. Wright" :
> Refcounting smartpointers are used to avoid duplication of the
> underlying C structures, but they are completely private. I've got
> serious reservations about exposing that complexity in the external
> object interfaces. Given those reservations, the API would just
On Wed, Oct 13, 2010 at 2:28 PM, Steinar Bang wrote:
>> Steinar Bang :
>
>> "Hyrum K. Wright" :
>>> 2) Return everything by pointer
>>> Pros: can represent the NULL value, potentially less memory overhead
>>> Cons: more complex memory management (caller must delete returned value)
>
>> Um.
On Wed, Oct 13, 2010 at 11:51 AM, Steinar Bang wrote:
>> "Hyrum K. Wright" :
>
>> 2) Return everything by pointer
>> Pros: can represent the NULL value, potentially less memory overhead
>> Cons: more complex memory management (caller must delete returned value)
>
> Um... why must the cal
> Steinar Bang :
> "Hyrum K. Wright" :
>> 2) Return everything by pointer
>> Pros: can represent the NULL value, potentially less memory overhead
>> Cons: more complex memory management (caller must delete returned value)
> Um... why must the caller delete the returned value? I thought y
On Wed, Oct 13, 2010 at 11:44 AM, Julien Cugnière
wrote:
> 2010/10/13 Hyrum K. Wright
>> Another option is a custom SVN::String type which looks / smells /
>> acts like a string, but also allows wrapping the NULL value, in a
>> manner you suggest above.
>
> Sorry to intrude, but just an additiona
> "Hyrum K. Wright" :
> 2) Return everything by pointer
>Pros: can represent the NULL value, potentially less memory overhead
>Cons: more complex memory management (caller must delete returned value)
Um... why must the caller delete the returned value? I thought you were
using refcou
2010/10/13 Hyrum K. Wright
> Another option is a custom SVN::String type which looks / smells /
> acts like a string, but also allows wrapping the NULL value, in a
> manner you suggest above.
Sorry to intrude, but just an additional possibility : can the strings
manipulated by SVN contain embedde
On Tue, Oct 12, 2010 at 5:06 PM, Branko Čibej wrote:
> On 12.10.2010 22:30, Hyrum K. Wright wrote:
>> On Tue, Oct 12, 2010 at 2:40 PM, Branko Čibej wrote:
>>> On 12.10.2010 20:35, Hyrum K. Wright wrote:
1) Return everything by value
Pros: simpler memory management, less overhead (?
On 10/12/2010 06:06 PM, Branko Čibej wrote:
> So typically you'd add a hasAuthor function and throw an exception from
> getAuthor if there is no author info for a revision. However, in this
> particular case, returning an empty string is just as good, unless you
> want to make the fine distinction
On 12.10.2010 22:30, Hyrum K. Wright wrote:
> On Tue, Oct 12, 2010 at 2:40 PM, Branko Čibej wrote:
>> On 12.10.2010 20:35, Hyrum K. Wright wrote:
>>> 1) Return everything by value
>>>Pros: simpler memory management, less overhead (?)
>>>Cons: doesn't allow the return of NULL values, need
On Tue, Oct 12, 2010 at 2:40 PM, Branko Čibej wrote:
> On 12.10.2010 20:35, Hyrum K. Wright wrote:
>> 1) Return everything by value
>> Pros: simpler memory management, less overhead (?)
>> Cons: doesn't allow the return of NULL values, need to establish
>> conventions to represent NULL obje
On 12.10.2010 20:35, Hyrum K. Wright wrote:
> 1) Return everything by value
>Pros: simpler memory management, less overhead (?)
>Cons: doesn't allow the return of NULL values, need to establish
> conventions to represent NULL objects (an isNull() method?)
Meh.
inline operator bool()
[ This is more thoughts (and questions!) about the work on the
object-model branch. If you don't care about the nuances of such
things, you can stop reading now, and save your cycles for shipping
1.7 work. :) ]
I'm trying to determine the best way to return objects from the
various wrapping class
37 matches
Mail list logo
