Sizeof out of scope?
-
Can someone tell me how to use sizeof() during debugging by any means at all (watch, immediate window, etc...)? All I keep getting are stupid error messages. For instance, in the Immediate window I typed: ? sizeof(bool) which gave me the message error: identifier 'sizeof' out of scope I can't seem to find documentation for this anywhere. Thanks.
-
Can someone tell me how to use sizeof() during debugging by any means at all (watch, immediate window, etc...)? All I keep getting are stupid error messages. For instance, in the Immediate window I typed: ? sizeof(bool) which gave me the message error: identifier 'sizeof' out of scope I can't seem to find documentation for this anywhere. Thanks.
In C#, and in C++, sizeof is an operator, and not a function. It is something that is calculated at compile-time, and not at run-time. As such, the debugger does not know the sizeof operator, as it is a language-specific way of expressing an operator. The way your type your expression, the debugger will interpret it as: Call Debug.Print(sizeof(bool)) Since the sizeof function does not exist, you get an out of scope error message.
-
Can someone tell me how to use sizeof() during debugging by any means at all (watch, immediate window, etc...)? All I keep getting are stupid error messages. For instance, in the Immediate window I typed: ? sizeof(bool) which gave me the message error: identifier 'sizeof' out of scope I can't seem to find documentation for this anywhere. Thanks.
-
Can someone tell me how to use sizeof() during debugging by any means at all (watch, immediate window, etc...)? All I keep getting are stupid error messages. For instance, in the Immediate window I typed: ? sizeof(bool) which gave me the message error: identifier 'sizeof' out of scope I can't seem to find documentation for this anywhere. Thanks.
I have never done this before, but I'm going to have to disagree with nearly everything that has been put forth in the responses so far. I created a new scratch C++/CLI project to see if there was a problem in the way my other C++ project was configured. However, using sizeof in the Immediate window continues to produce the "out of scope" error. Then I created a new scratch C# project to put Michel's response to the test. When I type ? sizeof(bool) in the Immediate window, it returns an output of "1". So whatever is going on with "sizeof" in C++/CLI is not extendable to C#. Regarding Richard's comment about me calling the "out of scope" message stupid, I'm going to stand by what I said. "Sizeof" -- especially if Michel is right calling it an operator rather than a function -- is part of the language. It's not some custom function of some special class where an extra reference is needed. So how can it ever be out of scope? In that regard, the message makes no sense. Therefore it is utterly unhelpful. That makes it, IMHO, fully deserving of the label "stupid".
-
I have never done this before, but I'm going to have to disagree with nearly everything that has been put forth in the responses so far. I created a new scratch C++/CLI project to see if there was a problem in the way my other C++ project was configured. However, using sizeof in the Immediate window continues to produce the "out of scope" error. Then I created a new scratch C# project to put Michel's response to the test. When I type ? sizeof(bool) in the Immediate window, it returns an output of "1". So whatever is going on with "sizeof" in C++/CLI is not extendable to C#. Regarding Richard's comment about me calling the "out of scope" message stupid, I'm going to stand by what I said. "Sizeof" -- especially if Michel is right calling it an operator rather than a function -- is part of the language. It's not some custom function of some special class where an extra reference is needed. So how can it ever be out of scope? In that regard, the message makes no sense. Therefore it is utterly unhelpful. That makes it, IMHO, fully deserving of the label "stupid".
I still stand by my answer. In c#, the debugger can use the .Net compiler support libraries to compile your statement on the fly. In native code, there is no such thing. I must admit that I've never tried it in C#, but in unmanaged C++, this behaviour is 'expected'. Whether to label it stupid, is is entirely up to you.
-
I still stand by my answer. In c#, the debugger can use the .Net compiler support libraries to compile your statement on the fly. In native code, there is no such thing. I must admit that I've never tried it in C#, but in unmanaged C++, this behaviour is 'expected'. Whether to label it stupid, is is entirely up to you.
But I'm not dealing with strictly unmanaged C++ anyway. My project is a "mixed mode" C++/CLI project. By definition, the project has to be .NET-aware. And the breakpoint that I set was actually in a managed code section (i.e., in one of the Windows Forms event handlers). So why can't it use the same .NET compilation support as C#? Even if the project was 100% unmanaged, the compiler still has to convert a sizeof call into a useable via some kind of library. Why can't the debugger make use of that part of the compiler? I don't label the problem itself as "stupid". I obviously don't understand it and was trying to get some clarification. What I do label as "stupid" is the "out of scope" error message. It just seems to me that there has to be a lot better/more helpful wording for when this error condition is encountered -- something like: "'Sizeof' operator is unsupported in debugging." If they had a truly informative error message like that, I wouldn't have had to start this post to begin with. It still wouldn't answer the "why" questions, but at least it would be a lot less cryptic than some vague "out of scope" message. After all, if sizeof is an operator rather than a function as you originally suggested, how the heck can an operator -- a built-in part of the language -- be out of scope?
-
But I'm not dealing with strictly unmanaged C++ anyway. My project is a "mixed mode" C++/CLI project. By definition, the project has to be .NET-aware. And the breakpoint that I set was actually in a managed code section (i.e., in one of the Windows Forms event handlers). So why can't it use the same .NET compilation support as C#? Even if the project was 100% unmanaged, the compiler still has to convert a sizeof call into a useable via some kind of library. Why can't the debugger make use of that part of the compiler? I don't label the problem itself as "stupid". I obviously don't understand it and was trying to get some clarification. What I do label as "stupid" is the "out of scope" error message. It just seems to me that there has to be a lot better/more helpful wording for when this error condition is encountered -- something like: "'Sizeof' operator is unsupported in debugging." If they had a truly informative error message like that, I wouldn't have had to start this post to begin with. It still wouldn't answer the "why" questions, but at least it would be a lot less cryptic than some vague "out of scope" message. After all, if sizeof is an operator rather than a function as you originally suggested, how the heck can an operator -- a built-in part of the language -- be out of scope?
Xpnctoc wrote:
the compiler still has to convert a sizeof call into a useable via some kind of library.
No it merely calculates the size of the operand and puts the resulting value in the object code. There is no associated library call because
sizeof()is an operator, just like+.Xpnctoc wrote:
If they had a truly informative error message
I think this rant should be directed at Microsoft.
It's time for a new signature.
-
Xpnctoc wrote:
the compiler still has to convert a sizeof call into a useable via some kind of library.
No it merely calculates the size of the operand and puts the resulting value in the object code. There is no associated library call because
sizeof()is an operator, just like+.Xpnctoc wrote:
If they had a truly informative error message
I think this rant should be directed at Microsoft.
It's time for a new signature.
Richard MacCutchan wrote:
No it merely calculates the size of the operand and puts the resulting value in the object code. There is no associated library call because sizeof() is an operator, just like +.
And yet other operators like + and == are fully accessible within the Immediate window. You said it yourself... there is no associated library because sizeof is an operator. How can any operator -- an integral part of the language -- ever be out of scope? I mean, wouldn't it strike you as really messed up if suddenly you got an error message saying + was "out of scope"? If 'sizeof' is only evaluated at compile time and treated as a constant in the executable, and Immediate cannot access it as part of the available evaluation syntax, then it seems to me 'sizeof' would be better termed as a MACRO than an operator -- just like using the #define precompiler directive.
-
Richard MacCutchan wrote:
No it merely calculates the size of the operand and puts the resulting value in the object code. There is no associated library call because sizeof() is an operator, just like +.
And yet other operators like + and == are fully accessible within the Immediate window. You said it yourself... there is no associated library because sizeof is an operator. How can any operator -- an integral part of the language -- ever be out of scope? I mean, wouldn't it strike you as really messed up if suddenly you got an error message saying + was "out of scope"? If 'sizeof' is only evaluated at compile time and treated as a constant in the executable, and Immediate cannot access it as part of the available evaluation syntax, then it seems to me 'sizeof' would be better termed as a MACRO than an operator -- just like using the #define precompiler directive.
Well, you are right in all you say and I am (partly) wrong. My biggest mistake was to take your query at face value, rather than checking what results I get. I have just tested this by adding
sizeof(variable)in my watch window while debugging and it shows the correct value. So, we go back to the original problem that you are seeing: where exactly, and under what conditions, are you typing your query?It's time for a new signature.
-
Well, you are right in all you say and I am (partly) wrong. My biggest mistake was to take your query at face value, rather than checking what results I get. I have just tested this by adding
sizeof(variable)in my watch window while debugging and it shows the correct value. So, we go back to the original problem that you are seeing: where exactly, and under what conditions, are you typing your query?It's time for a new signature.
The actual query I'm using is what I originally listed: ? sizeof(bool) rather than ? sizeof(boolean_variable) To reproduce what I'm getting: 1. Make a new project: C++, CLR, Windows Forms Application 2. Double-click the form to generate the Form_Load event. 3. Put a break point on the closing brace of the Form_Load event handler method. 4. Run the application. 5. When the break point is hit, bring up the Immediate window and type "? sizeof(bool)" (without the quotes, of course) 6. Result is: "error: identifier 'sizeof' is out of scope" If you take identical steps but use a C# project, you will get an output of "1". Michel had mentioned that we should expect the error message in unmanaged C++, but from the steps I've outlined above, we're not dealing with unmanaged C++. We're dealing with CLR-aware C++, so it seems to me we should have the same .NET support as C#. BTW, this is under VS 2008 (and Windows 7 64-bit if that makes a difference).
-
The actual query I'm using is what I originally listed: ? sizeof(bool) rather than ? sizeof(boolean_variable) To reproduce what I'm getting: 1. Make a new project: C++, CLR, Windows Forms Application 2. Double-click the form to generate the Form_Load event. 3. Put a break point on the closing brace of the Form_Load event handler method. 4. Run the application. 5. When the break point is hit, bring up the Immediate window and type "? sizeof(bool)" (without the quotes, of course) 6. Result is: "error: identifier 'sizeof' is out of scope" If you take identical steps but use a C# project, you will get an output of "1". Michel had mentioned that we should expect the error message in unmanaged C++, but from the steps I've outlined above, we're not dealing with unmanaged C++. We're dealing with CLR-aware C++, so it seems to me we should have the same .NET support as C#. BTW, this is under VS 2008 (and Windows 7 64-bit if that makes a difference).
OK, I can reproduce this under VS2010 (full and Express versions). I guess the only way forward is to raise this with Microsoft. I'm still confused as to why this happens with managed but not unmanaged code; I guess two different debuggers.
It's time for a new signature.