Topic: string::npos is unhandy and dangerous
Author: Rich Paul <rpaul@trcinc.com>
Date: 1996/04/12 Raw View
Nathan Myers, http://www.cantrip.org/ wrote:
> This is very astute. The question of how npos should specified
> is still up for discussion, for just the reason John mentioned.
> Clearly, the standard must not constrain allocators in this way
> just allow the basic_string template to be described more
> conveniently.
I'm wondering if the string template is perhaps a bit TOO flexable.
---
[ 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
]
Author: "Nathan Myers, http://www.cantrip.org/" <ncm@cantrip.org>
Date: 1996/04/06 Raw View
john (j.d.) hickin <hickin@nortel.ca> wrote:
>
> The basic problem has been already been noted raised by Mr. Kanze. Because
> the basic_string contains the following declaration:
>
> static const size_type npos = -1;
>
> it is evident that there is a constraint that size_type must be something thay
> can be constructed from an integral type. I can't quite recall the wording of
> the original post but it was made clear that size_type cannot be arbitrary.
This is very astute. The question of how npos should specified
is still up for discussion, for just the reason John mentioned.
Clearly, the standard must not constrain allocators in this way
just allow the basic_string template to be described more conveniently.
Nathan Myers
ncm@cantrip.org
---
[ 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
]
Author: Nico Josuttis <nico@bredex.de>
Date: 1996/04/02 Raw View
Following the standard, all find() member functions for string
return string::size_type and may have the value string::npos,
which is (size_type)-1.
I have some problems with that:
1.) If i understand it right I have to write:
string::size_type pos;
pos = s.find('x');
if (pos == string::npos)
// not found
...
This seems unhandy und thus dangerous as people might
try to make the code simpler:
For example:
int pos
pos = s.find('x');
if (pos == string::npos)
or even
if (pos == -1)
The problem is that the test with operator== fails if
sizeof(size_type) != sizeof(int)
because unfortunately then
(size_type)-1 is not -1
This is due to the conversion to unsigned.
Am I missing something or are these problems known?
Why wasn't taken a simpler and safer interface?
2.) I wonder what "npos" means.
Could somebody tell me?
--------
Nico address: BREDEX GmbH
email: nico@bredex.de Nicolai Josuttis
Fallersleber-Tor-Wall 23
phone: +49 531 24330-0 D-38100 Braunschweig
fax: +49 531 24330-99 Germany
--------
[ 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 ]
Author: np2@doc.ic.ac.uk (Nat Pryce)
Date: 1996/04/04 Raw View
In article <199604020902.LAA06787@bredex.bredex.de>,
Nico Josuttis <nico@bredex.de> writes:
>
>Following the standard, all find() member functions for string
>return string::size_type and may have the value string::npos,
>which is (size_type)-1.
... example elided...
> This seems unhandy und thus dangerous as people might
> try to make the code simpler:
> For example:
> int pos
> pos = s.find('x');
> if (pos == string::npos)
> or even
> if (pos == -1)
>
> The problem is that the test with operator== fails if
> sizeof(size_type) != sizeof(int)
> because unfortunately then
> (size_type)-1 is not -1
> This is due to the conversion to unsigned.
>
> Am I missing something or are these problems known?
> Why wasn't taken a simpler and safer interface?
Obviously these problems are known, because that is why the type
string::size_type and the constant string::npos were defined. This
is the safe interface, and I don't think it can be any simpler.
In fact I feel it is easier to read than "if( pos == -1 )" and
hides the implementation of the string. Is it really a problem to
type 14 extra characters, expecially when the result is code
which is more readable, easier to maintain, and *works*?
Basically, if you don't write to the interface then you cannot
expect your code to work in all cases. That is the point of an
interface, after all.
>
> 2.) I wonder what "npos" means.
> Could somebody tell me?
>
How about "no position"?
Cheers,
Nat.
--
+-------------------------------------------+--------------------------------+
| Name: Nat Pryce MEng ACGI O- | Mail: Department of Computing,|
| Email: np2@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 (Direct Dial) | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+-------------------------------------------+--------------------------------+
---
[ 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 ]
Author: "john (j.d.) hickin" <hickin@bnr.ca>
Date: 1996/04/05 Raw View
The basic problem has been already been noted raised by Mr. Kanze. Because
the basic_string contains the following declaration:
static const size_type npos = -1;
it is evident that there is a constraint that size_type must be something thay
can be constructed from an integral type. I can't quite recall the wording of
the original post but it was made clear that size_type cannot be arbitrary.
--
John Hickin Nortel Technology, Montreal, Quebec
(514) 765-7924 hickin@nortel.ca
---
[ 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 ]