Thread: Though implementation problem

Originally Posted by Elysia

Std::string is one of the most unhelpful string classes I've seen. Replace is fatefully misnamed.

This is a matter of semantics. I find boost's replace_all is better named than your Replace.

Find_first_of, for example, is also inappropriate named. It should be named more similarly to find_any_first_of or the like since it finds any of the characters in the string, not the entire phrase.

I'm not a native speaker, but of in this sense means exactly the same as "any of" or one of ...

The replace function is misleading into believing it can search and replace a given occurrence of a string with another. Further, it does not reallocate or move data (I think?), so if you replace "Alice" with "Jonathan" you're going to overwrite data.

I think the arguments that string::replace take makes it quite clear what it does, namely, replace a certain number of characters at a certain position with another string (or a part of it). It is not a nice function, though, and it seems that even this reference doesn't get it quite right.

The std::replace is also flawed in that it can only replace single characters with another given character (if I remember this correctly). Who needs that? When I replace, I replace strings.

It is primarily not a string algorithm.

All in all, I agree that std::string is lacking a lot of things for high-level string manipulation. However, does that mean everybody should rewrite their own string class?

Originally Posted by anon

This is a matter of semantics. I find boost's replace_all is better named than your Replace.

I think the arguments that string::replace take makes it quite clear what it does, namely, replace a certain number of characters at a certain position with another string (or a part of it). It is not a nice function, though, and it seems that even this reference doesn't get it quite right.

Perhaps. Perhaps not. But if I see "replace," it sounds to me like it's going to replace all occurrences. That's what the name implies to me.

I'm not a native speaker, but of in this sense means exactly the same as "any of" or one of ...

