Thread: Though implementation problem

Can you tell me why (2) is better than (1)?

Personally, I find it better because of a change in thought pattern. With a loop, I am inclined to think about how the loop works. With the application of such a generic algorithm, I am inclined to think about the range that is being processed. In this case the code happens to be shorter too, but if you write out a function object separately that would not be the case.

(2) Requires so much understanding of underground stuff! Whereas for ( ; ; ) is known to every C++ beginner!?

That should not be a concern though: the question is whether the code would be easy to understand once one understands the constructs.

If you don't mind me asking, I was going to ask:
The function Find is const because it does not change the class data, but it returns a non-const iterator, allowing the data later to be changed. Am I to interpret that Find should not be const or should I circumvent this?

I get issues either way.
If it's const, then, I cannot do:

Code:

if (uint32_t(pEnd - pStart) < nFindLength) return end(); //iterator(this, m_pUnusedStart);

But if it isn't const, then, this will fail (another function):

Code:

nIndex = strToSplit.Find(strSplitWhat, nLastIndex);

strToSplit is:

Code:

const Strings::CStringEx& strToSplit

So the problem is that if I remove the const, that line won't work. I have to remove const from the reference. And that, in turns, means that I cannot pass a regular string into the function, because that won't break the const only rule for references.

Any ideas?

The function Find is const because it does not change the class data, but it returns a non-const iterator, allowing the data later to be changed. Am I to interpret that Find should not be const or should I circumvent this?

I think there should be two versions of Find. One should be a const member function that returns a const iterator, the other should be a non-const member function that returns a non-const iterator.

Hmmm.
Does that mean that an "internal" replace must return an integer or perhaps a pointer to the buffer instead of an iterator, then...? Seeing as I cannot call a non-const function from a const function and I cannot assign a const iterator to a non-const iterator.

One more thing, though. If the function was to be separated (ie free), then how would you go about it, since it needs an "internal" function that should not be called directly.

Code:

	template<typename StrType> void Replace(const StrType& strSrc, const StrType&
		strReplaceWhat, const StrType& strReplaceWith);
	//template<typename StrType, typename ItType> void Replace(const StrType&
		strReplaceWhat, const StrType& strReplaceWith, const ItType& vStart);
	template<typename StrType, typename ItType> void Replace(const StrType& strSrc,
		const StrType& strReplaceWhat, const StrType& strReplaceWith, const ItType& vStart, 
		const ItType& vEnd);
	// NOT TO BE CALLED DIRECTLY
	template<typename StrType, typename ItType> int32_t ReplaceInternal(const StrType&
		strSrc, const StrType& strReplaceWhat, const StrType& strReplaceWith, bool bReplace, 
		const ItType& vStart, const ItType& vEnd);

Am I just supposed to do that or go about it another way?

Originally Posted by manav

Have you thought, why you are having so many problems?
You are constantly being bitten by how-to-do-it-in-C++!
Later on poor users of your class may be wondering how-to-use-it-in-my-program?

Don't be silly. I'm trying to make it as easy as possible.
For example:

Code:

void foo(std::string& mystr) { }
void foo2(const std::string& mystr) { }
int main()
{
    foo("test"); // Won't work
    foo2("test"); // Will work
}

Returning an iterator, for example, allows you to do all kinds of fun manipulations very easily.

Originally Posted by manav

I guess, either you do not know enough C++ to do this

Don't be silly. Of course I know ways around it, but I was asking for advice.

Originally Posted by manav

...OR, C++ is so much of a Language, that no body, except Him, knows it well! *_*

Screw that religion. It annoys me.

One more thing, though. If the function was to be separated (ie free), then how would you go about it, since it needs an "internal" function that should not be called directly.

If it needs access to the internals then it should be a member or a friend. But since it does not need to be a member, it should be a friend. That said, it crosses my mind that it need not access the internals to begin with: the problem is one of finding a subrange in some range, so if you have the begin and end iterators of the range, and the begin and end iterators of the subrange, you can solve the problem. The std::search generic algorithm already solves this, so you just need to write a function to use it.

Originally Posted by manav

