Though implementation problem

This is a discussion on Though implementation problem within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by phantomotap It is nonsense. 1): Nothing is stopping them from supporting C and C++ correctly. 2): As ...

  1. #241
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    Quote Originally Posted by phantomotap View Post
    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
    Last edited by Elysia; 05-18-2008 at 09:31 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #242
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    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.
    This is getting very tiresome. That the headers use extensions is a nonsense reason to not error on code that is an error. As I've said, twice, they use 'pragma' everywhere to turn off and on other warnings and errors. They already use 'pragma' to protect the headers from raising warnings and errors that the compiler does care about.

    Soma

  3. #243
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #244
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    And yet the headers won't compile with language extensions OFF.
    Which is a nonsense reason for the compiler to not raise an error on code that is an error.

    And that is all we care about.
    I don't care about it at all. I don't use the Microsoft headers even when I use the Microsoft compiler. I do care about my source being valid and sound. I expect the compiler to raise an error regarding invalid code.

    If it can't compile them without extensions, then the headers are flawed, because they aren't standard compliant are they?
    As I've said, thrice, they use 'pragma' everywhere to turn off and on other warnings and errors. The headers do depend on some extensions, but so what? That doesn't change the fact that the compiler is allowing nonconforming code a pass.

    Soma

  5. #245
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #246
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #247
    The larch
    Join Date
    May 2006
    Posts
    3,573
    What about this?
    Code:
    Find(const CStringEx& strFind, unsigned nPos)
    {
         CIterator vIter(nPos, this);
         ...
    }
    With an overload for passing a CIterator...
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  8. #248
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #249
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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?
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  10. #250
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #251
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.)
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #252
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    That would throw an exception.
    Code:
    if ( !vStart.valid_instance(strSrc) || !vEnd.valid_instance(strSrc) )
    	throw errInvalidIterator;
    No more undefined.
    Last edited by Elysia; 05-20-2008 at 05:04 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #253
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    Why not design the container/iterator model up such that the validate method is part of the iterator class? With such a design the validate method could examine the state of iterator for correctness and optionally update the owning container of the iterator if it was spawned from such constructs as this implicit conversion constructor.

    Soma

  14. #254
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #255
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    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...
    Last edited by Elysia; 05-25-2008 at 08:24 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 07:54 PM
  2. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 06:24 PM
  3. implementation file
    By bejiz in forum C++ Programming
    Replies: 5
    Last Post: 11-28-2005, 01:59 AM
  4. Replies: 5
    Last Post: 11-07-2005, 11:34 PM
  5. Memory Problem - I think...
    By Unregistered in forum C Programming
    Replies: 4
    Last Post: 10-24-2001, 01:14 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21