In that case, it could take a vector of chars (although I think I can see why it doesn't...). Then it wouldn't be unambiguous anymore. But since it takes a string, it's name is misleading IMO.

It is primarily not a string algorithm.

But for all the power and functionality, it seems to lack some very common operations!?
So much for a string class. It's not a string class if it lacks a way to do common operations such as replacing strings.

All in all, I agree that std::string is lacking a lot of things for high-level string manipulation. However, does that mean everybody should rewrite their own string class?

No, of course not. I just wanted to do one that suited me better.
And hey look - it has turned into something so much bigger which is giving a lot of experience and classes that I can reuse later (iterator, and range iterator too, which I'm working on!).

All in all, I agree that std::string is lacking a lot of things for high-level string manipulation. However, does that mean everybody should rewrite their own string class?

I think they should do a backwards incompatible complete rewrite of the standard library with the advantage of hindsight, and then provide this new library parallel to the current standard library (which would then be deprecated) for the sake of the huge amount of code that depend on it.

Hey, that's what I'm doing for the I/O library.

Elysia, while reading this thread, something occurred to me. If I recall correctly, you've several times stated that std::string should be properly derivable, so that people can create subclasses with additional high-level manipulation functions. You made an argument against free functions in namespaces because they are not associated with std::string and aren't as easily found in the documentation.

This makes me wonder. Have you considered that the member functions of mystring are just as difficult, if not more so, to find for the std::string-user as free functions?

Originally Posted by CornedBee

Elysia, while reading this thread, something occurred to me. If I recall correctly, you've several times stated that std::string should be properly derivable, so that people can create subclasses with additional high-level manipulation functions. You made an argument against free functions in namespaces because they are not associated with std::string and aren't as easily found in the documentation.

I don't think I've ever stated it about the std::string is particular, but I would love the STL to be derivable friendly.

This makes me wonder. Have you considered that the member functions of mystring are just as difficult, if not more so, to find for the std::string-user as free functions?

No, not really. It just seems an advantage to me putting them in the same place.

Originally Posted by cpjust

BTW Elysia, rather than creating a new string class (since we already have so many to choose from), why not create some string algorithms and put them in a StrUtils namespace like I did.
That way, a few years from now, if you decided you don't like CString anymore and want to use std::string, you can still use all those string algorithms on the other string classes.
The syntax might be a bit uglier, but you can write things like:

Code:

StrUtils::ToUpper( str.begin(), str.end() );

To convert the string (whatever its type may be) into upper case.

Sure, I'm working on trying to rip out all those functions into a namespace, say, Strings::Mainpulation (could use some work on that name). But I will still keep the members as wrappers.
But even so, right now I'm working on something even more intriguing which actually might (or might have) benefited the standard library.

Right now, I'm fixing up my range iterator. On the outside, it's just a normal iterator, but on the inside, it's not a single pointer or single address or single element, but rather a range.
What might this be good for, you ask? It can specify a range and emulate that range as a single object.
I was thinking of a new implementation of Find.
Basically, you call find to find a word (no range or anything), and it will return a Result class.
The result class have several member to control and attain the data you want. For example, say you seek for "is" in "This is very fun it is". The class would have some functions such as Next, which would set the internal state to the next position where "is" was found. Previous goes backwards. If you want, you can just call Get to get a range (or the entire string) of where the "is" are.
So say you get position 1 where "is" was encountered. It would return a range iterator that emulates the range 6 to 7 in the string. If you do *, it would return a std::string with your data. And if you try to assign it, you could easily replace that "is" with something else, even if longer.
Something like:

Code:

Strings::CStringEx MyStr = "This is a test";
Strings::SerachResult search_result = MyStr.Find("is");
Strings::CStringExItRange it = search_result.GetFirst();
cout << MyStr << endl; // Prints "This is a test"
cout << *it << endl; // Prints "is"
*it = "is not";
cout << *it << endl; // Prints "is not"
cout << MyStr << endl; // Prints "This is not a test"
search_result = MyStr.Find("not ");
MyStr.Erase( search_result.GetFirst() );

It's a very cool concept that might actually have a lot of uses.
But even being able to sort, and mess around with your results after Find is even better - more control which could be added for any string class. These are all members, but could be broken out to free functions.

O_o

I think you'll have to find some other name; what you describe is very definitely not a range iterator, but is instead a kind of insertion iterator; then, 'range_inserter' is probably a good name.

But even so, right now I'm working on something even more intriguing which actually might (or might have) benefited the standard library.

The STL already supports this goal by providing many generic functions. You only need a better interface--because as I've said, it can be verbose.

The code I provided below should work, but it isn't tested either.

Edit: In retrospect, the container type should be a required template parameter--not derived from a function parameter. With this is mind the function could take the target contents as a range, as for the old and new contents, and return an iterator to the last element yielding the much more sophisticated:

Code:

my_container_instance.erase(replace_range<my_container_type>(my_container_instance.begin(), my_container_instance.end(), old_contents.begin(), old_contents.end(), new_contents.begin(), new_contents.end()), my_container_instance.end());

Which has the bonus of allowing 'replace_range_all' to be written quite simply.

Soma

Code:

#include <algorithm>
#include <iostream>
#include <iterator>
#include <string>

template
<
  typename element_F
>
struct rollover
{
  element_F operator ()
  (
    const element_F & value_f
  )
  {
    return(value_f);
  }
};

template
<
  typename element_F
>
struct rollover_left
{
  element_F operator ()
  (
    const element_F & value_f,
    const element_F & ignored_f
  )
  {
    return(value_f);
  }
};

template
<
  typename element_F
>
struct rollover_right
{
  element_F operator ()
  (
    const element_F & ignored_f,
    const element_F & value_f
  )
  {
    return(value_f);
  }
};

template
<
  typename container_F
>
void replace_range
(
  container_F & container_f,
  const typename container_F::const_iterator old_contents_beginning,
  const typename container_F::const_iterator old_contents_ending,
  const typename container_F::const_iterator new_contents_beginning,
  const typename container_F::const_iterator new_contents_ending
)
{
  const typename container_F::difference_type old_contents_size(std::distance(old_contents_beginning, old_contents_ending));
  const typename container_F::difference_type new_contents_size(std::distance(new_contents_beginning, new_contents_ending));
  if(old_contents_size >= new_contents_size)
  {
    typename container_F::iterator modifier(std::search(container_f.begin(), container_f.end(), old_contents_beginning, old_contents_ending));
    typename container_F::iterator container_cursor(std::transform(new_contents_beginning, new_contents_ending, modifier, rollover<typename container_F::value_type>()));
    std::advance(modifier, new_contents_size);
    std::advance(container_cursor, old_contents_size - new_contents_size);
    container_f.erase(std::copy(container_cursor, container_f.end(), modifier), container_f.end());
  }
  else
  {
    typename container_F::iterator container_cursor(std::search(container_f.begin(), container_f.end(), old_contents_beginning, old_contents_ending));
    container_cursor = std::transform(old_contents_beginning, old_contents_ending, new_contents_beginning, container_cursor, rollover_right<typename container_F::value_type>());
    std::insert_iterator<container_F> modifier(container_f, container_cursor);
    typename container_F::const_iterator replacement_cursor(new_contents_beginning);
    std::advance(replacement_cursor, old_contents_size);
    std::copy(replacement_cursor, new_contents_ending, modifier);
  }
}

int main()
{
  std::string message("This is a test.");
  std::string is(" is ");
  std::string correction(" is not ");
  replace_range(message, is.begin(), is.end(), correction.begin(), correction.end());
  std::copy(message.begin(), message.end(), std::ostream_iterator<std::string::value_type>(std::cout, ""));
  std::cout << '\n';
  replace_range(message, correction.begin(), correction.end(), is.begin(), is.end());
  std::copy(message.begin(), message.end(), std::ostream_iterator<std::string::value_type>(std::cout, ""));
  std::cout << '\n';
  return(0);
}

Originally Posted by phantomotap

I think you'll have to find some other name; what you describe is very definitely not a range iterator, but is instead a kind of insertion iterator; then, 'range_inserter' is probably a good name.

I don't know about that. It's an iterator alright. You can definitely view the current value, its keys (starting and ending), plus set it to something else, just as you can modify a normal iterator.
You should also be able to traverse using ++, --, etc, so I fail to see how it is anything but an iterator for a range of elements.

But that example of yours looks really complicated (like anything with a lot of templates aren't...), so I may have to look over it more properly at a later time.

Originally Posted by Elysia

It just seems an advantage to me putting them in the same place.

My point was that they're not.

It's a very cool concept that might actually have a lot of uses.

Oh, yes. It's also very similar to Boost.Tokenizer's token_iterator and Boost.Regex's regex_iterator and regex_token_iterator. Those aren't mutable, though.

It seems as if you're slowly getting the idea of generic programming.

Phantomatap, I believe in this case you have a very specific idea of what a range iterator is to you, but that doesn't mean Elysia's use of the word is incorrect.
It's not very useful, though.

See, Elysia, the problem with range_iterator is this: a range, in C++, is a sequence specified as a pair of iterators (to the first elements and past the last element). Because of this, every iterator iterates over a range, which makes the name range_iterator kinda superfluous.
A better name would be subrange_iterator, because its element type is a subrange of the range it traverses.

Originally Posted by CornedBee

See, Elysia, the problem with range_iterator is this: a range, in C++, is a sequence specified as a pair of iterators (to the first elements and past the last element). Because of this, every iterator iterates over a range, which makes the name range_iterator kinda superfluous.
A better name would be subrange_iterator, because its element type is a subrange of the range it traverses.

I think not quite. A range iterator should still be able to walk forwards/backwards, only not per element, as in a traditional iterator. Instead it treats a range as one element and it should be obvious by this since it emulates this behaviour by implementing two iterators to keep track of start and end.
In my previous search example, if we found two "is" in the strong, we could walk among those results via the operator by using ++/--. The only difference between the range iterator and a normal iterator here is that the range iterator treats the whole word "is" as one element, as opposed to a normal iterator which would treat individual characters as one element.

If I take the previous example:

Code:

Strings::CStringEx MyStr = "This is a test, that it is.";
Strings::SerachResult search_result = MyStr.Find("is");
Strings::CStringExItRange it = search_result.GetFirst();
cout << MyStr << endl; // Prints "This is a test, that it is."
cout << *it << endl; // Prints "is"
*it = "is not";
cout << MyStr << endl; // Prints "This is not a test, that it is."
it++;
*it = "is not";
cout << MyStr << endl; // Prints "This is not a test, that it is not."

It iterates through the found matches in this example, just as a normal iterator would, only it treats the range from the 'i' to 's' as a single element. This way it can be implemented in a more advanced way.

Phantomatap, I believe in this case you have a very specific idea of what a range iterator is to you, but that doesn't mean Elysia's use of the word is incorrect.

Yes, it does, or are you discounted all technical names/jargon? The phrase implies some very specific capabilities. If he said he was designing an interface for an iterator that only supported '++' but called it a random access iterator would you tell him to call it something else?

See, Elysia, the problem with range_iterator is this: a range, in C++, is a sequence specified as a pair of iterators (to the first elements and past the last element). Because of this, every iterator iterates over a range, which makes the name range_iterator kinda superfluous.

The problem with this entire idiotic comment becomes obvious if you had actually read what has been posted. That is, ignoring comments relating to the poor attempt at describing a range in terms of the word "sequence", your left with nothing I didn't say. I specifically told him not to call it a range iterator. What I suggested was 'range_inserter' implying an iterator using a insertion mechanic over a specific range regardless of the number of pre-existing elements.

A better name would be subrange_iterator, because its element type is a subrange of the range it traverses.

That would not be a better name for this. That probably implies something very specific as well, but I don't know what it would be. At the very least it would be called 'subrange_inserter'.

Instead it treats a range as one element and it should be obvious by this since it emulates this behaviour by implementing two iterators to keep track of start and end.

Ah, in that case, you do want a range iterator. I misunderstood the intent of your illustrative source. Sorry.

Ah, nope... you are still talking about inserting additional contents back in to the original container.

Soma