I was just a little concerned! Guess what, I know you know C++, hundred times more than I know! And I never had to use whatever you are using, even when it is almost a year, since I am working on this C++ project!

I'll let you use a prototype once I get it in working order!
We'll see how easy you think it is to use!

I was not giving you advice, I was just wondering, that, if *you* are confused, what will happen to me, when I have to code it?!?

Your comments don't do justice to your thoughts, really.
You will face these problems too, eventually. And you will struggle. But eventually you will learn.

Him - Bjarne

Err OK, that really sounded unambiguous. I take back my comment, then.

Originally Posted by laserlight

If it needs access to the internals then it should be a member or a friend. But since it does not need to be a member, it should be a friend. That said, it crosses my mind that it need not access the internals to begin with: the problem is one of finding a subrange in some range, so if you have the begin and end iterators of the range, and the begin and end iterators of the subrange, you can solve the problem. The std::search generic algorithm already solves this, so you just need to write a function to use it.

I think you misunderstood that one.
The "internal" replace as you see requires more arguments (especially the bool) then the "normal" Replace. The "normal" replace comes in two variants and is supposed to be the public interface. It will do whatever is necessary and call the "internal" function.
With classes, I could hide the internal function, but if Replace is free, then I can't hide that internal function. It shouldn't be called directly, so I was wondering the best way of doing it? Should I just let it lie there or put it in a private header or so?

I think you misunderstood that one.
The "internal" replace as you see requires more arguments (especially the bool) then the "normal" Replace. The "normal" replace comes in two variants and is supposed to be the public interface. It will do whatever is necessary and call the "internal" function.

Actually, I am a little confused because you were talking about Find, but now you are talking about Replace

With classes, I could hide the internal function, but if Replace is free, then I can't hide that internal function. It shouldn't be called directly, so I was wondering the best way of doing it?

If that is the situation, then Replace should be a member function.

Originally Posted by laserlight

Actually, I am a little confused because you were talking about Find, but now you are talking about Replace

Uhh ya, looking back, I can see why...
Find had the const or not const iterator problem.
Replace was broken out and have the private interface problem.

If that is the situation, then Replace should be a member function.

I mean, currently it looks like:

Code:

	template<typename StrType> void Replace(const StrType& strSrc,
		const StrType& strReplaceWhat, const StrType& strReplaceWith)
	{
		Replace(strSrc, strReplaceWhat, strReplaceWith,
			strReplaceWhat.begin(), strReplaceWhat.end());
	}
	//template<typename StrType, typename ItType> void Replace(const
		StrType& strReplaceWhat, const StrType& strReplaceWith, const ItType& vStart);
	template<typename StrType, typename ItType> void Replace(const StrType& strSrc,
		const StrType& strReplaceWhat, const StrType& strReplaceWith, const ItType& vStart, 
		const ItType& vEnd)
	{
		int32_t nNeededSize = ReplaceInternal(strSrc, strReplaceWhat, strReplaceWith, false,
			vStart, vEnd);
		if (nNeededSize > 0) strSrc.resize(nNeededSize); //PrepareBuffer(nNeededSize);
		ReplaceInternal(strSrc, strReplaceWhat, strReplaceWith, true, vStart, vEnd);
	}

	template<typename StrType, typename ItType> int32_t ReplaceInternal(const StrType& strSrc,
		const StrType& strReplaceWhat, const StrType& strReplaceWith, bool bReplace,
		const ItType& vStart, const ItType& vEnd)

Replace is the public interface of the free function that you should call to do the work.
Then they will wrap ReplaceInternal that will do the actual replacing.
But ReplaceInternal shouldn't be called directly because 1) it takes a bool that should not be passed directly and 2) it has only one version - the one that takes a range. Therefore ReplaceInternal should be hidden away from prying eyes, but since it's free it cannot.
But making it a member will destroy the essence of generic functions...
Unless ReplaceInternal can wrap other generic functions to do its work. Perhaps that might be a good idea? Then ReplaceInternal could be made a member.

No, it's not the interface per se that's the problem, but the internal mechanisms.
And it should be Replace(What, With, Start, End).