CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 19 of 19
  1. #16
    Join Date
    Oct 2008
    Posts
    1,456

    Re: [RESOLVED] map iterators

    Quote Originally Posted by jwbarton View Post
    There is another problem with using the default initialization[...]
    you're totally right , actually my reasoning in my last post just implies that IF the comparison is well defined ( the standards says, "it's in the == domain" ) THEN it must follows that the singular iterator will not compare equal to map::end(). Unfortunately, this is of little help ...

    so, @2kaud, your current solution is not correct ...

  2. #17
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: [RESOLVED] map iterators

    I'm not checking the singular iterator equal to map::end(). The revised code from my post #1 is

    in a header file
    Code:
    ...
    class PROGLIBSPEC cOpts {
    private:
    	//Type defs for map
    	typedef std::map<cStr, cStr> TOPT;
    	typedef TOPT::const_iterator OPTITER;
    
    	TOPT	 optns;
    
    	OPTITER	 piter;
    
    public:
    
    	//Default constructor
    	cOpts()  {
    		piter = OPTITER();
    		optns.clear();
    	}
    ...
    in a .cpp file
    Code:
    ...
    	//Has GetFirst been done first
    	if (piter == OPTITER()) {
    		return (GetFirst(name));
    	}
    ...
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  3. #18
    Join Date
    Oct 2008
    Posts
    1,456

    Re: [RESOLVED] map iterators

    it's still wrong, the line

    Code:
    if (piter == OPTITER()) {
    will evaluate to true if piter is set to OPTITER()
    but, it will evaluate to false IF it was set to any other map instance iterator AND the comparison is well defined, UB otherwise. The problem is that, unless I'missing something ( again ), there's no guarantee that such a comparison is well defined or not. BTW, did you run the code with checked iterators turned on in order to confirm jwbarton's observation ?

  4. #19
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: [RESOLVED] map iterators

    piter is set to OPTITER() in the class constructor. GetFirst(name) sets piter to optns.begin(). OPTITER() is not equal to any xxx.begin(). So the test for piter == OPTITER() will be true only the first time that condition is evaluated and false every other time - which is the required behaviour just replacing NULL with OPTITER() in my original code in post #1.

    As I've already mentioned, I don't like this code and it and other issues arising from the change from vc2003/vc6 to vc2013 have already been flagged for code review and rewrite which could well involve changes to the class interfaces and usage.

    What the current classes like this have is essentially
    Code:
    myclass
    {
    public:
         myclass();
         retval = myclass.first();
         retval = myclass.next();
    }
    where .first() will return the first element (and set an iterator to .begin()) and .next() will return the next element or an special value to indicate no more elements (ie .end() reached). The issue arising from the discussions in this thread is that if .next() is called in the code using this class without .first() having been called then .next() needs to first call .first() to ensure that private elements of the class are initialised properly. The class interface documentation states that .first() should always be called before .next() is used but sometime over the previous 15-odd years some one hasn't liked that and changed .next() so that it will call .first() if .first() hasn't been explicitly already called - so that the code that uses these classes doesn't have to first call .first() but can just use .next(). We've looked at the code that uses these classes and some follow the interface documentation calling .first() before .next() is called but there is substantial code that just uses .next() assuming .first(). Doh!

    This whole code base is now being reviewed to establish the way forward to bring it into the 'modern' c++11/14 arena.
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured