On Saturday, November 3, 2012 2:20:59 PM UTC-7, Justin Lebar wrote:
> > Since you can't refer to anonymous-namespace symbols at all in the Visual
> > Studio debugger...
>
> Are there compiler annotations we could put on a class so that it
> behaves as though it's in an anonymous namespace but also
On 2012-11-21 12:06 AM, Robert O'Callahan wrote:
I don't know how to set breakpoints by
name on methods of CSSParserImpl, which is in a toplevel anonymous
namespace. Nor can I cast to a CSSParserImpl* in the expression evaluator.
Note that this is the situation where 'static' cannot be used as
On Wednesday, November 21, 2012 12:06:32 AM UTC-5, Robert O'Callahan wrote:
> On Wed, Nov 21, 2012 at 4:07 PM, wrote:
>
> Actually that seems quite easy. For example in FrameLayerBuilder.cpp I can
> add gMaskLayerImageCache to the watch window with no problems, even though
> it's in mozilla::{ano
On Wed, Nov 21, 2012 at 4:07 PM, wrote:
> In VS2010 you can have symbols in your watch window that are in an
> anonymous namespace and you can put breakpoints on them. For example:
>
> namespace {
> int g = 42;
> }
>
> In your Watch window, add g, and you can see 42.
>
> If you have an anonymo
That's not exactly correct.
In VS2010 you can have symbols in your watch window that are in an anonymous
namespace and you can put breakpoints on them. For example:
namespace {
int g = 42;
}
In your Watch window, add g, and you can see 42.
If you have an anonymous namespace inside of anothe
On Wed, Nov 21, 2012 at 3:19 PM, wrote:
> Maybe there's a specific case where you can reproduce this, but in general
> I've always been able to set breakpoints in unnamed namespaces.
> I've tested just now with a simple app in VS2008, VS2010 and VS2012. And
> on those debuggers it works fine.
>
> Even worse, in Visual Studio 2010 (not sure about 2012),
> you can't set a breakpoint on an anonymous-namespace symbol
> *at all*. And we can't submit patches to fix that, either :-).
Maybe there's a specific case where you can reproduce this, but in general I've
always been able to set break
Following our discussion here and in the weekly platform team call, I've
gone ahead and altered the C++ style guide to note that we now prefer
'static' to anonymous namespaces (except for cases that can't be covered
by 'static').
https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_
>> Are there compiler annotations we could put on a class so that it
>> behaves as though it's in an anonymous namespace but also plays nicely
>> with the debugger? If so, maybe we should switch to those.
>
> Sure: "static" :)
/on a class/?
(I thought the main point of anonymous namespaces was
On 11/03/2012 02:20 PM, Justin Lebar wrote:
Are there compiler annotations we could put on a class so that it
behaves as though it's in an anonymous namespace but also plays nicely
with the debugger? If so, maybe we should switch to those.
Sure: "static" :)
Jason
___
> Since you can't refer to anonymous-namespace symbols at all in the Visual
> Studio debugger, it also means you can't evaluate an expression containing a
> cast to an anonymous-namespace class. That can also be a real pain, and
> there's no workaround AFAIK.
Wow. MSDN provides a possible work-ar
On Sun, Nov 4, 2012 at 2:24 AM, Justin Lebar wrote:
> > Even worse, in Visual Studio 2010 (not sure about 2012), you can't set a
> > breakpoint on an anonymous-namespace symbol *at all*. And we can't submit
> > patches to fix that, either :-).
>
> Not even by opening the file and clicking to the
On Sat, Nov 3, 2012 at 8:59 AM, Jason Duell wrote:
> I see an increasing number of patches using anonymous namespaces instead
> of 'static'. This is debugger unfriendly: setting a breakpoint in gdb
> for 'foo' in an anonymous namespace requires the following syntax:
>
> b (anonymous namespac
On Sat, Nov 3, 2012 at 10:59 AM, Justin Lebar wrote:
>
>>It also obfuscates the visibility of the identifier,
>
> That's a problem with namespaces in general. Do you have a reason we
> should use namespaces but shouldn't use anonymous ones (except where
> we have to), or is the argument for limit
> [It's annoying to do]
>
> b (anonymous namespace)::foo
>
> (If there's a less verbose way of doing this, please let me know.)
Does that even work if you're not inside the file which contains
foo()? I'd be impressed...
I almost always do
(gdb) b Foo.cpp:123
because that's the only thing wh
On Sat, Nov 3, 2012 at 6:59 AM, Jason Duell wrote:
> I see an increasing number of patches using anonymous namespaces instead of
> 'static'. This is debugger unfriendly
It also obfuscates the visibility of the identifier, because the
|namespace {| is often far from the identifier. This is part
I see an increasing number of patches using anonymous namespaces instead
of 'static'. This is debugger unfriendly: setting a breakpoint in gdb
for 'foo' in an anonymous namespace requires the following syntax:
b (anonymous namespace)::foo
(If there's a less verbose way of doing this, plea
17 matches
Mail list logo
