On Friday, May 17, 1996, Max TenEyck Woodbury wrote...
> James P. Cohoon wrote:
> >
> > The class template basic_string in Jan 96 working paper defines
> > a constant npos in the following manner.
> >
> >         static const size_type npos = -1;
> >
> > Is the intent that this translate into a maximal-sized integral
> > value? If so, isn't this technically machine-dependent? I believe
> > in an earlier version of the working paper, there was a class
> > cstring that described a constant NPOS which explicitly represented
> > a maximal-sized integral value. If this is the intent for npos,
> > I believe it should also be explicitly stated.
> >     I believe the intent is to get the effect of a macro like NULL
> without cluttering the macro name space.  In that respect, the
> actual value is irrelavent. Maybe a little verbage to make the
> intent clear could be added.

The actual value is relevant, as the DWP frequently uses npos in size
comparisons and arithmetic. Consider the following ctor description:

  basic_string(const charT* s, size_type n,
               const Allocator& = Allocator());

  Requires:
    s shall not be a null pointer and n < npos.
  Throws:
    out_of_range if n == npos.

If npos == size_type(-1), i.e. the largest size_type, and sizeof(charT) >
1, say, 2, then the values between [npos/2+1,npos) are considered valid
under these rules, though you can't create a string of a size within that
range. Assuming you define max_size() as one less than the true maximum
size (leaving room for a nul terminator, so c_str() should be
well-defined, regardless of how it's implemented), I think it should
read:

  Requires:
    s shall not be a null pointer and n <= max_size().
  Throws:
    out_of_range if n > max_size().

As the largest size_type, npos will always be > max_size(), so npos still
works as the "impossible index value".

(This is based on the Jan-96 DWP, but npos is used similarly in the Apr-95
DWP; for example, see append(), replace(), etc., which do arithmetic with
npos.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

The class template basic_string in Jan 96 working paper defines
a constant npos in the following manner.

 static const size_type npos = -1;

Is the intent that this translate into a maximal-sized integral
value? If so, isn't this technically machine-dependent? I believe
in an earlier version of the working paper, there was a class
cstring that described a constant NPOS which explicitly represented
a maximal-sized integral value. If this is the intent for npos,
I believe it should also be explicitly stated.

Cheers,

Jim Cohoon


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James P. Cohoon wrote:
>
> The class template basic_string in Jan 96 working paper defines
> a constant npos in the following manner.
>
>         static const size_type npos = -1;
>
> Is the intent that this translate into a maximal-sized integral
> value? If so, isn't this technically machine-dependent? I believe
> in an earlier version of the working paper, there was a class
> cstring that described a constant NPOS which explicitly represented
> a maximal-sized integral value. If this is the intent for npos,
> I believe it should also be explicitly stated.
>     I believe the intent is to get the effect of a macro like NULL
without cluttering the macro name space.  In that respect, the
actual value is irrelavent. Maybe a little verbage to make the
intent clear could be added.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Max TenEyck Woodbury wrote:
>
> James P. Cohoon wrote:
> >
> > The class template basic_string in Jan 96 working paper defines
> > a constant npos in the following manner.
> >
> >         static const size_type npos = -1;
> >
> > Is the intent that this translate into a maximal-sized integral
> > value? If so, isn't this technically machine-dependent? I believe
> > in an earlier version of the working paper, there was a class
> > cstring that described a constant NPOS which explicitly represented
> > a maximal-sized integral value. If this is the intent for npos,
> > I believe it should also be explicitly stated.
> >     I believe the intent is to get the effect of a macro like NULL
> without cluttering the macro name space.  In that respect, the
> actual value is irrelavent. Maybe a little verbage to make the
> intent clear could be added.

It seems that inherited from a bulk of C programs issue is going to bother.
It always seemed to me strange why direct and inderect referencing should
have two distinct invalid values - null (means zero typically) is invalid direct
reference and some large or negative integer is invalid for indirect one.
Perhaps because writing (!p) is shorter then (p != nil). To my mind, it will remain in the language forever. But concerning npos it seems better to difine
it as invalid indirect reference value, ensured by compiler producer to be
invalid (well, iinvalid in typical usage, you can't ensure it without run time
checking or hardware support).


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]