how to print the microsecond symbol in C? - c

I am trying to print the microsecond symbol in C, but I don't get any data in the output.
printf("Micro second = \230");
I also tried using
int i = 230;
printf("Character %c", i);
but in vain! Any pointers?

That depends entirely on the character encoding used by the console you're using. If you're using Linux or Mac OS X, then most likely that encoding is UTF-8. The UTF-8 encoding for µ (Unicode code point U+00B5) is 'C2 B5' (two bytes), so you can print it like this:
printf("Micro second = \xC2\xB5"); // UTF-8
If you're on Windows, then the default encoding used by the console is code page 437, then µ is encoded as 0xE6, so you would have to do this:
printf("Micro second = \xE6"); // Windows, assuming CP 437

Here is the standards-sanctioned way to print it in C:
printf("%lc", L'\u00b5');
If you're happy assuming UTF-8, though, I'd just hard-code "µ".

Since you work on Mac OS, you can rest assured that the terminal uses UTF-8. Therefore, bring up the characters palette (Edit -> Special characters...), find the microsecond symbol there, and put it right into your string.
int main()
{
printf("µs\n");
}
It will work as long as your source file is UTF-8 too. Otherwise, you'll need to find the code point for it (which should also be indicated in the characters palette). Mouse over the character to find its UTF-8 value (and excuse my French system):
This means you can use printf("\xc2\xb5") as an encoding-independant replacement for the character itself.

printf("%c", 230);
works for me. I think this is OS dependent though. It is encoding dependent (thanks zneak). I'm on Windows.

I had the same issue, I found the solution based on Code page 437
"\xB5"
I just included that code into a string and it worked for me.
My environnement: Windows, C++. I was trying to convert a string to display in SFML.

Using a mix of C and C++14 for a work project, here's what worked for me:
printf("Micro second symbol = \xC2\xB5");
\xB5, and \230 produced ▒ on my output. My project equipment is apparently is picky as I tried it with elsewhere with some online IDE's and a version of Xcode on Mac, all worked fine.
Could be if you're trying to print elsewhere besides console, say like to an LCD screen, then you're screen would have to be programmed (created and mapped to xyz...) to include that character. Though from my experience that varies wildly depending on what you're creating.

Related

How the encoding standard you use to save a c program affect during compilation

I created a basic, simple C program and saved it with the .c extension using the Unicode encoding standard, and did not compile correctly. An error occurred saying null character(s) ignored, but when I saved the same program using ASCII standard it compiled just fine.
What is the reason behind this? My compiler is gcc compiler
Thank you.
There is no encoding called "Unicode". Unicode is not an encoding. It is a standard for many many things including several encodings.
The encodings are such as UTF16-LE and UTF-8. I presume you're using Notepad.exe on Windows. Microsoft may call this UTF16 little-endian as "Unicode". It would represent each ASCII character as two bytes, one of which would be NULL byte.
As far as I know GCC never expects the file to be in UTF-16 encoding, so it just ignores these intervening null bytes...
What you need to do is get a proper text editor that uses proper terminology and save your files as UTF-8 or whatever lesser encoding the operating system happens to use from day to day.

Print Unicode characters in C, using ncurses

I have to draw a box in C, using ncurses;
First, I have defined some values for simplicity:
#define RB "\e(0\x6a\e(B" (ASCII 188,Right bottom, for example)
I have compiled with gcc, over Ubuntu, with -finput-charset=UTF-8 flag.
But, if I try to print with addstr or printw, I get the hexa code.
What I`m doing wrong?
ncurses defines the values ACS_HLINE, ACS_VLINE, ACS_ULCORNER, ACS_URCORNER, ACS_LLCORNER and ACS_LRCORNER. You can use those constants in addch and friends, which should result in your seeing the expected box characters. (There's lots more ACS characters; you'll find a complete list in man addch.)
ncurses needs to know what it is drawing because it needs to know exactly where the cursor is all the time. Outputting console control sequences is not a good idea; if ncurses knows how to handle the sequence, it has its own abstraction for the feature and you should use that abstraction. The ACS ("alternate character set") defines are one of those abstractions.
A few issues:
if your program writes something like "\e(0\x6a\e(B" using addstr, then ncurses (any curses implementation) will translate the individual characters to printable form as described in the addch manual page.
ncurses supports line-drawing for commonly-used pseudo-graphics using symbols (such as ACS_HLINE) which are predefined characters with the A_ALTCHARSET attribute combined. You can read about those in the Line Graphics section of the addch manual page.
the code 0x6a is ASCII j, which (given a VT100-style mapping) would be the lower left corner. The curses symbol for that is ACS_LRCORNER.
you cannot write the line-drawing characters with addstr; instead addch, addchstr are useful. There are also functions oriented to line-drawing (see box and friends).
running in Ubuntu, your locale encoding is probably UTF-8. To make your program work properly, it should initialize the locale as described in the Initialization section of the ncurses manual page. In particular:
setlocale(LC_ALL, "");
Also, your program should link against the ncursesw library (-lncursesw) to use UTF-8, rather than just ncurses (-lncurses).
when compiling on Ubuntu, to use the proper header definitions, you should define _GNU_SOURCE.
BTW, maybe I'm probably arriving somewhat late to the party but I'll give you some insight that might or not shed some light and skills for your "box drawing" needs.
As of 2020 I'm involved in a funny project on my own mixing Swift + Ncurses (under OSX for now, but thinking about mixing it with linux). Apparently it works flawlessly.
The thing is, as I'm using Swift, internally it all reduces to "importing .h and .c" files from some Darwin.ncurses library the MacOS Xcode/runtime offers.
That means (I hope) my newly acquired skills might be useful for you because apparently we're using the very same .h and .c files for our ncurses needs. (or at least they should be really similar)
Said that:
As of now, I "ignored" ACS_corner chars (I can't find them under swift/Xcode/Darwin.ncurses runtime !!!) in favour of pure UTF "corner chars", which also exist in the unicode pointspace, look:
https://en.wikipedia.org/wiki/Box-drawing_character
What does it mean? Whenever I want to use some drawing box chars around I just copy&paste pure UTF-8 chars into my strings, and I send these very strings onto addstr.
Why does it work? Because as someone also answered above, before initializing ncurses with initscr(), I just claimed "I want a proper locale support" in the form of a setlocale(LC_ALL, ""); line.
What did I achieve? Apparently pure magic. And very comfortable one, as I just copy paste box chars inside my normal strings. At least under Darwin.ncurses/OSX Mojave I'm getting, not only "bounding box chars", but also full UTF8 support.
Try the "setlocale(LC_ALL, ""); initscr();" approach and tell us if "drawing boxes" works also for you under a pure C environment just using UTF8 bounding box chars.
Greetings and happy ncursing!

Why Xcode C compiler does not display properly some of the ASCII table characters?

I'm developing a program in C using Xcode.To be practical let's take the following code
#include <stdio.h>
int main () {
printf("%c",3);
}
It's supposed to display the hearts character but it doesn't,instead just a interrogation icon show's up!And,at least for me,this is happening for many other 'special' characters.Anyone knows the reason of this?
The ASCII character 3 is a control character called "end of text." It does not stand for a hearts symbols. You may think that it does because the PC console generated a heart-suit symbol when a program tried to print that character. There's no reason why a modern system should follow the same convention, although the console emulator of Windows cmd.exe might still do it.
If you want to output a heart-suit symbol in a modern environment you should use Unicode, for example:
printf("%s", "\u2665");

Getting a Dev-C++ built program to output UNICODE characters to the Windows command line

If you can answer any of my questions, that would be awesome.
Here's the scoop: I'm teaching an intro to programming class in Thailand to 11th graders. It's been going great so far, their level of English is high enough that I can teach in English and have them write programs in English and everything is fine and dandy.
However, as speakers of a language with non-Latin characters, I feel that they should at least learn what UNICODE is. I won't test them on it or bog them down with implementation details, but I want to show them an example of a UNICODE program that can do I/O with Thai characters.
I'm operating under the following constraints, none of which can be changed (at least for this semester):
The program must run on Windows 7
The program must be in C (not C++)
We must use Dev-C++ (v. 4.9.9.3) as our IDE (I'm going to try and convince the admins to change for next semester, but they may not want to)
The program should output to the Command Line (I'd like it to "look like" the programs we've been writing so far)
I want it to be easy to set up and run, though I'm not opposed to including a Batch file to do some setup work for the kids.
Here's how far I've gotten, and the questions I have:
In Control Panel > Regions > Administrative > Language for non-UNICODE programs is set to Thai.
I used "chcp 874" to set the Thai codepage in the Command Line, but characters from the keyboard come appear as garbage characters. Is this maybe because the keyboard mappings are wrong or do I have to change something else?
I wrote a program with the line: printf("\u0E01\n"); which prints ก, the first letter in the Thai alphabet. Is that the right syntax?
I received a compiler warning that "Universal Characters are only supported in C++ and C99." Does Dev-C++ not compile to C99? Is there a way I could get a C99 compiler for it?
I ran the code and got garbage characters. I imagine this could be because of the compiler, the command line, or any number of other things.
I'd love to end this course with a program that outputs สวัสดีโลก, the Thai equivalent of "Hello World!" I've done tons of googling, but every answer I've found either doesn't work in this specific case or involved a different IDE.
Ok, here's my bit of help. I don't use Dev-C++ as my IDE, so I can't help you with IDE specific things, but the following is standard to most C/C++ compilers:
wprintf is the printf implementation for wide characters (unicode).
When using wide characters you will use wchar_t in place of char for defining strings.
so you might do something like this
#include <wchar.h>
int main(int argc, char** argv) {
wchar_t* str = L"สวัสดีโลก";
wprintf(L"%s", str);
system("pause");
return 0;
}
wprintf is most likely what you're looking for.
Other functions for printing and manipulating wide strings can be found by researching the wchar.h header file.
Reference:
wprintf - C++ Reference
Using L before the quotations means you intend to define a wide string. (unicode)
Hope that helps,
-Dave
I have never used DEV-C++ IDE :-) However, after reading up on it a bit I see that
dev-c++ version 4.9.9.3 uses gcc-3.5.4 mingw port. Which has universal character support status of "Done" see http://gcc.gnu.org/gcc-3.4/c99status.html for details. You have to change the IDE configuration such that the compiler uses -std=c99 as part of the compiler flags.
Hopefully that will do the trick.
I will try to fiddle with it on my own system and see how far we can get. Will update the answer if I find more clues :-)
If you need to change the code page in a console C program, you can add the header <stdlib.h> and the line system("CHCP 874"); at the beginning of the program.
If you need a free compiler conforming with C99 under windows, you can try Pelles C:
http://www.christian-heffner.de/index.php?page=download&lang=en
It is conforming at all with C99.
You have to use wide-string constants, that have the following syntax:
L"Wide string\n"
Instead of printf(), you need to use wprintf() and the like.
http://pubs.opengroup.org/onlinepubs/7908799/xsh/wchar.h.html

Utf8 Linux filenames and C

I am working at a OS independent file manager, using SDL_ttf to draw my text.
On Windows, everything works well, but on Linux I have to use the UTF8 functions of SDL_ttf, because the filenames can be UTF8 encoded.
This works well, but if I have my own C string (not a file name) such as "Ää", it will be displayed wrong. Is there any way to tell gcc to encode my strings as UTF8?
You don't need anything special from your C compiler for UTF-8 string literals. Proper support for it in the APIs you use is another matter, but that seems to be covered.
What you do need to do is to make sure your source files are actually saved in UTF-8, so that non-ASCII characters don't get converted to some other encoding when you edit or save the file.
The compiler doesn't need specific UTF-8 support, as long as it assumes 8-bit characters and the usual ASCII values for any syntactically significant characters; in other words, it's almost certainly not the problem.
gcc should interpret your source code and string literals as UTF-8 by default. Try -fexec-charset
See also: http://gcc.gnu.org/onlinedocs/gcc-4.0.1/cpp/Implementation_002ddefined-behavior.html#Implementation_002ddefined-behavior
C should have some sort of Unicode string literal syntax. Googling for "Unicode programming C" should get you started, two tutorials that seemed good are the one on developerworks and the one on cprogramming.com.
The general approach for your specific case would be using a wide string literal L"Ää", then converting that into UTF-8 with wcstrtombs().

Resources