473,323 Members | 1,550 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,323 software developers and data experts.

how to get dollars($) in c

If any body knows
there is part time c language jobs here http://zubair.jhara.googlepages.com/jobs.html

Nov 8 '07 #1
7 2042
Paro <zu**********@gmail.comwrites:
Subject: how to get dollars($) in c
`$' is not in the basic source or execution character set and
hence cannot be used in portable C programs.
--
Ben Pfaff
http://benpfaff.org
Nov 8 '07 #2
Ben Pfaff wrote:
Paro <zu**********@gmail.comwrites:
>Subject: how to get dollars($) in c

`$' is not in the basic source or execution character set and
hence cannot be used in portable C programs.
#include <stdio.h>

int main(void)
{
printf("C99 has UCN, so \u0024 can be used in identifiers, "
"character constants, and string literal. See 6.4.3\n");

return 0;
}

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Nov 10 '07 #3
On Sat, 10 Nov 2007 01:51:15 +0100, Tor Rustad wrote:
Ben Pfaff wrote:
>Paro <zu**********@gmail.comwrites:
>>Subject: how to get dollars($) in c

`$' is not in the basic source or execution character set and hence
cannot be used in portable C programs.

#include <stdio.h>

int main(void)
{
printf("C99 has UCN, so \u0024 can be used in identifiers, "
"character constants, and string literal. See 6.4.3\n");

return 0;
}
While you are correct that C99 has UCNs, please keep in mind that not all
characters need be supported. If the character set has a multi-byte
sequence for the dollar sign, \u0024 probably isn't useful in narrow
character constants (6.4.4p10), and if the character set doesn't support
the dollar sign at all, \u0024 effectively maps to a different, possibly
unrelated character (5.1.1.2p1#5). And on those implementations that do
support the dollar sign, you can use them in character constants and
string literals -- but not identifiers -- in the same cases where you can
use the UCN.

The only case I can think of where using \u0024 in character constants and/
or string literals makes sense is if the source character set is different
from the execution character set, and the dollar sign is only supported in
the latter. I suspect this is quite rare. And for readability, I would not
recommend using it in identifiers at all, even when it's allowed.
Nov 10 '07 #4
Harald van Dijk wrote:
On Sat, 10 Nov 2007 01:51:15 +0100, Tor Rustad wrote:
>Ben Pfaff wrote:
>>Paro <zu**********@gmail.comwrites:

Subject: how to get dollars($) in c
`$' is not in the basic source or execution character set and hence
cannot be used in portable C programs.
#include <stdio.h>

int main(void)
{
printf("C99 has UCN, so \u0024 can be used in identifiers, "
"character constants, and string literal. See 6.4.3\n");

return 0;
}

While you are correct that C99 has UCNs, please keep in mind that not all
characters need be supported.
The intent of UCN, was to provide a facility for e.g. the Asian
languages, to let them write strictly conforming programs using
characters outside the basic character set.

The only C99 like compiler I currently have access to is

gcc -std=c99

which on my installations, defines __STDC_ISO_10646__. I expect Unicode
characters to be supported, by the time we can start writing portable
programs in C99! Until then, it doesn't matter much (for me).
The only case I can think of where using \u0024 in character constants and/
or string literals makes sense is if the source character set is different
from the execution character set, and the dollar sign is only supported in
the latter. I suspect this is quite rare.
The way I picture it, isn't that programmers usually write these UCN
sequences by hand via U+NNNN. My keyboard has some special characters
too: "æøåÆØÅ", which I can access via a single keystroke.

However, if editing C source from another machine, e.g. using putty.exe
(getting a Linux login shell over SSH from Windows), those keystrokes
doesn't produce the expected result. Hence, I can't type

setlocale(LC_CTYPE, "")
printf("%ls\n", L"æøå"); <--- can't type

hard coding these Latin 1 characters doesn't work either:
printf("\xE6\xF8\xE5\n"); <--- display garbage

while, not only does this work:
printf("\u00e6\u00f8\u00e5\n"); <--- can type & display correctly

but can be typed from "everywhere".
And for readability, I would not recommend using it in
identifiers at all, even when it's allowed.
UTF-8 enabled editors, could be able to display the C source in a
readable way. IMO, the main advantage for restricting source to be
written in English, is that "anyone" can maintain the source afterwards,
but that may not be important to e.g. a Japanese SW company.

For readability

int år, aar, year;

'Ã¥r' is not only the most readable form for me, but is also the quickest
one to type (requires only two keystrokes). BTW, neither

int år, \u0005r;

works with latest GNU GCC, so UCN support appears to be broken. <g>

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Nov 11 '07 #5
Tor Rustad wrote:
int år, \u0005r;
ooops, a typo for:

int år, \u00e5r;

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Nov 11 '07 #6
On Sun, 11 Nov 2007 18:10:01 +0100, Tor Rustad wrote:
Harald van Dijk wrote:
>On Sat, 10 Nov 2007 01:51:15 +0100, Tor Rustad wrote:
>>Ben Pfaff wrote:
Paro <zu**********@gmail.comwrites:

