-
January 20th, 2015, 04:58 AM
#16
Re: [RESOLVED] map iterators
Originally Posted by jwbarton
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 ...
-
January 20th, 2015, 05:32 AM
#17
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)
-
January 20th, 2015, 05:45 AM
#18
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 ?
-
January 20th, 2015, 06:35 AM
#19
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)
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|