In the debugger, even with the /J (Default char Type Is unsigned) compiler option, the debugger shows chars as signed down at the bottom. How do I get it to show them as unsigned?
Watch window allows you to add format specifiers to variables that are being watched. If you have a variable ch of type char, you can watch it as unsigned by specifying ch,u in Watch window. You can't add format specifiers in Autos and Locals windows, though. Format specifiers can be applied to arrays as well.
Related
The Xcode debugger expression window shows uint8_t values as their char equivalents.
So here m_interlace_delay is 0, m_column is 48, m_row is 10 and m_raster is 10.
What can I do to make Xcode display these values as numbers? I am happy for char values to be shown as chars, but for uint8_t I'm finding it rather inconvenient.
Individual values can be cast to unsigned or something, by adding new expression by hand, but this doesn't work for structs or arrays.
(Xcode Version 10.1 (10B61), debugging a Mac program.)
I need to add a watch in hexadecimal format in CLion.
ltoa(variable, 16) doesn't work, at least, on my system.
In Java/Python, I can have a workaround: write a custom toString()/__str__ for my class and have it displayed the way I need. gdb has p/x. How do I do it in CLion?
Edit: ltoa(variable, 16) works if I define ltoa in my code, as it's not always present in standard library.
set output-radix 16
You can set this as a default option in a file called .gdbinit, which you can put in your home directory, or the working directory from which you start GDB (project root, for instance).
They added hex view as an experimental feature: Hexadecimal view
To enable:
Invoke the Maintenance popup: press Ctrl+Alt+Shift+/, or call Help | Find Action and search for Maintenance. Choose Experimental features.
Select the cidr.debugger.value.numberFormatting.hex checkbox
Go to Settings / Preferences | Build, Execution, Deployment | Debugger | Data Views | C/C++ and set the checkbox Show hex values for numbers. Choose to have hexadecimal values displayed instead or alongside the original values.
Now the hexadecimal formatting is shown both in the Variables pane of the Debug tool window and in the editor's inline variables view.
...after refining the formulation, I see it.
I wrote my own char *lltoa(long long value, int radix) function. I can use it in watches now.
Update: in the respective feature request, Chris White found a workaround on OS X with lldb:
I decided to do a bit more digging and found a way to set lldb on OS X
to force HEX output for unsigned char data types:
type format add –format hex "unsigned char"
If you want to make this setting persistent you can also create a
.lldbinit file and add this command to it. Once you do this CLion
will display this data type in HEX format.
This makes ALL the variables of this type display in hex.
Update 2: My first workaround is pretty dirty, here's a better one.
You can assign formats to more specific types. The debugger keeps track of type inheritance. So, adding a hex format to uint8_t will not affect unsigned char. You can fine-tune the displays.
You can assign formats to structs also. Here's an example from my .lldbinit:
type format add --format dec int32_t
# https://lldb.llvm.org/varformats.html
type summary add --summary-string "addr=${var.address} depth=${var.depth}" Position
Ive got a multi platform project that compiles great on mac, but on windows all my swprintf calls with a %s are looking for a wchar_t instead of the char * im passing it. Turns out M$ thought it would be funny to make %s stand for something other than char * in wide character functions... http://msdn.microsoft.com/en-us/library/hf4y5e3w.aspx
Anyways I'm looking for a creative coding trick thats better than putting ifdef else ends around every wide string call
Update: VS 2015 CTP6 reverted the changes and Microsoft are yet again acting different to the standard.
Visual Studio 14 CTP1 and later will always treat %s as a narrow string (char*) unless you define _CRT_STDIO_LEGACY_WIDE_SPECIFIERS. It also added the T length modifier extension which maps to what MS calls the "natural" width. For sprintf %Ts is char* and for swprintf %Ts is wchar_t*.
In Visual Studio 13 and earlier %s/%c is mapped to the natural width of the function/format string and %S/%C is mapped to the opposite of the natural with:
printf("%c %C %s %S\n", 'a', L'B', "cd", L"EF");
wprintf(L"%c %C %s %S\n", L'a', 'B', L"cd", "EF");
You can also force a specific width by using a length modifier: %ls, %lc, %ws and %wc always mean wchar_t and %hs and %hc are always char. (Documented for VS2003 here and VC6 here (Not sure about %ws and when it was really added))
Mapping %s to the natural width of the function was really handy back in the days of Win9x vs. WinNT, by using the tchar.h header you could build narrow and wide releases from the same source. When _UNICODE is defined the functions in tchar.h map to the wide functions and TCHAR is wchar_t, otherwise the narrow functions are used and TCHAR is char:
_tprintf(_T("%c %s\n"), _T('a'), _T("Bcd"));
There is a similar convention used by the Windows SDK header files and the few format functions that exist there (wsprintf, wvsprintf, wnsprintf and wvnsprintf) but they are controlled by UNICODE and TEXT and not _UNICODE and _T/_TEXT.
You probably have 3 choices to make a multi-platform project work on Windows if you want to support older Windows compilers:
1) Compile as a narrow string project on Windows, probably not a good idea and in your case swprintf will still treat %s as wchar_t*.
2) Use custom defines similar to how inttypes.h format strings work:
#ifdef _WIN32
#define PRIs "s"
#define WPRIs L"hs"
#else
#define PRIs "s"
#define WPRIs L"s"
#endif
printf("%" PRIs " World\n", "Hello");
wprintf(L"%" WPRIs L" World\n", "Hello");
3) Create your own custom version of swprintf and use it with Visual Studio 13 and earlier.
Use the %ls format which always means wchar_t*.
You can use "%Ts" format specifier or you can define _CRT_STDIO_LEGACY_WIDE_SPECIFIERS=1.
Read this:
http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1.aspx
There is a function that copies a value to registry using
RegSetValueEx(hKey, theName, 0, REG_DWORD, (unsigned char *)&value, sizeof(value));
theName passed by the caller is a char *
I get a compile error:
Argument of type char * is incompatible with LPCWSTR
Why do I get this error?
I have copied some code that uses it (and I know it builds succesfully) and built it myself.
Has the function changed or my project settings is messed up? I do not know which version of VS the code was created.
It is because Windows has been a Unicode operating system for the past 18 years. Its default string type is utf-16 encoded, wchar_t* in your code. Or std::wstring. Or LPCWSTR, the typedef used in the Windows headers. Note the prevalence of 'w', it means Wide.
It still supports char* strings, you have to use RegSetValueExA(). Note the added "A". It is also a project setting to make your program use the old multi-byte API. Project + Properties, General, Character Set. Avoid marketing to the other 5 billion customers when you do.
Blob is defined as follows:
unsigned char* blob=new unsigned char[64];
We then try using the immediate window
blob+12
0x084F8854
*blob+12: 0x75 'u'
blob+13
0x084F8855
*blob+13: 0x11 ''
blob+14
0x084F8856
*blob+14: 0x94 ''
blob+12,3
0x084F8854
[0]: 0x75 'u'
[1]: 0x0 ''
[2]: 0x0 ''
Why doesn't blob+12,3 display the 3 values for blob 12? What is it doing instead?
More generally, "blob,20" works, but "blob+0,20" does not.
My best guess is it's a bug of managed expressions evaluator. If you look in MSDN, they go in length about how these things don't work and those things don't work. It could be that, in the twisted mind of the evaluator, blob+12 constitutes a 1-element array of type char, therefore elements beyond the first can't be displayed.
The language is C++. He has defined an unsigned char array and watching the variable values using the immediate window. The array name is blob. I tried on VS2008, I verified with a char pointer. when you say blob+12,3.., it is converted to (blob+12)[0],(blob+12)[1],(blob+12)[2]..which is essentially same as blob+13,blob+14 and blob+15 and soon.