By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,486 Members | 1,589 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,486 IT Pros & Developers. It's quick & easy.

STL set broken?

P: n/a
Hello,

I am using the std::set from the standard template
library, and it seems that it is broken. I've tried
both the MS version as well as the g++ version and I
get the same bug in both version.

As I fill the set with more and more ints, it suddenly
seems to reset itself. Here is some sample output of
the number of items in the set:

18317
30483
38315
43175
46061
47685
48539
48950
49125
49187
49203
49205
49205
18317 *** ???
30483
38315
43175

Is this a documented bug in stl? Is there something
I may be doing which breaks it? I am only using the
insert and size methods of a simple std::set<int> object.

- Andrew

--
http://www.headsupclub.com/aprock/
Nov 22 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
A. Prock wrote:
Hello,

I am using the std::set from the standard template
library, and it seems that it is broken. I've tried
both the MS version as well as the g++ version and I
get the same bug in both version.

As I fill the set with more and more ints, it suddenly
seems to reset itself. Here is some sample output of
the number of items in the set:

[snip]

Is this a documented bug in stl? Is there something
I may be doing which breaks it? I am only using the
insert and size methods of a simple std::set<int> object.


The fact that your code breaks in the same way with two completely
different implementations of the STL indicates that almost certainly the
bug is in your code. Post the code.

john
Nov 22 '05 #2

P: n/a

"A. Prock" <pr*******@pokerstove.com> wrote in message
news:43**********************@spool.cs.wisc.edu...
| Hello,
|
| I am using the std::set from the standard template
| library, and it seems that it is broken. I've tried
| both the MS version as well as the g++ version and I
| get the same bug in both version.
|
| As I fill the set with more and more ints, it suddenly
| seems to reset itself. Here is some sample output of
| the number of items in the set:
|
| 18317
| 30483
| 38315
| 43175
| 46061
| 47685
| 48539
| 48950
| 49125
| 49187
| 49203
| 49205
| 49205
| 18317 *** ???
| 30483
| 38315
| 43175
|
| Is this a documented bug in stl? Is there something
| I may be doing which breaks it? I am only using the
| insert and size methods of a simple std::set<int> object.
|

Why should the std::set be broken if in fact the above code indicates
that the std::set container is correctly storing the dataset? Or are you
suggesting that the STL should prevent iterating through a container
more than once?

Have you even a clue how many folks have developed and tested the
various STL containers over the last 2 decades? And i've yet to find any
fundamental flaw in any of these yet.

Let me put it to you this way, if i pass a container by value, then add
elements to the original container, wouldn't it be in fact undefined
behaviour if the local container was to somehow include the new data
that is being added elsewhere?
Nov 22 '05 #3

P: n/a
A. Prock wrote:
Hello,

I am using the std::set from the standard template
library, and it seems that it is broken. I've tried
both the MS version as well as the g++ version and I
get the same bug in both version.
When something like that happens, you should always first assume that your
program contains the error, not the compiler or standard library. Remember
that those are often tested extensively. Of course, there are also bugs in
that software, but it is very unlikely that two separate implementations
contain the exact same bug _and_ that nobody noticed it yet.
As I fill the set with more and more ints, it suddenly
seems to reset itself. Here is some sample output of
the number of items in the set:

18317
30483
38315
43175
46061
47685
48539
48950
49125
49187
49203
49205
49205
18317 *** ???
30483
38315
43175

Is this a documented bug in stl?
What exactly is "this"? I mean, where is the code that produced that? Show
it. Maybe your code is erroneous.
Is there something I may be doing which breaks it?
How would anyone here know?
I am only using the insert and size methods of a simple std::set<int>
object.


And how was that output then produced?

Nov 22 '05 #4

P: n/a

"A. Prock" <pr*******@pokerstove.com> wrote in message
news:43**********************@spool.cs.wisc.edu...
Hello,

I am using the std::set from the standard template
library, and it seems that it is broken. I've tried
both the MS version as well as the g++ version and I
get the same bug in both version.

As I fill the set with more and more ints, it suddenly
seems to reset itself.
What do you mean 'reset'? Does its size become zero?
Here is some sample output of
the number of items in the set:

18317
30483
38315
43175
46061
47685
48539
48950
49125
49187
49203
49205
49205
18317 *** ???
30483
38315
43175
I'll take a wild guess here. Are you believing that
you should have more than one instance of the same
value in a 'std::set'? This container by definition
does not allow duplicates. If you want duplicates,
use 'std::multiset'.


Is this a documented bug in stl?
Is what a bug?
Is there something
I may be doing which breaks it? I am only using the
insert and size methods of a simple std::set<int> object.


No way to tell without seeing the exact code which produces
the 'problem.'

-Mike
Nov 22 '05 #5

P: n/a
According to John Harrison <jo*************@hotmail.com>:
The fact that your code breaks in the same way with two completely
different implementations of the STL indicates that almost certainly the
bug is in your code. Post the code.


Nothing like someone stating the obvious to lead
you directly to the solution. The code which created
sets was wrapped in a loop. So the sets were never
getting smaller (something which I was looking for
explicitly), they just were new instances.

Thanks,

- Andrew

--
http://www.headsupclub.com/aprock/
Nov 22 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.