Inconsistent use of default arguments in string class?

Thread View: comp.std.c++

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Harald Winroth Wed, 01 Nov 1995 10:51

#2378

Author: Harald Winroth
Date: Wed, 01 Nov 1995 10:51

33 lines
2058 bytes

I have a question regarding the proposed string class. In the April WP 
there are string member functions taking both string and char* arguments. 
For example, there are

        class basic_string : ... {
          ...
                basic_string& append(const basic_string& str, size_t pos=0,
                                     size_t n=NPOS);
                basic_string& append(const charT* s, size_t n);
          ...
        };

As I understand the WP, 

        str.append("abc123", 3)

would append "abc" to str, while

        str.append((string)"abc123", 3) 

would append "123" to str. Is that interpretation correct? If so, I think
this could cause a lot of bugs in application code. Is there a good reason 
why string member function taking  charT* arguments won't also take the 
same position/size arguments as their basic_string-argument counterparts?

-----------------------------------------------------------------------------
Harald Winroth     | Computational Vision and Active Perception Laboratory,
harald@bion.kth.se | Royal Institute of Technology, S-10044 Stockholm, Sweden
-----------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Re: Inconsistent use of default arguments in string class?

#2419

Author: Bob Manson
Date: Fri, 03 Nov 1995 19:12

31 lines
2210 bytes

In article <HARALD.95Nov1105205@moon.bion.kth.se>,
Harald Winroth <harald@bion.kth.se> wrote:
>I have a question regarding the proposed string class. In the April WP 
[...text deleted]
>would append "123" to str. Is that interpretation correct? If so, I think

It is that way in Plauger's "The Draft Standard C++ Library", and I'm
pretty sure it's one of the things that didn't change in the April
draft.

Speaking as someone that's written an implementation of (and uses
pretty heavily) this string class interface, it hasn't been an issue
at all. I think it's because that all of the functions that take char*
work in a similar fashion, and it's simple enough (and perhaps a bit
more obvious code-wise) to add the offset to the char* pointer if
that's what is desired. (Admittedly it seemed a little disturbing when
I was initially implementing it, but it just hasn't been a problem in
actual use.)

But I would like to argue for removing the position offset from
append/assign/insert etc. The same thing can be accomplished with
using substr(), and for a reasonably efficient implementation there
would only be a little extra overhead--not to mention that it makes
the resulting code more readable. The reasoning for the current design
may have been that since the offset case is efficient for char*, it
should be equally efficient for instances of string as well.
						Bob
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads