diff mbox

Re: cString operator= with same buffer

Message ID 200511221033.05622.holger.brunn@stud.uni-karlsruhe.de
State New
Headers

Commit Message

Holger Brunn Nov. 22, 2005, 9:33 a.m. UTC 
  > I think something should be done to fix the "assign cString to itself"
> case, even though this is very unlikely. This does go wrong with the
> current code, even with the copy constructor added.

Okay, now as all seems to be said, here is a patch that checks for that case 
(that may happen when working with references/pointers to cStrings), leaving 
Klaus with the decision whether it's useful to have it or not.

Greetings
Holger

Comments

Sascha Volkenandt Nov. 23, 2005, 8:10 p.m. UTC | #1 
On Tuesday 22 November 2005 10:33, Holger Brunn wrote:
> Okay, now as all seems to be said, here is a patch that checks for that
> case (that may happen when working with references/pointers to cStrings),
> leaving Klaus with the decision whether it's useful to have it or not.

Is this the complete patch now? I still suggest adding a copy ctor (which 
should word like operator= without freeing)..

Greetings,
Sascha
Holger Brunn Nov. 23, 2005, 9:51 p.m. UTC | #2 
> Is this the complete patch now? I still suggest adding a copy ctor (which
> should word like operator= without freeing)..

The copy constructor is added with the patch from an older posting 
(vdr-cstring-copyctor.diff).

Regards
Holger
Clemens Kirchgatterer Nov. 25, 2005, 12:56 p.m. UTC | #3 
Holger Brunn <holger.brunn@stud.uni-karlsruhe.de> wrote:

> > I think something should be done to fix the "assign cString to
> > itself" case, even though this is very unlikely. This does go wrong
> > with the current code, even with the copy constructor added.
> 
> Okay, now as all seems to be said, here is a patch that checks for
> that case (that may happen when working with references/pointers to
> cStrings), leaving Klaus with the decision whether it's useful to
> have it or not.

why not just:

typedef std::string cString;

or:

class cString : public std::string { ... };

i really can't understand all this messing with a datatype allready
implemented elsewhere. what is so special about cString that other
string implementations do not have?

my 0.02E
clemens
Gunnar Roth Nov. 25, 2005, 1:14 p.m. UTC | #4 
Clemens Kirchgatterer wrote:

>Holger Brunn <holger.brunn@stud.uni-karlsruhe.de> wrote:
>
>  
>
>>>I think something should be done to fix the "assign cString to
>>>itself" case, even though this is very unlikely. This does go wrong
>>>with the current code, even with the copy constructor added.
>>>      
>>>
>>Okay, now as all seems to be said, here is a patch that checks for
>>that case (that may happen when working with references/pointers to
>>cStrings), leaving Klaus with the decision whether it's useful to
>>have it or not.
>>    
>>
>
>why not just:
>
>typedef std::string cString;
>
>or:
>
>class cString : public std::string { ... };
>
>i really can't understand all this messing with a datatype allready
>implemented elsewhere. what is so special about cString that other
>string implementations do not have?
>  
>
AFAIR it is because of Klaus disliking standard stuff  like stl, 
utf-8,gettext , ntpl and so on.

regards,
gunnar
diff mbox

Patch

diff -Nu vdr-1.3.36-org/tools.c vdr-1.3.36/tools.c
--- vdr-1.3.36-org/tools.c	2005-11-20 12:58:55.000000000 +0100
+++ vdr-1.3.36/tools.c	2005-11-22 10:22:31.000000000 +0100
@@ -539,6 +539,7 @@ 
 
 cString &cString::operator=(const cString &String)
 {
+  if(this==&String) return *this;
   free(s);
   s = String.s ? strdup(String.s) : NULL;
   return *this;