467,075 Members | 962 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,075 developers. It's quick & easy.

Is it standard and practical to use long long types?

Hi folks. Can you help with some questions?

I gather that some types supported by g++ are nonstandard but have been
proposed as standards.

Are the long long and unsigned long long types still under consideration
for the ANSI C and C++ standards? Are they likely to be accepted into
the standards?

Which compilers support those types, and which do not?

In a general practical sense, is portability impaired for programs that
use those types?

Is there any good literature on standard techniques related to word size
and portability?
________________________
keywords: gnu gcc g++ borland turbo visual microsoft intel ISO ANSI
compiler long long C C++ language standard

Jul 22 '05 #1
  • viewed: 5220
Share:
88 Replies
Matt wrote:
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.

I gather that some types supported by g++ are nonstandard but have been
proposed as standards.

Are the long long and unsigned long long types still under consideration
for the ANSI C and C++ standards? Are they likely to be accepted into
the standards?
long long (along with its variants) was added to C with the 1999 ISO
standard. C++ had not been updated with new features since 1998 (a 2003
update corrected and clarified the existing standard, but added nothing
new), and does not include long long. I don't know the details, but I'm
sure it has been discussed and may still be being discussed for
addition. I'd be surprised if it was not included in the next version of
the C++ standard.

Which compilers support those types, and which do not?
C99 compilers do. Other C and C++ compilers do not, unless through
extensions.

In a general practical sense, is portability impaired for programs that
use those types?
I would say so. C99 support is rather narrow at the moment.

Is there any good literature on standard techniques related to word size
and portability?


I don't understand this question.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #2

"Matt" <ma**@themattfella.zzzz.com> wrote in message

Are the long long and unsigned long long types still under
consideration for the ANSI C and C++ standards? Are they likely
to be accepted into the standards?
Traditionally an int is the size of a register, and registers can be used
either to hold addresses or data, so void * is also the same size as an int.
That rule of thumb is breaking down with 64-bit architectures, because
integers usually represent real numbers (say, the number of employees in a
company) and there are only a few cases where you need a number bigger than
4 billion.
long long looks like the most likely convention to emerge for the 64-bit
type. However it will be a long time before 32-bit architectures become
rare, or long long becomes so entrenched that they are forced to support it.
Is there any good literature on standard techniques related to word > size and portability?

Not that I know of. The main reason for using a 64-bit type is to represent
a size of memory, in which case you should use size_t. Just occasionally you
will need 64 bits for another purpose (eg give the entire population of the
world an id number). In that case there is no neat solution if the target
compiler won't support 64-bit types - you will have to define a structure
and write your own arithmetical routines. (In C++ it is easier because you
can wrap into a class). typedefing long long is probably a good idea if you
think this might happen.
Jul 22 '05 #3
Malcolm wrote:
"Matt" <ma**@themattfella.zzzz.com> wrote in message
Are the long long and unsigned long long types still under
consideration for the ANSI C and C++ standards? Are they likely
to be accepted into the standards?


Traditionally an int is the size of a register,


Not on 8-bit machines. It's a recommendation, not a requirement.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #4
Matt wrote:

Are the long long and unsigned long long types still under consideration
for the ANSI C and C++ standards? Are they likely to be accepted into
the standards?


The C standard has included [signed | unsigned] long long now into its
4th year.

Follow-ups set to comp.lang.c.
Jul 22 '05 #5
Kevin Goodsell wrote:
Matt wrote:

Is there any good literature on standard techniques related to word
size and portability?

I don't understand this question.

-Kevin


Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.

Jul 22 '05 #6
Matt wrote:

Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.


Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges. So if I need a variable that might exceed 32,767, I don't use an
int. In many cases, additional precision beyond what is needed is not
harmful, so choosing something guaranteed to be "wide enough" works just
fine.

When people have problems with the differences in precision that
different implementations may use, it's usually because they want to do
something that relies on variables using a particular representation and
size. For example, writing a value out to a file as raw bits, and
reading it back in later. The simple answer to this problem is "don't do
that". A file written that way isn't portable anyway. The right thing to
do is to define your file format, and write your program so that it
handles that format (by reading & writing byte-by-byte and
reconstructing/deconstructing values as you go if necessary -- though
differences in the size of a byte could potentially cause problems).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #7
Kevin Goodsell wrote:
Matt wrote:

Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.


Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges.


OMG. Is this my punishment for cross posting?

Jul 22 '05 #8
On Tue, 13 Apr 2004 00:10:35 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote in comp.lang.c:

"Matt" <ma**@themattfella.zzzz.com> wrote in message

Are the long long and unsigned long long types still under
consideration for the ANSI C and C++ standards? Are they likely
to be accepted into the standards?

Traditionally an int is the size of a register, and registers can be used
either to hold addresses or data, so void * is also the same size as an int.
That rule of thumb is breaking down with 64-bit architectures, because
integers usually represent real numbers (say, the number of employees in a
company) and there are only a few cases where you need a number bigger than
4 billion.


The correspondence in size between ints and registers has been broken
in many, many platforms over the years, long before 64-bit
architectures (other than Cray, perhaps) existed.

The assumption that sizeof(void *) == sizeof(int) is horrible broken
and a crutch for the uninformed or lazy, always has been, and always
will be.

I was working today, and will be for the next few weeks, on a platform
with quite a decent C compiler where int has 16 bits and pointers have
32. Not "far" pointers, but all pointers. At the hardware level,
addresses have 32 bits and there is a 4Gb address space.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jul 22 '05 #9
Matt <ma**@themattfella.zzzz.com> writes:
Kevin Goodsell wrote:
Matt wrote:

Is there any good literature on standard techniques related to word
size and portability?

I don't understand this question.
-Kevin


Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.


I've redirected followups to comp.lang.c.

C99 provides a standard header, <stdint.h>, that provides typedefs for
a variety of exact-width, minimum-width, and "fastest" signed and
unsigned integer types.

If your compiler doesn't support <stdint.h>, it's easy to implement
for any C90 compiler (except that it may or may not support 64-bit
types). See Doug Gwyn's public-domain q8 library, available at
<http://www.lysator.liu.se/c/q8/>.

Many pre-C99 compilers support "long long" and "unsigned long long" as
an extension, though it's not certain that the corresponding printf
formats will be supported by the library.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Jul 22 '05 #10
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Jul 22 '05 #11
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:c5**********@news-reader2.wanadoo.fr...
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type

Looking at the subject of your message, the answer is NO since there is not
such a thing as long long type in C++. Next time do not cross post among
irrelevant newsgroups, C & C++ are different languages.


Ioannis Vranos

Jul 22 '05 #12
Ioannis Vranos wrote:
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:c5**********@news-reader2.wanadoo.fr...
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type


Looking at the subject of your message, the answer is NO since there is not
such a thing as long long type in C++. Next time do not cross post among
irrelevant newsgroups, C & C++ are different languages.


Ioannis Vranos


Next time reply to the same person you seem to be addressing.

Next time don't post using weirdo fonts.

Next time try to give a reply that is useful to somebody.

Jul 22 '05 #13
Kevin Goodsell wrote:
Matt wrote:
Hi folks. Can you help with some questions?

Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.


I cross-posted because I am asking the questions about both languages.

Jul 22 '05 #14
Matt <ma**@themattfella.zzzz.com> scribbled the following
on comp.lang.c:
Ioannis Vranos wrote:
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:c5**********@news-reader2.wanadoo.fr...
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Looking at the subject of your message, the answer is NO since there is not
such a thing as long long type in C++. Next time do not cross post among
irrelevant newsgroups, C & C++ are different languages.

Next time reply to the same person you seem to be addressing. Next time don't post using weirdo fonts. Next time try to give a reply that is useful to somebody.


Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio
Jul 22 '05 #15

"Matt" <ma**@themattfella.zzzz.com> wrote in message
news:OB****************@news01.roc.ny...
Hi folks. Can you help with some questions?

I gather that some types supported by g++ are nonstandard but have been
proposed as standards.

Are the long long and unsigned long long types still under consideration
for the ANSI C and C++ standards? Are they likely to be accepted into
the standards?

Which compilers support those types, and which do not?

In a general practical sense, is portability impaired for programs that
use those types?
Even a program using only long is not portable (in the sense that it will
always work correctly).

The only thing that the standard gaurantees (I can't find the reference) is
that int is at least 32 bits.

Therefore if you require an integer > 32 bits the only way for your program
to be
totally portable is to write your own 'BigInteger' class.

Note that you can't even portably check stuff with the preprocessor because
#if LONG_MAX < 73624963649249264926492
Is just not going to work if LONG_MAX is only 2^31-1 (I would hope for a
compiler error)

If you limit portability to machines known to support 64 bits then it is
near certainty that
long will be 64 bits - but check with the preprocessor.

If you want more than 64 bits you are unlikely to be portable to many
machines whether the
compiler supports long long or not.
I would suggest that you try:
#ifdef LONG_LONG_MAX
(or LONGLONG_MAX? )


Is there any good literature on standard techniques related to word size
and portability?
________________________
keywords: gnu gcc g++ borland turbo visual microsoft intel ISO ANSI
compiler long long C C++ language standard

Jul 22 '05 #16
In <c5**********@news8.svr.pol.co.uk> "Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

"Matt" <ma**@themattfella.zzzz.com> wrote in message

Are the long long and unsigned long long types still under
consideration for the ANSI C and C++ standards? Are they likely
to be accepted into the standards?

Traditionally an int is the size of a register,


This "tradition" has been broken so many times that it ceased being a
tradition long ago. The standard simply doesn't allow it for 8-bit
systems and it is very impractical for many 64-bit systems.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Jul 22 '05 #17
Matt <ma**@themattfella.zzzz.com> writes:
Kevin Goodsell wrote:
Matt wrote:
Hi folks. Can you help with some questions?

Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
thing to do. While related, these languages are different enough
that answers for one frequently don't apply to the other.


I cross-posted because I am asking the questions about both languages.


Then it probably would have been better to post separately to each
newsgroup, since you're really asking two separate (but indirectly
related) questions.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Jul 22 '05 #18
In <OB****************@news01.roc.ny> Matt <ma**@themattfella.zzzz.com> writes:
I gather that some types supported by g++ are nonstandard but have been
proposed as standards.

Are the long long and unsigned long long types still under consideration
for the ANSI C and C++ standards? Are they likely to be accepted into
the standards?
The C99 standard has adopted them, there is no C++ standard supporting
them, AFAIK. Note, however, that the vast majority of C implementations
in current use do NOT support the C99 standard. At best, they support
a subset of C99 in extended mode. And, of course, each supports a
*different* subset of C99.
Which compilers support those types, and which do not?
It's not only a matter of compiler support, it's also a matter of
library support (not every compiler comes with its own libraries).
In a general practical sense, is portability impaired for programs that
use those types?
Yes. A C89 compiler *must* diagnose long long as a syntax error when
invoked in conforming mode. And if you invoke it with extensions enabled
you don't have much control over what other "goodies" you get along with
the long long support and what parts of your program they can (silently)
break.
Is there any good literature on standard techniques related to word size
and portability?


Each C type has a guaranteed minimal range. If you can afford using only
types whose minimal range is enough for your purposes, your application
is portable.

This is the most elegant approach, but not always the most practical
(using long when you need a 32-bit type is wasteful on platforms with
64-bit longs if you need very large arrays of that type).

Since each implementation must define the range of each standard type
in <limits.h> and <float.h>, you can use the preprocessor to discover
the minimal types that satisfy your needs on a given implementation
and use your own typedef names for them. Use your typedef's when
declaring your own variables. The drawback is that the code becomes less
readable when you don't know the exact type that is behind each variable
and it is also fairly easy to introduce very obscure bugs, this way. So,
restrict this approach to the variables that *really* need it.

C99 comes with a standard set of such typedef's, so you may want to use
the same names in your code, rather than reinventing the wheel. Have a
look at the specification of <stdint.h>.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Jul 22 '05 #19
Matt wrote:
Kevin Goodsell wrote:
Matt wrote:
Hi folks. Can you help with some questions?


Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
thing to do. While related, these languages are different enough that
answers for one frequently don't apply to the other.

I cross-posted because I am asking the questions about both languages.


But they are different languages, so they are two different questions,
with different answers. You wouldn't cross-post a message to a baking
group and an astronomy group just because you had a question about each,
would you?

You'll annoy fewer people and get better results if you follow my
advice. If nothing else, having two separate threads in different groups
makes it easier to spot messages you didn't read yet, and it's generally
less confusing for a number of reasons.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #20
Matt wrote:

Next time reply to the same person you seem to be addressing.

Next time don't post using weirdo fonts.

Next time try to give a reply that is useful to somebody.


You are being very rude. There was nothing wrong with Ioannis's message
(as far as I can see), and it's not his fault that the person he replied
to didn't include any context to clue him in to who originally asked the
question.

As for the usefulness of replies, as I've already said you can improve
this by posting appropriately (e.g., not cross-posting between
comp.lang.c and comp.lang.c++). And Ioannis's reply was worth every cent
you paid for it and more.

Keep this up and you'll find it difficult to get good responses in the
future.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #21
On Tue, 13 Apr 2004 03:06:55 +0000, Matt wrote:
Kevin Goodsell wrote:
Matt wrote:

Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.


Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges.


OMG. Is this my punishment for cross posting?


Yes :)

Seriously thogh, you now know that you can't have long long unless you
limit yourself to C99 compilers or C89 compilers with long long as an
extension, or C++ compilers with long long as an extension.
Now is the time for a new post (or two new posts if you want ansers
for both C and C++) where you tell us what you want to achieve and ask
about how to do it.

Something along the lines of

Q: I want to shuffle around data in 64 bit chunks
A: Use an array of bytes

Q: I want to do calculations on integers that require more than 32
bits of storage.
A: Look at bigint libraries, or roll your own.
Seriously these two groups is a great place to ask about how to do
anything in a compiler-independent standards-compliant way, the hard
part is phrasing the question right.

--
NPV

What did that old blonde gal say? -- That is the part you throw away.
Tom Waits - The part you throw away

Jul 22 '05 #22
Nick Hounsome wrote:

The only thing that the standard gaurantees (I can't find the reference) is
that int is at least 32 bits.


There is a good reason that you can't find the reference: your
assertion is wrong.

Jul 22 '05 #23
Martin Ambuhl wrote:
Nick Hounsome wrote:

The only thing that the standard gaurantees (I can't find the
reference) is
that int is at least 32 bits.

There is a good reason that you can't find the reference: your
assertion is wrong.


True. 'int' is only required to be at least 16 bits. There are also
numerous other guarantees: 'char' must be at least 8 bits, 'long' must
be at least 32, certain types may not have greater precision than
others, etc.

The size requirements are, as far as I know, not stated explicitly, but
are implied from other requirements. In particular, restrictions on how
integers may be represented, plus the required minimum ranges for the
integer types (e.g. -32,767 to 32,767 for 'int'), imply that they must
have at least some easily determined number of bits.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #24
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:c5**********@oravannahka.helsinki.fi...
Matt <ma**@themattfella.zzzz.com> scribbled the following
on comp.lang.c:
Ioannis Vranos wrote:
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:c5**********@news-reader2.wanadoo.fr...
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type

Looking at the subject of your message, the answer is NO since there is not such a thing as long long type in C++. Next time do not cross post among irrelevant newsgroups, C & C++ are different languages.

Next time reply to the same person you seem to be addressing.

Next time don't post using weirdo fonts.

Next time try to give a reply that is useful to somebody.


Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?

The strange thing is that in my Outlook Express preferences (both the Read
and Send section) i have set Western European (ISO) encoding. It is nice
that my MS program does what i have told it to do. :-)


Ioannis Vranos

Jul 22 '05 #25
"Matt" <ma**@themattfella.zzzz.com> wrote in message
news:oJ****************@news02.roc.ny...
Kevin Goodsell wrote:
Matt wrote:
Hi folks. Can you help with some questions?

Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.


I cross-posted because I am asking the questions about both languages.

There is no long long in C++98 standard. I also hope that there will not be
one in C++0x.


Regards,

Ioannis Vranos

Jul 22 '05 #26

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5**********@ulysses.noc.ntua.gr...
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:c5**********@oravannahka.helsinki.fi...
Matt <ma**@themattfella.zzzz.com> scribbled the following
on comp.lang.c:
Ioannis Vranos wrote:
> "jacob navia" <ja***@jacob.remcomp.fr> wrote in message
> news:c5**********@news-reader2.wanadoo.fr...
>>lcc-win32 supports long long. The non-standard
>>__int64
>>is supported to maintain compatibility with Microsoft Visual C.
>>It is a 64 bit integer type
>
> Looking at the subject of your message, the answer is NO since there
is
not> such a thing as long long type in C++. Next time do not cross post among> irrelevant newsgroups, C & C++ are different languages.

