lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] still MSVC compilation problems


From: Greg Chicares
Subject: Re: [lmi] still MSVC compilation problems
Date: Tue, 24 Jun 2008 13:20:48 +0000
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)

On 2008-06-24 12:09Z, Vadim Zeitlin wrote:
> On Tue, 24 Jun 2008 11:59:02 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> > Also, placeholder is a private class (and IMO should be
> GC> > defined inside some "namespace Private" or "namespace impl") so the 
> unsafe
> GC> > "void *get()" shouldn't be used from anywhere else.
> GC> 
> GC> I know boost does that frequently, and I even copied their
> GC> practice for a while. But I just don't see how this makes
> GC> anything really safer: one can so easily write 'impl::get()'.
> 
>  Well, you've surely heard this argument already but the standard
> explanation is that when we try to make the code safe we don't really fight
> against somebody determined to write wrong code because this fight is lost
> in advance, but just against someone who could be honestly mistaken.
> Putting a function in a "Private" namespace clearly shows to any
> well-intentioned person that it's not supposed to be used from the outside.

Thanks for recapitulating that for me. I still think an innocent,
well-intentioned bumbler could write "Private::" before a function
call, just because "it makes an error message go away": a magical
technique that could be stumbled upon via google, say. One might
hope they'd look inside the header first, but they might answer
"I just copied this code from somewhere, and it 'works'".

To me, that's another reason for using pointers-to-member that no
such person is ever going to understand. "I couldn't figure out
what '->*' means--templates, I guess--but I saw a void* function,
so I tried to call it...but it only works for msvc so I give up":
that's what I want to hear.

> GC> > GC> >  Finally, I still have unit test failures after this change:
> GC> > GC> [...]
> GC> > GC> > but they seem to be due to the difference between the expected 
> and real
> GC> > GC> > value of std::type::info::name() so I think I should just add 
> tests for
> GC> > GC> > MSVC into any_member_test.cpp along the existing tests for g++ 
> version. Do
> GC> > GC> > you see anything wrong with this?
> GC> > GC> 
> GC> > GC> Nothing wrong with that. Testing the value of 
> std::type::info::name()
> GC> > GC> is fragile, but we're already doing it for other compilers, and I'd
> GC> > GC> rather not spend time thinking about removing that fragility right 
> now.
> GC> > 
> GC> >  In fact I think it's easy enough to remove this fragility: instead of
> GC> > hardcoding the results of std::type_info::name() in the test code we 
> could
> GC> > construct the string dynamically using lmi::TypeInfo(). Then there 
> would be
> GC> > no need for any compiler [version] tests.
[...]
>  Here it is. I didn't test this with old g++ yet but it does work (i.e. the
> test passes) with g++ 4.1 and MSVC.

It works with MinGW gcc-3.4.4, too. Could I ask you to write a
similar patch for 'safely_dereference_as_test.cpp', which has
the same fragility?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]