Topic: Proposed addition to string library: strnew


Author: fox@research.att.com (David Fox)
Date: 12 Sep 90 18:15:51 GMT
Raw View
I am aware of strdup(), but it uses malloc rather than new and
it bombs if you pass it a zero pointer, rather than passing
back a zero pointer as strnew does.  I wasn't really that
serious about strnew, but I've received many replies saying
that strdup is the same as strnew, but its not.




Author: hansen@pegasus.att.com (Tony L. Hansen)
Date: 13 Sep 90 16:19:33 GMT
Raw View
In article <2699@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes:
< In article <FOX.90Sep7130228@devo.research.att.com> fox@research.att.com (David Fox) writes:
<< I propose the following function be added to the standard string.h:
<< inline char * strnew(const char *s) {
<<   return s ? strcpy(new char[strlen(s)+1], s) : 0;
<< }
<
< What's the matter with strdup()? It's not ANSI C, but it's in common
< usage among MS-DOS and OS/2 compilers.

strdup() is defined as using malloc() underneath. However, there's no
guarantee in any of the C++ books that new[] and malloc() must be
compatible in any way. In other words, you cannot assume that you can
create a value using new[] and then use free() on it later, or create a
value using malloc() and pass it to delete later.

It's guaranteed that new[] is NOT compatible for types with a
constructor or destructor, as new[] is required to keep track of the
number of members within the array. Some implementations of new[] may
use malloc(), but allocate a larger amount of memory, and then place
the number of members in front of the memory whose pointer is returned.
Such an implementation is DEFINITELY NOT compatible with malloc().
Whether this is done for all invocations of new[], or just those for
types without constructors/destructors, is implementation dependent.
Consequently, you cannot guarantee anything for any invocations of new[].

     Tony Hansen
    att!pegasus!hansen, attmail!tony
        hansen@pegasus.att.com




Author: fox@research.att.com (David Fox)
Date: 7 Sep 90 17:02:28 GMT
Raw View
I propose the following function be added to the standard string.h:

inline char *
strnew(const char *s)
{
  return s ? strcpy(new char[strlen(s)+1], s) : 0;
}




Author: bright@Data-IO.COM (Walter Bright)
Date: 10 Sep 90 18:22:22 GMT
Raw View
In article <FOX.90Sep7130228@devo.research.att.com> fox@research.att.com (David Fox) writes:
<I propose the following function be added to the standard string.h:
<
<inline char *
<strnew(const char *s)
<{
<  return s ? strcpy(new char[strlen(s)+1], s) : 0;
<}

What's the matter with strdup()? It's not ANSI C, but it's in common
usage among MS-DOS and OS/2 compilers.




Author: shankar@hpclscu.HP.COM (Shankar Unni)
Date: 10 Sep 90 23:39:13 GMT
Raw View
> inline char *
> strnew(const char *s)
> {
>   return s ? strcpy(new char[strlen(s)+1], s) : 0;
> }

Check out "strdup()".
---
Shankar.




Author: jeh@cs.rit.edu (Jim Heliotis)
Date: 11 Sep 90 16:15:44 GMT
Raw View
In article <FOX.90Sep7130228@devo.research.att.com> fox@research.att.com (David Fox) writes:
<I propose the following function be added to the standard string.h:

I have not followed this group very closely.  Has there ever been a discussion
of whether or not there should be a significant class library that comes
standard with C++, as in Smalltalk or Eiffel?  What made me think of this
is that it's a little embarassing to have a string "libarary" composed of
functions operating on char*, rather than a class String.  I might also
say that I recognize the controversy that would occur over choosing a model
of string behavior!

I would also be against any language dependencies on the library.

    Jim Heliotis
    Rochester Institute of Technology
    Rochester, NY 14623-0887
    jeh@CS.RIT.EDU
    {allegra,seismo}!rochester!rit!jeh