Next time reply to the same person you seem to be addressing.

Next time don't post using weirdo fonts.

Next time try to give a reply that is useful to somebody.


Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?

The strange thing is that in my Outlook Express preferences (both the Read
and Send section) i have set Western European (ISO) encoding. It is nice
that my MS program does what i have told it to do. :-)

However in the new message window in Format::Encoding menu it had Greek as
preselected, i changed it to one message to Westen European (ISO) and now it
seems to remember it. Nice...


Ioannis Vranos

Jul 22 '05 #27
Ioannis Vranos wrote:
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5**********@ulysses.noc.ntua.gr...
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:c5**********@oravannahka.helsinki.fi...
Matt <ma**@themattfella.zzzz.com> scribbled the following
on comp.lang.c:

Ioannis Vranos wrote:

>"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
>news:c5**********@news-reader2.wanadoo.fr...
>
>>lcc-win32 supports long long. The non-standard
>>__int64
>>is supported to maintain compatibility with Microsoft Visual C.
>>It is a 64 bit integer type
>
>Looking at the subject of your message, the answer is NO since there


is
not
>such a thing as long long type in C++. Next time do not cross post


among
>irrelevant newsgroups, C & C++ are different languages.

Next time reply to the same person you seem to be addressing.

Next time don't post using weirdo fonts.

Next time try to give a reply that is useful to somebody.

Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?

The strange thing is that in my Outlook Express preferences (both the Read
and Send section) i have set Western European (ISO) encoding. It is nice
that my MS program does what i have told it to do. :-)


However in the new message window in Format::Encoding menu it had Greek as
preselected, i changed it to one message to Westen European (ISO) and now it
seems to remember it. Nice...


Ioannis Vranos


The post to which I am now replying appears to me in a normal-size font.
Your first post showed up tiny in my browser (Mozilla 1.4.1).

Jul 22 '05 #28
"Matt" <ma**@themattfella.zzzz.com> wrote in message
news:4D****************@news02.roc.ny...


The post to which I am now replying appears to me in a normal-size font.
Your first post showed up tiny in my browser (Mozilla 1.4.1).

And entirely off topic in this world, i strongly suggest Mozilla Firefox.
It is my default browser now and i do not switch any kind of programs so
easily. Definetely it is worth to check it out.


Ioannis Vranos

Jul 22 '05 #29
Keith Thompson wrote:
Matt <ma**@themattfella.zzzz.com> writes:
Kevin Goodsell wrote:
Matt wrote:
Hi folks. Can you help with some questions?

Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
thing to do. While related, these languages are different enough
that answers for one frequently don't apply to the other.


I cross-posted because I am asking the questions about both languages.

Then it probably would have been better to post separately to each
newsgroup, since you're really asking two separate (but indirectly
related) questions.


Thank you. I see your point.

I often find it useful to understand one language in terms of the other.

Jul 22 '05 #30
"Matt" <ma**@themattfella.zzzz.com> wrote in message
news:C6****************@news02.roc.ny...

I often find it useful to understand one language in terms of the other.

C and C++ follow two different evolution paths, e.g. C99 provides a complex
type as a built in "exotic" type, while C++98 provides a complex type as
part of the standard library, which can be defined using the core language
(as a template).


Ioannis Vranos

Jul 22 '05 #31
Ioannis Vranos wrote:
C and C++ follow two different evolution paths,
?
e.g. C99 provides a complex type as a built in "exotic" type
while C++98 provides a complex type as part of the standard library
which can be defined using the core language (as a template).


What does the C++03 [draft] standard say about type complex?
Does anything prevent C++ from "absorbing" the C99 complex type?

Jul 22 '05 #32
Nils Petter Vaskinn wrote:
Now is the time for a new post (or two new posts if you want ansers
for both C and C++) where you tell us what you want to achieve and ask
about how to do it.


Done. See my new post to comp.lang.c++ at 16:19 CST.

Jul 22 '05 #33
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:40************@jpl.nasa.gov...
Ioannis Vranos wrote:
C and C++ follow two different evolution paths,
?
e.g. C99 provides a complex type as a built in "exotic" type
while C++98 provides a complex type as part of the standard library
which can be defined using the core language (as a template).


