microsoft.public.vc.stl Google Group

Re: std::set and std::multiset element mutability

2010-01-04T21:52:10Z

OK understood, thanks for clearing up the confusion. Btw, I enjoyed
reading your blog on the rvalue references and experimenting with them.
Hope you don't mind that I was using a different compiler for that :)

Re: std::set and std::multiset element mutability

2010-01-04T21:40:47Z

Actually, we're working with Dinkumware closer than ever before. During
VC8, Microsoft's sources diverged significantly from Dinkumware's master
sources. In VC10 we got back in sync. This, combined with the introduction
of many C++0x features like rvalue references, looks like a major rewrite of

Re: std::set and std::multiset element mutability

2010-01-04T20:14:07Z

Stephen,
So it's not Dinkum in VC10 anymore?

Re: std::set and std::multiset element mutability

2010-01-04T19:15:05Z

I built a time machine, so I answered your question over half a year ago:
[link]
(Note that #2 and #4 have been reversed.)
To add to the story very briefly:
Modifying set elements was always considered a squirreley thing to do, so

Re: catching push_back exception

2009-12-31T18:47:46Z

For me, your code eventually throws a bad_alloc exception which is successfully caught by the appropriate catch clause. How does your experience differ?
Do you have exception handling turned off, by any chance? Check Project | Properties | C/C++ | Code Generation | Enable C++ Exceptions.

catching push_back exception

2009-12-31T16:24:27Z

I tried your suggestion with the simple program above and it did not work. That is, I had:
for(theint=0; theint < 20000000000; theint++)
{
try
{
thevector.push_back(theint);
}
catch ( const std::bad_alloc & e )
{
return 0;
}
catch ( const std::exception & e )
{
return 0;
}
The program crashed (threw an exception) on the push_back(*) call. Am I missing something simple? Any idea why the exception would not be handled? BTW, the value of theint when it crashed was 67108864. Thanks.

Re: std::set and std::multiset element mutability

2009-12-25T17:10:02Z

Take a look at [link] if you like for my
full take on this.
/Leigh

Re: std::set and std::multiset element mutability

2009-12-24T16:57:17Z

I always think mutable is a bit of a hack as const setter functions seem
somehow dodgy to me, instead I have just written the following:
template <typename T, typename Pr = std::less<typename T::key_type const>,
typename Alloc = std::allocator<std::pair<typen ame T::key_type const, T> > >
class mutable_set : public std::map<typename T::key_type, T, Pr, Alloc>

Re: std::set and std::multiset element mutability

2009-12-23T12:39:53Z

Following code compiles on VC9 but not VC10:
class A
{
int m_n;
public:
A(int n):m_n(n){}
void Change(){m_n++;}
bool operator < (const A& rhs) const {return m_n < rhs.m_n;}
int main()
{
std::set<A> mySet;
A a(1);
mySet.insert(a);
mySet.begin()->Change();
return 0;
Error message on VC10 is
error C2662: 'A::Change' : cannot convert 'this' pointer from 'const A' to 'A &'

std::set and std::multiset element mutability

2009-12-23T01:55:15Z

VC9 allows you to modify a std::set and a std::multiset's elements. This
seems to be forbidden by the c++0x standard, so is this being fixed in VC10
or left as it is in order not to break software which is c++03 standard's
compliant (debatable) but not c++0x standard's compliant?
/Leigh

std::vector::reference ctor is not private

2009-12-14T00:43:19Z

In VC++2008 the std::vector<bool>::reference constructor is not private,
according to the standard it should be.
/Leigh

Re: vc 2010 beta2 bind unique_ptr move

2009-12-02T23:28:15Z

Although mechanics std::thread constructor and std::bind is similar, now
when you say it, yes contexts and definitely the purposes of std::bind
and std::thread are different. I'm no longer convinced that
specialization of std::bind for std::unique_ptr just for sake of
mimicking same behavior is a good idea.

Re: vc 2010 beta2 bind unique_ptr move

2009-12-02T21:58:18Z

That constructor is explicitly documented to support MoveConstructible arguments. The reason for the difference, I presume, is because thread is known to call its function object exactly once.
bind doesn't know that it's going to be called only once.

Re: vc 2010 beta2 bind unique_ptr move

2009-12-02T21:08:42Z

actually std::thread constructor led me to that
std::thread uses similar mechanism as bind, and it will be possible to
transfer ownership using:
std::thread thr(foo, std::move(pint));
where pint is instance of unique_ptr<int>
and I still think that this should be same as:
std::thread thr(std::bind(foo, std::move(pint)));

Re: vc 2010 beta2 bind unique_ptr move

2009-12-02T13:41:05Z

The functional produced by std::bind stores a copy of pint (which it can do using move constructor). Its operator() would then call foo(copy_of_pint). It doesn't know enough about its parameter to infer that it should use move() in this call. So this is the part that fails.
The (draft) standard requires that parameters of std::bind be CopyConstructible, which unique_ptr isn't. So your program is invalid.