Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   o/p problem (http://www.velocityreviews.com/forums/t440636-o-p-problem.html)

fidlee 12-23-2005 12:33 PM

o/p problem
 
what should be the ouptut of
printf("%d",'++');

the ascii value of + is 43... the output comes as 11051 in turboC... (i
was surprised it doesnt throw an error on compiling... ) someone
explain me as to how this output comes...


Pieter Droogendijk 12-23-2005 12:52 PM

Re: o/p problem
 
On Fri, 23 Dec 2005 04:33:33 -0800, fidlee wrote:

> what should be the ouptut of
> printf("%d",'++');
>
> the ascii value of + is 43... the output comes as 11051 in turboC...
> (i was surprised it doesnt throw an error on compiling... ) someone
> explain me as to how this output comes...


6.4.4.4 "Character constants" #10:
The value of an integer character constant containing more than one
character (e.g., 'ab'), or containing a character or escape sequence that
does not map to a single-byte execution character, is
implementation-defined.

In your case, 43 * 256 + 43.

--
Pieter Droogendijk <pieter at binky dot org dot uk>
PGP/1E92DBBC [ Make way for the Emperor's Finest. ] binky.org.uk


Robert Gamble 12-23-2005 01:00 PM

Re: o/p problem
 
fidlee wrote:
> what should be the ouptut of
> printf("%d",'++');
>
> the ascii value of + is 43... the output comes as 11051 in turboC... (i
> was surprised it doesnt throw an error on compiling... ) someone
> explain me as to how this output comes...


Character constants can contain multiple characters, the integer value
of which is implementation-defined. You will need to consult the
documentation that came with your compiler for the details but you
might observe the fact that 43*256+43=11051.

Robert Gamble


fidlee 12-23-2005 01:19 PM

Re: o/p problem
 
@ Robert

so u mean to say that this statement will behave differently on the
different compilers??
i also tried out
printf("%d",'+a'); and it gives 11105 on g++ (linux) and turboC
(windows) i dont think they are compiler dependednt...

Can someone please tell me as to why the compiler behaves in the
following way?? (43*256+43=11051)


Stefan Krah 12-23-2005 01:30 PM

Re: o/p problem
 
* fidlee <fidlee@gmail.com> wrote:
> what should be the ouptut of
> printf("%d",'++');
>
> the ascii value of + is 43... the output comes as 11051 in turboC... (i
> was surprised it doesnt throw an error on compiling... ) someone
> explain me as to how this output comes...


gcc gives this warning:

multichar.c:5:15: warning: multi-character character constant

Now you should be equipped for a Google search. ;)


Stefan Krah

--
Break original Enigma messages: http://www.bytereef.org/m4_project.html

Lew Pitcher 12-23-2005 01:44 PM

Re: o/p problem
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fidlee wrote:
> @ Robert
>
> so u mean to say that this statement will behave differently on the
> different compilers??
> i also tried out
> printf("%d",'+a'); and it gives 11105 on g++ (linux) and turboC
> (windows) i dont think they are compiler dependednt...


Certainly, the results will be compiler dependant. It's just that both
of your compilers give the same results :-)

Consider that the result depends on
- - the width (sizeof()) of a character constant (hint: it isn't
necessarily == 1)
- - the 'endianness' of a character constant (hint: it isn't necessarily
little-endian)
- - the characterset used to express characters in (hint: it isn't always
ASCII)

Think of what the differences might be between your results and the
results of the same program when compiled and run on a system with
- - 32bit integer values
- - big-endian integers
- - EBCDIC-US characterset

> Can someone please tell me as to why the compiler behaves in the
> following way?? (43*256+43=11051)


Because, on /your/ system, character constants are stored as 16bit
integer values, in the ASCII characterset. Since the ASCII for '+' is
binary 43, then the first '+' (being shifted left into the high-order 8
bits of your 16bit integer) becomes 43*256 (or 43 << 8). The second '+'
(not moving from the low-order position) becomes 43. And the combination
of the two (a 16bit integer, remember?) becomes (45*256)+43



- --

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFDq/8+agVFX4UWr64RAnAEAJ95BsHcGCYBqkvNRyHHzggeNFTPZwCe JvP6
ymeBG+DMNGdtX6rSOY+HKVI=
=Ra/t
-----END PGP SIGNATURE-----

fidlee 12-23-2005 01:50 PM

Re: o/p problem
 
true that it does give the multi character constant warning... but in
ends up giving the same o/p right ?? :)


Pieter Droogendijk 12-23-2005 01:54 PM

Re: o/p problem
 
On Fri, 23 Dec 2005 05:19:31 -0800, fidlee wrote:

> so u mean to say that this statement will behave differently on the
> different compilers??


Not quite. Different compilers, architectures, operating systems,
characters sets, etcetera.

> i also tried out
> printf("%d",'+a'); and it gives 11105 on g++ (linux)


g++ implies a C++ compiler, mind. You probably mean gcc.

> and turboC (windows) i dont think they are compiler dependednt...


It might do the same on a whole lot of compilers for Windows and Linux.
Try it on a few more systems, especially if they don't use ASCII.

Or better yet, try it on a mainframe.

> Can someone please tell me as to why the compiler behaves in the
> following way?? (43*256+43=11051)


Not I. Perhaps your compiler documentation or operating system manual can
help you there.

--
Pieter Droogendijk <pieter at binky dot org dot uk>
PGP/1E92DBBC [ Make way for the Emperor's Finest. ] binky.org.uk


Lew Pitcher 12-23-2005 01:58 PM

Re: o/p problem
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew Pitcher wrote:
> fidlee wrote:
>
>>>@ Robert
>>>
>>>so u mean to say that this statement will behave differently on the
>>>different compilers??
>>>i also tried out
>>>printf("%d",'+a'); and it gives 11105 on g++ (linux) and turboC
>>>(windows) i dont think they are compiler dependednt...

>
>
> Certainly, the results will be compiler dependant. It's just that both
> of your compilers give the same results :-)
>
> Consider that the result depends on
> - the width (sizeof()) of a character constant (hint: it isn't
> necessarily == 1)
> - the 'endianness' of a character constant (hint: it isn't necessarily
> little-endian)
> - the characterset used to express characters in (hint: it isn't always
> ASCII)
>
> Think of what the differences might be between your results and the
> results of the same program when compiled and run on a system with
> - 32bit integer values
> - big-endian integers
> - EBCDIC-US characterset


For example, here's a test on /my/ system

source code:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
printf("The character constant '++' == %d\n",'++');
return EXIT_SUCCESS;
}


execution results:

The character constant '++' == 20046


Of course, this was compiled and executed on an IBM OS/390 operating
system using the OS/390 C V2 R10 compiler (5647A01). OS/390 uses EBCDIC
variant charactersets, and the source code was written using the
EBCDIC-US variant.

[snip]

- --

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFDrAJ2agVFX4UWr64RAiFlAJ9Lqz5umtvPU9xWbKkFRy X85PXWZwCgiCYF
GAh416UYHPyruVU5PoEusow=
=RCUr
-----END PGP SIGNATURE-----

fidlee 12-23-2005 02:03 PM

Re: o/p problem
 
@Pieter
thanx for the help offered...
but i still do think that there must be some logic as to y the c
compiler behaves in this fashion...

if someone knows d logic, just let me know ...



All times are GMT. The time now is 08:59 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.