Thread: Though implementation problem

Originally Posted by phantomotap

It is nonsense.
1): Nothing is stopping them from supporting C and C++ correctly.
2): As I've said, they use 'pragma' everywhere to turn off and on other warnings and errors.

2) It still won't compile without extensions added, so it's not nonsense.
Besides, the headers use a lot of things like re-define of defines (without #undef first). Regardless if it ignores this or not, it's not allowed. If extensions are disabled, you get compile errors.

Code:

#define __$adt_prop(adt,prop)

2>d:\program\microsoft sdks\windows\v6.0a\include\specstrings.h(171) : error C2008: '$' : unexpected in macro definition

And yet the headers won't compile with language extensions OFF. And that is all we care about.
If it can't compile them without extensions, then the headers are flawed, because they aren't standard compliant are they?

Well, we obviously have different views or do not understand each other, so I'll leave it at that. I have no further wish to argue.

Another question I'm thinking on:
Say that CIterator takes a constructor with int:
CIterator(int)
This is not enough information to properly construct the iterator, however. Therefore, it would want to ask the owner class to which it belongs or is constructed for for the rest of the information.
Typically, it would do this via the proxy:
m_pProxy->QueryRange(m_pRangeStart, m_pRangeEnd);
However, since it's newly constructed, it doesn't have the owner class address or a valid proxy pointer, so it can't really do much.

Now the question becomes - is it possible, then, to somehow pass along the address for the class for either the correct proxy instance or the owner class?
The reason is that the int constructor is supposed to be an implicit constructor to should allow this:

CStringEx test = "test";
test.Find("test", 0);

Find's prototype would be:

Find(const CStringEx& strFind, CIterator vStart);

This would invoke the int constructor for CIterator for int. The constructor would then set itself to test.begin() + n.
But I can't seem to find a viable solution for the iterator to get the address the owner class so as to be able to make this possible.

Is it perhaps just too much of a hassle to make it possible?

What about this?

Code:

Find(const CStringEx& strFind, unsigned nPos)
{
     CIterator vIter(nPos, this);
     ...
}

With an overload for passing a CIterator...

That's one solution I didn't think of... it will probably mean two overloaded functions, but hey, who cares.
Suppose I'll do that unless I can find a better solution.
Thanks.

Code:

Find(const CStringEx& strFind, unsigned nPos)
{
     CIterator vIter(nPos, this);
     return Find(strFind, vIter);
}

Find(const CStringEx& strFind, CIterator vStart)
{
    ...
}

What happens if the passed iterator does not refer to this CStringEx?

The functions will always accept T::iterator.
Such as my current free Find function:

Code:

template<typename StrType> typename StrType::const_iterator Find(const StrType& strFind,
	const typename StrType::const_iterator& vStart, 
	const typename StrType::const_iterator& vEnd);

By using proper typedefs in the class, it will make sure that the iterator is compatible with the class.

But what if that iterator points into a different instance of StrType? That's what anon was asking.

(Of course, in the STL, that's simply undefined, but you're not a fan of undefined behaviour.)

That would throw an exception.

Code:

if ( !vStart.valid_instance(strSrc) || !vEnd.valid_instance(strSrc) )
	throw errInvalidIterator;

No more undefined.

The valid_instance function is part of the iterator class.
It takes a const reference to the base object to validate.
It uses its proxy to query which owning object it's bound against and compares the address of the passed argument. If they don't match, it returns false. In other words, if the object passed through reference is an instance that is not the instance of the owning object, it returns false.

New wonder:
I have the following free operator:

Code:

CTmplStringBaseTemplate CTmplStringBaseTmpl& operator +=
	(CTmplStringBaseTmpl& rlhs, const CTmplStringBaseTmpl& rrhs);

But if I try to call it through the code:

Code:

Strings::CStringExW test( L"test" );
test += L"This is a test";

I simply get an error:

Code:

error C2784: 'Strings::CTmplStringBase<T,Strings::StrTraits<T>> &Strings::operator +=
	(Strings::CTmplStringBase<T,Strings::StrTraits<T>> &,
	const Strings::CTmplStringBase<T,Strings::StrTraits<T>> &)' :
could not deduce template argument for
'const Strings::CTmplStringBase<T,Strings::StrTraits<T>> &'
from
'const wchar_t [15]'

I even tried changing the function to:

Code:

template<typename T> CTmplStringBase<T, StrTraits<T>>& operator +=
	(CTmplStringBase<T, StrTraits<T>>& rlhs,
	const CTmplStringBase<T, StrTraits<T>>& rrhs/*const T* strData*/);

Yet still refuses to work. But technically, it should, because the class has constructors (not-explicit) for the types:

Code:

CTmplStringBase();
CTmplStringBase(const CTmplStringBase& rSrc);
#ifdef _MFC_VER
CTmplStringBase(const CStringT< T, StrTraitMFC_DLL<T> >& strSrc);
#endif
CTmplStringBase(const T* strData);
CTmplStringBase(const T cData);
CTmplStringBase(uint64_t nData);
CTmplStringBase(int64_t nData);
CTmplStringBase(long nData);

So shouldn't it be able to create a temp object for the wchar_t* (using CTmplStringBase<wchar_t>) and then pass via a const reference?
I must be doing something wrong here...