What does the C++03 [draft] standard say about type complex?


Nothing that wasn't said in C++98.
Does anything prevent C++ from "absorbing" the C99 complex type?


Nope, and in fact it just did (sort of). At the meeting last month
in Sydney the committee voted to add *all* the library stuff added
with C99 to the (non-normative) Library TR scheduled for completion
this fall (northern hemisphere). It's done in such a way that you
can write essentially equivalent code using either the builtin
complex of C99 or the template class library version in C++.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #34
"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:sB*******************@nwrddc03.gnilink.net...

Does anything prevent C++ from "absorbing" the C99 complex type?

Nope, and in fact it just did (sort of). At the meeting last month
in Sydney the committee voted to add *all* the library stuff added
with C99 to the (non-normative) Library TR scheduled for completion
this fall (northern hemisphere). It's done in such a way that you
can write essentially equivalent code using either the builtin
complex of C99 or the template class library version in C++.

And where and why the C99 "library" complex type and similar stuff are
needed in C++?


Ioannis Vranos

Jul 22 '05 #35
Kevin Goodsell wrote:
You are being very rude. Keep this up and you'll find it difficult to get good responses in the
future.

-Kevin
Okay, sorry. Please don't deprive me of gems like:
Well, the general technique is to know the required minimum ranges of the types and write code that doesn't rely on anything beyond those ranges.

Jul 22 '05 #36
I already needed unsigned long long in a GNU C++ program. It was a good
spare of programming time in comparisson to using some external "big
integer" libraries.

--
Best regards,
Alex.

PS. To email me, remove "loeschedies" from the email address given.
Jul 22 '05 #37
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr...
"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:sB*******************@nwrddc03.gnilink.net...

Does anything prevent C++ from "absorbing" the C99 complex type?

Nope, and in fact it just did (sort of). At the meeting last month
in Sydney the committee voted to add *all* the library stuff added
with C99 to the (non-normative) Library TR scheduled for completion
this fall (northern hemisphere). It's done in such a way that you
can write essentially equivalent code using either the builtin
complex of C99 or the template class library version in C++.

And where and why the C99 "library" complex type and similar stuff are
needed in C++?


C99 defines a handful of complex functions not defined in Standard C++.
The Library TR (aka TR1) adds these functions to C++.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #38
"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:yn******************@nwrddc01.gnilink.net...
And where and why the C99 "library" complex type and similar stuff are
needed in C++?


C99 defines a handful of complex functions not defined in Standard C++.
The Library TR (aka TR1) adds these functions to C++.

Wouldn't it better if these functions would be new member functions of the
existing complex class?



Ioannis Vranos

Jul 22 '05 #39
Ioannis Vranos wrote:
"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:yn******************@nwrddc01.gnilink.net...
>

And where and why the C99 "library" complex type and similar stuff are
needed in C++?


C99 defines a handful of complex functions not defined in Standard C++.
The Library TR (aka TR1) adds these functions to C++.


Wouldn't it better if these functions would be new member functions of the
existing complex class?


Amazing. How far can somebody be out of touch with one of the original
essential major design criteria of C++? I am not referring to Mr.
Plauger or any of the committee members.

Jul 22 '05 #40
Ioannis Vranos wrote:
"Matt" <ma**@themattfella.zzzz.com> wrote in message
news:4D****************@news02.roc.ny...

The post to which I am now replying appears to me in a normal-size font.
Your first post showed up tiny in my browser (Mozilla 1.4.1).


And entirely off topic in this world, i strongly suggest Mozilla Firefox.
It is my default browser now and i do not switch any kind of programs so
easily. Definetely it is worth to check it out.


I use Firefox myself, but I think he mis-spoke when he said "browser".
He was probably referring to his news client (Mozilla is both, and
more). Firefox is, of course, only a web browser. I also use
Thunderbird, the stand-alone version of Mozilla's mail and news client.

In any case, the actual problem is the fonts used by Mozilla,
apparently. I know you can adjust them in Thunderbird, and I'm sure you
can in Mozilla as well. I've seen different fonts used for unusual
character sets before, but it should be easy to fix.