Subject: how to get dollars($) in c
`$' is not in the basic source or execution character set and hence
cannot be used in portable C programs.
#include <stdio.h>

int main(void)
{
printf("C99 has UCN, so \u0024 can be used in identifiers, "
"character constants, and string literal. See
6.4.3\n");

return 0;
}

While you are correct that C99 has UCNs, please keep in mind that not
all characters need be supported.

The intent of UCN, was to provide a facility for e.g. the Asian
languages, to let them write strictly conforming programs using
characters outside the basic character set.
Almost, but not exactly. From the rationale:

[...] Thus, \unnnn can be used to designate a Unicode character. This
way, programs that must be fully portable may use virtually any
character from any script used in the world and still be portable,
provided of course that if it prints the character, the execution
character set has representation for it.

Fully portable programs can use \u00AA e.a. in identifiers, but fully
portable programs cannot meaningfully use \u00AA in character constants.
The only C99 like compiler I currently have access to is

gcc -std=c99
Consider adding -pedantic. With that option, you'll at least get gcc in a
mode where it attempts to conform to C99, even if it doesn't yet. And
also, see below.
which on my installations, defines __STDC_ISO_10646__. I expect Unicode
characters to be supported, by the time we can start writing portable
programs in C99! Until then, it doesn't matter much (for me).
__STDC_ISO_10646__ is optional, so an implementation might choose to not
support it at all. If it is defined on your implementation, great, you
can rely on it on your implementation, but only there.
>The only case I can think of where using \u0024 in character constants
and/ or string literals makes sense is if the source character set is
different from the execution character set, and the dollar sign is only
supported in the latter. I suspect this is quite rare.

The way I picture it, isn't that programmers usually write these UCN
sequences by hand via U+NNNN. My keyboard has some special characters
too: "æøåÆØÅ", which I can access via a single keystroke.

However, if editing C source from another machine, e.g. using putty.exe
(getting a Linux login shell over SSH from Windows), those keystrokes
doesn't produce the expected result. Hence, I can't type

setlocale(LC_CTYPE, "")
printf("%ls\n", L"æøå"); <--- can't type

hard coding these Latin 1 characters doesn't work either:
printf("\xE6\xF8\xE5\n"); <--- display garbage

while, not only does this work:
printf("\u00e6\u00f8\u00e5\n"); <--- can type & display correctly

but can be typed from "everywhere".
You're assuming the locale will always be the same every time the program
is run. It's better to use %ls as in your original version,

setlocale(LC_CTYPE, "");
printf("%ls\n", L"\u00e6\u00f8\u00e5");

to minimise this assumption. That said, it's a step up from requiring
L"æøå", but still, this will work on implementations that support those
characters, and won't on those that don't.
And for readability, I would not recommend using it in identifiers at
all, even when it's allowed.

UTF-8 enabled editors, could be able to display the C source in a
readable way.
Not unless you want to deal with the same problems again that you already
do: if an UTF-8 enabled editor automatically converts UCNs to/from UTF-8,
you might be able to enter L"\u00e6\u00f8\u00e5", but when reading it
back, if it tries to show L"æøå", it will quite likely give you garbled
output.
IMO, the main advantage for restricting source to be
written in English, is that "anyone" can maintain the source afterwards,
but that may not be important to e.g. a Japanese SW company.

For readability

int år, aar, year;

'Ã¥r' is not only the most readable form for me, but is also the quickest
one to type (requires only two keystrokes). BTW, neither

int år, \u0005r;

works with latest GNU GCC, so UCN support appears to be broken. <g>
The former doesn't work because there is no required automatic conversion
from any character to an UCN. An implementation may choose to do it in
translation phase 1, but it's in no way required. The latter doesn't work
because \u0005 is not a valid UCN (6.4.3p2), and even if it were, it's
not a valid character in identifiers (6.4.2.1p3).

int \u00e5r;

is valid C99. <OT>It "works" with GCC when you enable the option to
support UCNs in identifiers (-fextended-identifiers). This is not enabled
by default, IIRC because the implementation is incomplete and/or broken,
so choose your interpretation of "works".</OT>
Nov 11 '07 #7
Harald van Dijk wrote:
On Sun, 11 Nov 2007 18:10:01 +0100, Tor Rustad wrote:
>Harald van Dijk wrote:
>>On Sat, 10 Nov 2007 01:51:15 +0100, Tor Rustad wrote:
#include <stdio.h>

int main(void)
{
printf("C99 has UCN, so \u0024 can be used in identifiers, "
"character constants, and string literal. See
6.4.3\n");

return 0;
}
While you are correct that C99 has UCNs, please keep in mind that not
all characters need be supported.
The intent of UCN, was to provide a facility for e.g. the Asian
languages, to let them write strictly conforming programs using
characters outside the basic character set.

Almost, but not exactly. From the rationale:

[...] Thus, \unnnn can be used to designate a Unicode character. This
way, programs that must be fully portable may use virtually any
character from any script used in the world and still be portable,
provided of course that if it prints the character, the execution
character set has representation for it.

Fully portable programs can use \u00AA e.a. in identifiers, but fully
portable programs cannot meaningfully use \u00AA in character constants.
Point taken.

>The only C99 like compiler I currently have access to is

gcc -std=c99

Consider adding -pedantic. With that option, you'll at least get gcc in a
mode where it attempts to conform to C99, even if it doesn't yet. And
also, see below.
I have yet to write my first useful C99 program, but will keep your
advice in mind.

>which on my installations, defines __STDC_ISO_10646__. I expect Unicode
characters to be supported, by the time we can start writing portable
programs in C99! Until then, it doesn't matter much (for me).

__STDC_ISO_10646__ is optional, so an implementation might choose to not
support it at all. If it is defined on your implementation, great, you
can rely on it on your implementation, but only there.
So is __STDC_IEC_559__. To my mind, ISO 10646 is the natural choice for
internal representation of "wide" characters, and seems to be promoted
(but not required) by the standard.

[...]
You're assuming the locale will always be the same every time the program
is run. It's better to use %ls as in your original version,

setlocale(LC_CTYPE, "");
printf("%ls\n", L"\u00e6\u00f8\u00e5");
Agreed.
to minimise this assumption. That said, it's a step up from requiring
L"æøå", but still, this will work on implementations that support those
characters, and won't on those that don't.
When using common tools for file inter-change, I have watched national
characters in comments, become garbage for many years, so I continue to
write everything in English. Not so sure the Japanese agrees on doing
that. :)

> And for readability, I would not recommend using it in identifiers at
all, even when it's allowed.

UTF-8 enabled editors, could be able to display the C source in a
readable way.

Not unless you want to deal with the same problems again that you already
do: if an UTF-8 enabled editor automatically converts UCNs to/from UTF-8,
you might be able to enter L"\u00e6\u00f8\u00e5", but when reading it
back, if it tries to show L"æøå", it will quite likely give you garbled
output.
Context for me above, was identifiers, so I was thinking about the case
where programmer write & see "int år" the editor. In one mode, the
editor could store this identifier as "int \u00e5r" on file, while in
another mode, the editor save the source using UTF-8 encoding.

Disclaimer: I don't have detailed knowledge on how editors and C
processors handle multibyte sequence today, but I would suspect the
natural choice for external encoding (source files on disk) is UTF-8.

>IMO, the main advantage for restricting source to be
written in English, is that "anyone" can maintain the source afterwards,
but that may not be important to e.g. a Japanese SW company.

For readability

int år, aar, year;

'Ã¥r' is not only the most readable form for me, but is also the quickest
one to type (requires only two keystrokes). BTW, neither

int år, \u0005r;

works with latest GNU GCC, so UCN support appears to be broken. <g>

The former doesn't work because there is no required automatic conversion
from any character to an UCN. An implementation may choose to do it in
translation phase 1, but it's in no way required. The latter doesn't work
because \u0005 is not a valid UCN (6.4.3p2), and even if it were, it's
not a valid character in identifiers (6.4.2.1p3).
Sorry, \u0005 was a typo, I tried to correct it, but you where too quick. :)

IMO, using e.g. "int år" should be the way to go, and to archive it, the
implementation could use some specific translation at phase 1, e.g.
accepting UTF-8 encoded source, and/or the editor could save non-ASCII
character 'Ã¥' as \u00e5.

IMO, the important properties for people using non-English language, is

(1) C source can be exchanged in a portable way between systems
(2) editors save C source in a compatible encoding of what C compilers
accept.

int \u00e5r;

is valid C99. <OT>It "works" with GCC when you enable the option to
support UCNs in identifiers (-fextended-identifiers). This is not enabled
by default, IIRC because the implementation is incomplete and/or broken,
so choose your interpretation of "works".</OT>
I didn't know about the -fextended-identifiers switch.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Nov 12 '07 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Bill | last post by:
I have some variables that are supposed to display in dollars. While the value of the variable may be an interger, such as 1290 I would like it to display as $ 1,290.00 with the dollar sign, and...
2
by: Calvin | last post by:
Hi, I'm developing an eCommerce site and need to change the currency displayed from Dollars to Pounds. SqlServer field is set to Money. Then on Product List page, following code is used......
6
by: nyy | last post by:
I need help on this program, it have to convert cents to dollars when you enter #of cents. Thanks please anybody can help. Thanks.
3
by: nyy | last post by:
this program is supposed to give the user the ability to enter numbers in cents and tell you how many dollars you have. PLease anybody can tell me what's wrong. Thx. <!DOCTYPE html PUBLIC...
1
by: kritter | last post by:
-------------------------------------------------------------------------------- Hi, I have another focus group. This one is for females only. Can not work for an advertising agency,...
1
by: GinnyP | last post by:
Hi, Is there a way to convet $9.05, as entered, to "nine dollars and five cents" to print out on a check. Thanks GinnyP
3
by: mochatrpl | last post by:
I am looking for a way to make a query / report display the running average for total dollars. I have already set up a query to provide totals dollars per day from which a report graphly shows...
0
by: abcd | last post by:
http://www.parttimejobsu.blogspot.com/
0
by: honey | last post by:
Hi friends,please visit this site.it will help to us.www.financialservicesportal.blogspot.com
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.