Re: How to convert a vector type into string?

Eugene Gershnik wrote: 
Tom Widmer wrote:

Eugene Gershnik wrote:

Hmmm. I am looking at the source to STLPort 4.5.3 and cannot see
this. Are you using a different version?


I think I'm looking at 5.0RC2, but I doubt this has changed. Are you
looking in stlport/stl/debug/_string.h?


The very same. No asserts there as far as I can see. 

Ahh, it has indeed changed for 5.0:

basic_string(const _CharT* __s, size_type __n,
               const allocator_type& __a = allocator_type()) :
    _ConstructCheck(__s),
    _STLP_NON_DBG_STRING_BASE(__s, __n, __a), _M_iter_list(_Get_base()) {}

//...

  __construct_checker(const value_type* __p) {
    _STLP_VERBOSE_ASSERT((__p != 0), _StlMsg_INVALID_ARGUMENT)
  }

Interestingly, GCC 4.0 only asserts if the pointer is null and the length is greater than zero, which is the more permissive precondition that you propose.


>>>Dinkumware that comes with VC 7.1 certainly doesn't assert. 

The debugging mode is only available if you purchase the unabridged
library from Dinkumware. See http://www.dinkumware.com/libdual_vc.html
and the "safe iterator checking" mode.


Ah this one. Well I don't see what safe iterator checking has to do with the issue of allowing basic_string(NULL, 0) but perhaps. I have no means to verify since I don't have this library and unlikely ever will.

Quoting from the link I sent you:
"A superset of the tests available with other libraries, this feature helps you detect invalid iterator operations in the Standard Template Library, as well as null pointers and invalid ordering rules for sorting or ordering maps, sets, and hash tables."

"null pointers" suggests that it does check for improper passing of null pointers.

In any case to make everybody happy a check for NULL could be made before passing the parameter. This should be 100% standard kosher and still as fast or faster than

std::string aString(vec.begin(), vec.end());

on the current implementations. 

Indeed.

In any case I

think that an implementation that will assert would be pretty
stupid. Apart from enforcing standard's requirement is there any
platform where it could fail?


Perhaps it fails under C++/CLI (with a null pointer exception or
suchlike), though I don't have it installed to check.


But the whole point is that the pointer is *not* dereferenced anywhere. This is in constrast with basic_string(NULL) where the implementation has either to explicitly check for NULL or it will fail on strlen(). This whole issue boils down to whether

memcpy(p, NULL, 0);

should work.

Given that there is no requirement on libraries to use memcpy here, I don't think it boils down to that at all! memcpy isn't the fastest way of copying small buffers on some platforms in any case - Duff's Device or a for loop (with compiler unrolling) can perform better.

The expression
"&array[0]" may well invoke some kind of bounds check.


It may, but we already eliminated that with begin(const std::vector &).

Ahh, I was talking about your earlier version, the one that did &vec[0]. So discount it, if you have discarded that one entirely for the "begin" version.

In any case, an
implementation that checks that your code has defined behaviour is
hardly stupid. You seem to have some definite expectation as to what
the behaviour should be, which seems very strange to me given that it
isn't defined anywhere (or rather, it is defined as "undefined"). It
seems only natural to me that a function might check its
preconditions, or might not, or might crash, if you pass the wrong
arguments.


An implementation is free to define its own preconditions that are more relaxed than the standard ones. It is also free to define UB in particular circumstances. If an implementation would work just fine when parameters are (NULL, 0) trying to enforce the letter of the standard rather than document its own, more relaxed, preconditions would be stupid IMHO.

You're advocating writing standard libraries that promote the writing of non-standard code, which defeats the purpose of having a standard in the first place. This we'll just have to agree to disagree on.

Tom
.

Relevant Pages

  • Re: Popularity of programming languages
    ... > unfair comparison: it is comparing, ... If most libraries can accomplish all of their ... that suggests that the standard ... elicited some other pointers to other collections (and some gratuitous ...
    (comp.lang.lisp)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: comparing doubles for equality
    ... AFAIK there is no ANSI/ISO standard for it. ... Fortran 95 seem to have some built-in operators but it's not clear ... LIA,GIA,ICE libraries for interval methods in C++ from Delisoft ... Actually I've been for quite some months proposing getting together ...
    (comp.programming)
  • Re: "Criticism of the C programming language ??????"
    ... "that's not in the standard, ... rewrites of the compiler. ... PH> They got all the compiler vendors to agree to a common ... or graphics libraries or threading libraries, ...
    (comp.lang.c)
Loading