On Sat, Oct 3, 2009 at 8:49 PM, Antoine Labour <[email protected]> wrote:
> On Sat, Oct 3, 2009 at 4:25 PM, Peter Kasting <[email protected]> wrote: > >> You're missing the point. >> > > I don't think I am. > I'm just trying to help... I've encountered this situation many times, with > the same exact behavior, I'm trying to tell you all I know about it, > teaching you how to fish. But maybe I don't express myself clearly. > OK. I have hit this a number of times too -- in fact, enough to have looked up the defect report the C++ Standards Committee has on this issue (the intent of the spec was to not require storage in such cases, which they intend to rectify, presumably in C++0x). I had just never had it happen to me in this sort of a flaky way -- normally compilers are more consistently petulant :). Like I said "The compiler may be able to get away with things if it doesn't > need the actual storage for the value" which explains why the previous code > didn't have the issue - it was just using the value, not the storage. As > Jacob points out, the implementation of DCHECK_NE needs the storage. > Yep. I had a hard time tracing this down over remote desktop from this Mac that I can't seem to get used to. Thanks to Jacob for the solid investigation. > The storage declaration is missing, or at least isn't in > blocked_popup_container.cc where it belongs. Beware of simply adding it > without an ifdef though, because in my experience MVSC doesn't like it. > I'll tread carefully. In the past I'm pretty sure I've been able to get MSVC to accept this kind of thing. Thanks for the cautionary words, PK --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