Incidentally Mozilla 1.4.1 is a bit old now. 1.7 is in beta, I think.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #41
Matt wrote:

Okay, sorry. Please don't deprive me of gems like:
Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges.



Perhaps a more specific question would have gotten a more satisfactory
answer. I'm not psychic, and I cannot guess exactly what you want to do
or what your level of knowledge and experience is. So I answered the
question you asked. If you don't like the answer... well, I'd be happy
to refund the money you paid for it.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #42

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:7X****************@newsread1.news.pas.earthli nk.net...
Martin Ambuhl wrote:
Nick Hounsome wrote:

The only thing that the standard gaurantees (I can't find the
reference) is
that int is at least 32 bits.

There is a good reason that you can't find the reference: your
assertion is wrong.


True. 'int' is only required to be at least 16 bits. There are also
numerous other guarantees: 'char' must be at least 8 bits, 'long' must
be at least 32, certain types may not have greater precision than
others, etc.

The size requirements are, as far as I know, not stated explicitly, but
are implied from other requirements. In particular, restrictions on how
integers may be represented, plus the required minimum ranges for the
integer types (e.g. -32,767 to 32,767 for 'int'), imply that they must
have at least some easily determined number of bits.


Help me out here - what;s the std reference? The index is useless.
Jul 22 '05 #43
Nick Hounsome wrote:
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:7X****************@newsread1.news.pas.earthli nk.net...
The size requirements are, as far as I know, not stated explicitly, but
are implied from other requirements. In particular, restrictions on how
integers may be represented, plus the required minimum ranges for the
integer types (e.g. -32,767 to 32,767 for 'int'), imply that they must
have at least some easily determined number of bits.

Help me out here - what;s the std reference? The index is useless.


5.2.4.2.1 Sizes of integer types <limits.h>
Jul 22 '05 #44
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message news:<c5**********@ulysses.noc.ntua.gr>...
There is no long long in C++98 standard. I also hope that there will not be
one in C++0x. Regards,

Ioannis Vranos

Why not?
Jul 22 '05 #45
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message news:<c5**********@ulysses.noc.ntua.gr>...
-posted because I am asking the questions about both languages.


There is no long long in C++98 standard. I also hope that there will not be
one in C++0x.
Regards,

Ioannis Vranos


Why do you hope so?
Jul 22 '05 #46

On Tue, 13 Apr 2004, Ioannis Vranos wrote:

There is no long long in C++98 standard. I also hope that there will
not be one in C++0x.


C++0x will introduce not only "long long int," but also "signed signed
int" for those numerical applications requiring extremely positive and/or
extremely negative numbers, and probably "short short int" for the
convenience of embedded programmers.
(There is also an extremely vocal contingent pushing for the adoption of
the "do do" control structure, but it's way past their bedtime.)

-Arthur,
insert "embed" joke here
Jul 22 '05 #47
In <c5**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:
lcc-win32 supports long long.


Unfortunately, it does it at the expense of not being conforming to any
C standard. long long is a syntax error in C89 and lcc-win32 is NOT a
conforming C99 implementation, either. So, I have yet to figure out
what -ansic means to the lc and lcc commands.

Then again, this is only one droplet in the ocean of lcc-win32 conformance
problems...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Jul 22 '05 #48
In <oJ****************@news02.roc.ny> Matt <ma**@themattfella.zzzz.com> writes:
Kevin Goodsell wrote:
Matt wrote:
Hi folks. Can you help with some questions?

Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.


I cross-posted because I am asking the questions about both languages.


This is still not the right thing. Post the question separately in both
newsgroups and compare the C answers and the C++ answers.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Jul 22 '05 #49
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:

On Tue, 13 Apr 2004, Ioannis Vranos wrote:

There is no long long in C++98 standard. I also hope that there will
not be one in C++0x.
C++0x will introduce not only "long long int," but also "signed signed
int" for those numerical applications requiring extremely positive and/or
extremely negative numbers, and probably "short short int" for the
convenience of embedded programmers.
(There is also an extremely vocal contingent pushing for the adoption of
the "do do" control structure, but it's way past their bedtime.)

-Arthur,
insert "


AFAIK the dodo concept already died out. However, I'm very
interested in the new additional meanings of 'static'.
" joke here

--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
Jul 22 '05 #50
88 Replies

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.