I'm using Code::Blocks on Ubuntu 10.10 (Maverick Meerkat). I have connected a Mac keyboard and set the keyboard settings to "Swiss German Mac". Now whenever I write an equals sign, followed by a space (something like width = 100) I get the error message: stray '\302' in program.
I know this error means that there is a non-standard character in the text file.
When I delete the space character, the program compiles just fine. So that means Code::Blocks adds some sort of special character. But I can't see why this happens. What is the reason?
What character does '\302' stand for?
[UPDATE]
I got a little further investigating the problem. I get this stray when I use the combo Shift + Space. Now that I know it doesn't happen that often any more. But it's still rather annoying especially when writing code... Is there a way to turn off this combo in X11?
[SOLVED]
Thanks to Useless's answer, I was able to solve the "issue". It's more of a feature actually. Shift + space created a spacenolinebreak by default. So by changing the xmodmap with
xmodmap -e "keycode 65 = space space space space space space"
this behavior was overridden and everything works fine now.
Since you're sure it's caused by hitting Shift + Space, you can check what X itself is doing by. First, run xev from the command line, hit Shift + Space and check the output. For example, I see:
$ xev
KeyPress event, serial 29, synthetic NO, window 0x2000001,
root 0x3a, subw 0x0, time 4114211795, (-576,-249), root:(414,593),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 29, synthetic NO, window 0x2000001,
root 0x3a, subw 0x0, time 4114213059, (-576,-249), root:(414,593),
state 0x1, keycode 65 (keysym 0x20, space), same_screen YES,
XLookupString gives 1 bytes: (20) " "
XmbLookupString gives 1 bytes: (20) " "
XFilterEvent returns: False
...
Then, run xmodmap -pk and look up the keycode (space should be 65 as above, but check your xev output).
If you see something like
65 0x0020 (space)
Then X isn't doing this. On the other hand, if I pick a character key which is modified by shift, I see something like this:
58 0x006d (m) 0x004d (M)
If you have two or more keysyms for your keycode, X is the culprit. In that case, something like xmodmap -e 'keycode 65 space' should work.
\302 stands for the octal representation of byte value the compiler encountered. It translates to 11000010 in binary, which makes me think it's the start of a two byte UTF-8 sequence. Then this sequence must be:
11000010 10??????
Which encodes the binary Unicode point 10??????, which can be anything from U+80 to U+BF.
Several characters starting from U+80 are special spaces and breaks which usually are not shown inside a text editor.
Probably it's not your editor, but Xorg, that emits these characters due to your keyboard settings. Try switching to a generic US keyboard and test if the problems persists.
'\302' is C notation for the octal number 3028, which equals C216 and 19410. So it's not ASCII.
Which character it maps to depends on the encoding. In Latin-1, it's the  character, for instance.
I have seen this type of issue when copying and pasting from web pages or other electronic documents. The common culprits would be invalid quotes like ` instead of ', or something alike. Try to use the compiler error to guide you into where in the file the error might be.
That sounds like some kind of encoding issue. I haven't used Code::Blocks for years, so I am not sure if it allows you to pick different encodings.
How about opening your code file with gedit and saving it as UTF-8, and then try again? But it sounds rather strange that you get such an issue using space characters.
I've seen this problem in my Linux box with a Finnish keyboard.
It also happens with Emacs, etc. I don't have a good solution for it, but I guess reports about the fact that it happens elsewhere are also useful...
If you open your file in Emacs and set-buffer-file-coding-system to something like "unix" or some ASCII variety, then when you try to save, it'll warn you that the buffer contains unrepresentable characters and points you to them so you can fix them.
I had the same issue by modified a US ASCII example file.
So I convert it in UTF-8, here are GNU/Linux command:
iconv -c -t us-ascii -f utf-8 source_file -o dest_file
And then add my modifications… no more errors!
To verify initial encoding, use
file -i source_file
I should add a non-ASCII character to allow iconv do the job!!??
I decided to move the file from a MAC book to a Linux box and used email with my icloud.com address. When I opened the transferred file the errors had gone and the file now compiles !
Related
While writing a program I encountered a bug. When I don't use the system() function in my code, e.g. system("CLS"); character 27 (that is the left arrow in the ASCII code) is displayed correctly, but after using this function this character turns into an empty space. I should add that this does not happen with any other ASCII character.
Here is some code:
printf("%c %c",27,26);
And it displays: ← →
but
system("CLS");
printf("%c %c",27,26);
displays: →
Anyone had a similar problem and dealt with it? I would like to find out how to solve it because I need both the system() and the left arrow.
The ← character in Unicode is codepoint U+2190 LEFTWARDS ARROW.
In codepage 437 (aka the DOS OEM codepage), for instance, byte 0x1B (dec 27) is used to display Unicode codepoint U+2190. See Console Code Pages for more details.
So, it is possible that maybe calling system("CLS") is resetting the current codepage of the terminal, which would explain why printing 0x1B no longer displays as ←. Try calling system("CHCP 437") or SetConsoleOutputCP(437) afterwards to change it back.
Or, you could simply stop relying on printing ANSI strings using codepages at all. Print out Unicode strings instead, using wprintf() or WriteConsoleW(), or since your question is tagged as c++, use std::wcout.
Out of interest, on the windows console, the ASCII codes 0-5, 11, 16-26 and 28-31 have printable symbols, the others below 32 really are control codes and may do something very odd 😁
char(27) really is escape and char(24) cancels it. char(7) sounds the bell.
I am currently writing a uart-console on an ATMega1284p. It supposed to echo the characters back, so that the computer-side-console actually sees what is being typed and that is it for now.
Here is the problem: With ASCII it works perfectly fine, but if I am sending anything beyond ASCII e.g. a '§' my minicom shows "�§" '�' being the invalid or the '§' in case everything works fine. But getting the combination of both throws me off and I currently have no idea where the problem is!
Here is part of my code:
char c;
while(m_uart->recv(c) > 0) {
m_lineBuff[m_lineIndex++] = c;
if(c == '\r') {
c = '\n';
m_lineBuff[m_lineIndex++] = c;
m_sendCount = 2;
} else {
m_sendCount = 1;
}
this->send();
if(c == '\n') {
m_lineBuff[m_lineIndex++] = '\0';
// invoke some callbacks that handle the line at some point
m_lineIndex = 0;
}
}
m_lineBuff is a self written (and tested) vector of chars. m_uart is a self written (and also tested) UART driver for the micro-internal hardware uart. this->send sends m_sendCount bytes using m_uart.
What I tried so far:
I verified that the baud rates of minicom and my micro match (115200). I verified that the frequency is within the 2% range (micro is running at 20MHz). Both minicom and the micro are setup for 8n1.
I verified that minicom works by hooking it up to a little-board I had lying around. On that board any utf-8 digit works just fine.
Does anyone see my mistake or does anyone have a clue at what I haven't considered?
I'll be happy to supply up to all of my code if you guys are interested in it.
EDIT/Elaboration:
Observation 1 (prior to starting this project)
The PC side program (minicom) can send and recieve characters to resp. from the microcontroller. It does not show the sent characters though.
Conclusion 1 (prior to starting this project)
The microcontroller side needs to send the characters back to the PC, so that you have the behaviour of a console.
Thus I immediately send back any character I get.
Observation 2 (after implementing it)
When I press '§' (or any other character consisting of more than 1 byte) (using minicom) I see "�§".
Conclusion 2 (after implementing it)
Something I can't explain with my knowledge is going on. Maybe a small delay between the two bytes making up the character lead to minicom printing a '�' first because the first byte on it's own is indeed an invalid character, and when the second character comes in minicom realizes that it's acutally '§' but minicom doesn't remove/overwrite the '�'.
If that is the problem, then how do I solve it? Does my microcontroller need to react faster/with less delay in between characters?
EDIT2:
I replaced the '?' with the actual character '�' using the power of copy and paste.
More tests I did
I tried the character '😹' and as I expexted (it backs my conclusion 2) and I got "���😹". '😹' by the way is a 4 byte character.
Set the baud rate of micro and minicom to 9600: exact same behaviour.
I managed to set minicom into hex mode: it sends regularly but outputs hex... When I send '😹' I get "f0 9f 98 b9" which (at least according to this site) is correct... Is that backing my conclusion 2? And more importantly: how do I get rid of that behaviour. It works with my little linux board instead of my micro.
EDIT: the op discovered on his own that the odd behaviour he discovered is (probably) a bug of minicom itself. This post of mine clearly looses its value, unless the community thinks that it should be removed I would leave it here as a witness of possible workarounds when experiencing similar problems.
tl;dr: your pc application might not be interpreting UTF-8 correctly as it appears.
If we look at the Extended ASCII Code defined by ISO 8859-1,
A7 10100111 § § => Section sign
and according to this page, the UTF-8 encoding of § is
U+00A7 § c2 a7 => SECTION SIGN
So my educated guess is that the symbol is still printed correctly because it belongs to the Extended ASCII Code with the same value a7.
Either your end-application fails to correctly interpret the UTF-8 U (c2) symbol, and that's why you get an ? printed out, or a component in the middle fails to pass the correct value forward. I am inclined to believe your output is an instance of the first case.
You claim that minicom works, I can not refute this claim, but I would suggest you to try the following things first:
try send a symbol that belongs to UTF-8 but not to the ISO 8859-1 standard: if it doesn't work, this should rule out your Conclusion #2 pretty immediately;
try reduce the speed to the lowest possible, 9600 baud rate
verify that minicom is correctly configured to interpret UTF-8 characters checking the documentation;
try to use some other application to fetch data from your micro-controller and see whether the results are consistent;
verify that the unicode symbol U you're sending out is correct
NB: this is kind of an incomplete answer, but I couldn't get everything in the comments. If you're patient enough, please update your question with your findings and comment this answer to notify me. I'll get back here and update my answer accordingly.
I am trying to examine some addresses in gdb. It was printing in hex previously but I'm not sure how I changed it. When I enter x/20 $rsp the result looks like this:
0x7fffffffb060: -20336 32767 -559038737 0
Obviously this is not the end of the world since I can manually convert the values if needed but it is pretty annoying. I've tried exiting gdb and restarting but that does nothing.
gdb uses the last specified setting when printing values. To force hexadecimal, append x: x/20x addr.
faced the same issue, I try to print one byte first and then x/x shows hex values
or
use x/4bx to display 4 bytes in hex, there is an extra x in the end.
When I was using up to qt4.8(qt quick 1.1) for gui then I am successfully able to print degree with \260 but when things got upgraded to qt5 and above then this stopped working. I searched on the net and found many relevant link such as (http://www.fileformat.info/info/unicode/char/00b0/index.htm) I tried but no help. Do I need to include some library for usinf UTF format or problem is sth else. Please some one help. What to do?
#Revised,
Here it is described what is being done.
First I am storing the printable statement in string text.
As in cpp function:-
sprintf(text, "%02d\260 %03d\260 ",latD, longD);
QString positionText(text.c_str());
return positionText;
And then using positionText in qml file to display on the window.
So, someone please answer what do I need to do to have degree in display?
Thanks.
Problem is simple you used \260 most probably inside Ansii C-string (const char []). In such cases Qt has use some codec to convert this to Unicode characters. For some reason when you change Qt version default codec was changed and this is why it stopped working.
Anyway your approach is wrong. You shouldn't use C-string which are codec depended (usually this leads to this kind of problems). You can define QChar const as QChar(0260) or best approach is to use tr and provide translation.
It would be best if you give representative example with string with degree character, then someone will provide you best solution.
Edit:
I would change your code like this:
const QChar degreeChar(0260); // octal value
return QString("%1%3 %2%3").arg(latD, 2, 10, '0').arg(longD, 3, 10, '0').arg(degreeChar);
or add translation which will handle this line:
return tr("%1degree %2degree").arg(latD, 2, 10, '0').arg(longD, 3, 10, '0');
Note that this translation for this line only have to be added always no mater what is current locale.
Try
return QString::fromLatin1(text);
or, if that doesn't work, another static QString::fromXXX method.
QT5 changed Qt's default codec from Latin-1 to UTF-8, as described here:
https://www.macieira.org/blog/2012/05/source-code-must-be-utf-8-and-qstring-wants-it/
Latin-1 and Unicode both use 176 (0xB0 or 0260) as the degree symbol, so your usage of it coincidentally worked, since it was interpreted as Latin-1 and converted to the same value in Unicode.
That first line could be changed to:
sprintf(text, "%02d\302\260 %03d\302\260 ",latD, longD);
As mentioned before, going directly to a QString is indeed better, but if you had to go through a std::string, you could simply substitute the UTF-8 encoding of Unicode 176, in which the lower 6 bits 110000 would have a 10 prepended, and the upper 2 bits 10, would have 110000 prepended in the first byte. This becomes: \302\260.
To easily print angles with degree symbols in console, try this:
#include <QDebug>
double v = 7.0589;
qDebug().noquote() << "value=" << v << QString(248);
Console output:
value= 7.0589 °
This works out-of-the-box under Windows.
I'd like to have my program output "cm2" (cm squared).
How do make a superscript 2?
As Zan said, it depends what character encoding your standard output supports. If it supports Unicode , you can use the encoding for ²(U+00B2). If it supports the same Unicode encoding for source files and standard output, you can just embed it in the file. For example, my GNU/Linux system uses UTF-8 for both, so this works fine:
#include <iostream>
int main()
{
std::cout << "cm²" << std::endl;
}
This is not something C++ can do on its own.
You would need to use a specific feature of your console system.
I am not aware of any consoles or terminals that implement super-script. I might be wrong though.
I was trying to accomplish this task for the purpose of making a quadratic equation solver. Writing ax² inside a cout << by holding ALT while typing 253 displayed properly in the source code only, BUT NOT in the console. When running the program, it appeared as a light colored rectangle instead of a superscript 2.
A simple solution to this seems to be casting the integer 253 as a char, like this... (char)253.
Because our professor discourages us from using 'magic numbers', I declared it as a constant variable... const int superScriptTwo = 253; //ascii value of super script two.
Then, where I wanted the superscript 2 to appear in the console, I cast my variable as a char like this...
cout << "f(x) = ax" << (char)superScriptTwo << " + bx + c"; and it displayed perfectly.
Perhaps it's even easier just to create it as a char to begin with, and not worry about casting it. This code will also print a super script 2 to the console when compiled and run in VS2013 on my Lenovo running Windows 7...
char ssTwo = 253;
cout << ssTwo << endl;
I hope someone will find this useful. This is my first post, ever, so I do apologize in advance if I accidentally violated any Stack Overflow protocols for answering a question posted 5+ years ago. Any such occurrence was not intentional.
Yes, I agree with Zan.
Basic C++ does not have any inbuilt functionality to print superscripts or subscripts. You need to use any additional UI library.
std::cout << cm\x00B2;
writes cm^2.
For super scripting or sub scripting you need to use ascii value of the letter or number.
Eg: Super scripting 2 for x² we need to get the ascii value of super script of 2 (search in google for that) ie - 253. For typing ascii character you have to do alt + 253 here, you can write a any number, but its 253 in this case.
Eg:-cout<<"x²";
So, now it should display x² on the black screen.
Why don't you try ASCII?
Declare a character and give it an ASCII value of 253 and then print the character.
So your code should go like this;
char ch = 253;
cout<<"cm"<<ch;
This will definitely print cm2.