gamedevlists-general — List for discussing general game development issues

[GD-General] Graphic Library and market share

[Sebastian U. <li...@in...>]

###
Note: Sorry if this appears twice, i first sent it with another email 
address (not subscripted to the list) but it's still awaiting moderator 
approval
###

Hi,

   We're making some small puzzle game for Win32 to be (hopefully) 
distributed online. We're currently using SDL (as we had planned to make 
it easily portable), but some problems with it are slowing down our 
development (timer granularity and slow alpha blitting mostly).
   So we're thinking in using DirectX for now, and later care about 
other platforms. I wanted to get some idea about the installed base of 
DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or DX7 
must come with W2K. We don't care a lot about W98 right now (¿Should 
we?). Our programmers say DX8 will be easier to use tan DX7, but I'm 
worried it will restrict our market share, as we're not targeting 
hardcore gamers (with the latest in machine and OS).

   ¿What's your experience with this? Any comment will be appreciated!

PD: I believe OpenGL would probably be well suited also, but the main 
programmer in this proyect feels more comfortable with DX.

   Thanks

-- 
///
Sebastián Uribe
Inmune Games
su...@in...
www.inmune.com.ar

RE: [GD-General] The joy of type aliasing and C

[Simon O'C. <si...@sc...>]

There's some interesting discussion about VC++ standards compliance =
here:

http://msdn.microsoft.com/chats/vstudio/vstudio_022703.asp=20

"Q: Follow-up on the C99 "varargs" question, what, if anything, from C99
will we see in the future from VC

A: In general, we have seen little demand for many C99 features. Some
features have more demand than others, and we will consider them in =
future
releases provided they are compatible with C++. It is more likely we'll
entertain C99 features if they are picked up in the next version of the =
C++
standard."


http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/vccore=
/html
/vcrefwhatsnewlibrariesvisualc70.asp

"Because the timing of the release of C99, this version of Visual C++ is =
not
conformant with that standard."=20


There aren't many other references to C99 compliance on MSDN, so they =
aren't
even really claiming partial conformance. Probably have to wait for =
Whidbey
for stdint.h and inttypes.h.


> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Brian Hook
> Sent: 04 January 2004 17:31
> To: gam...@li...
> Subject: Re: [GD-General] The joy of type aliasing and C
>=20
> > Erm, are you sure about that?=20
>=20
> Nope, but my assumption has been that any compiler released=20
> since 2000 on should have those, since it's not exactly=20
> difficulty technology to produce.
>=20
> I know that GCC definitely has it, and I'm assuming=20
> CodeWarrior as well.  I'd be flatout flabbergasted if they=20
> didn't have it in MSVC 7.x, but then again...I guess I wouldn't. =3D)
>=20
> I don't blame a compiler vendor for being slow to implement=20
> some of the more radical features, like variable length=20
> arrays, variable argument macros, __func__, etc. but stdint.h=20
> and inttypes.h are trivial to implement.
>=20
> Brian
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign=20
> up for IBM's Free Linux Tutorials.  Learn everything from the=20
> bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003
=20

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> Erm, are you sure about that? 

Nope, but my assumption has been that any compiler released since 2000 
on should have those, since it's not exactly difficulty technology to 
produce.

I know that GCC definitely has it, and I'm assuming CodeWarrior as 
well.  I'd be flatout flabbergasted if they didn't have it in MSVC 
7.x, but then again...I guess I wouldn't. =3D)

I don't blame a compiler vendor for being slow to implement some of 
the more radical features, like variable length arrays, variable 
argument macros, __func__, etc. but stdint.h and inttypes.h are 
trivial to implement.

Brian

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

Erm, are you sure about that? Can't verify other compilers ATM, but for VC++
7.1 I can't find anything like that either in the docs or in the include
directory.

Alen

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Saturday, January 03, 2004 16:13
Subject: Re: [GD-General] The joy of type aliasing and C


> This sounds like a good news. Which compilers support those?

Any that claim C99 compliance.  While there are no 100% C99 compliant
compilers out there, there are a lot of "mostly compliant" ones.  GCC,
VC++ 7.x, Intel C/C++, Borland, etc. should all support <stdint.h> and
<inttypes.h>

Brian

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> - Overlaying an lvalue with multiple types (a.k.a. type punning) "

This is what it does, and it DOES compile, because it's legal syntax, 
just like pointer casting between incompatible types in C.  But just 
because it compiles doesn't mean that the standard guarantees it will 
run like you expect =3D)

Brian

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> This sounds like a good news. Which compilers support those?

Any that claim C99 compliance.  While there are no 100% C99 compliant 
compilers out there, there are a lot of "mostly compliant" ones.  GCC, 
VC++ 7.x, Intel C/C++, Borland, etc. should all support <stdint.h> and 
<inttypes.h>

Brian

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

>int x = ( int & ) f;
>int x = * ( int * ) &f;
>In the above, both the 'f' are considered lvalues, since they are
>expressions with an object type.

I thought so. :/

>> The reinterpret_cast operator is _designed_ to be used for type
>> punning, isn't it?
>Typically only for modifying pointer types, e.g. derived pointer to
>base class, etc.
But it does compile without errors when used to do type punning (FWIK).
Weirdo. Is there some statement in the standard, ignored by compilers, that
says it shouldn't?

I'm not reading the standard, but some Deep C++ articles, saying:

"While the Standard gives static_cast a sweeping general property plus a
complicated set of exceptions, it limits reinterpret_cast to two fundamental
roles:
- Conversions to and from pointers
- Overlaying an lvalue with multiple types (a.k.a. type punning) "

So maybe that creates some confusion. Is the statement above correct?

Alen

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

Whoops, pardon my ignorance!
This sounds like a good news. Which compilers support those?

Alen

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Wednesday, December 31, 2003 5:51 PM
Subject: Re: [GD-General] The joy of type aliasing and C


> but for sanity sake, standards could just add int16, int32 etc. and
> get over with the mess. Am I wrong?

They already have.  As of C99, there's <stdint.h> and <inttypes.h>
which had a host of types, including int16_t, uint32_t, etc.  There
are also "fast" versions that are "at least this size, but may be
larger", and constant macros for 64-bit values.

Brian




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

[GD-General] <limits.h>

[Brian H. <ho...@py...>]

Anyone know off-hand of any compilers that don't include <limits.h> 
and/or have broken implementations of <limits.h>?  This is assuming 
post-C89, so 'pcc' and other 1970s compilers don't count =3D)

Brian

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> would work just as well. Now, this depends on definition of lvalue.

>From 6.3.2.1:

"An lvalue is an expression with an object type or an incomplete type 
other than void; if an lvalue does not designate an object when it is 
evaluated, the behavior is undefined....a modifiable lvalue is an 
lvalue that does not have array type, does not have an incomplete 
type, does not have a const-qualified type, and if it is a structure 
or union, does not have any member with a const-qualified type."

>From footnote 53:

"The name 'lvalue' comes originally from the assignment expression E1 
=3D E2, in which the left operand E1 is required be a (modifiable) 
lvalue."

> Perhaps (const int &) might be considered an lvalue, but according

int x =3D ( int & ) f;
int x =3D * ( int * ) &f;

In the above, both the 'f' are considered lvalues, since they are 
expressions with an object type.  

> What might be of more interest is: What does C++98 say on using
> reinterpret_cast?
>
> i =3D reinterpret_cast<int&>(f);

That is semantically identical to a direct cast as in C and is equally 
unsafe since there is no guarantee that the bit representation of 'f' 
will be meaningful as an integer.

That said, it does work on the compilers I've tried =3D)

> The reinterpret_cast operator is _designed_ to be used for type
> punning, isn't it?

Typically only for modifying pointer types, e.g. derived pointer to 
base class, etc.

Brian

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> but for sanity sake, standards could just add int16, int32 etc. and
> get over with the mess. Am I wrong?

They already have.  As of C99, there's <stdint.h> and <inttypes.h> 
which had a host of types, including int16_t, uint32_t, etc.  There 
are also "fast" versions that are "at least this size, but may be 
larger", and constant macros for 64-bit values.

Brian

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

>> Generally, trying to look at a float as if it's some kind of a
>> black box that stores real numbers, is kinda silly.
>I think this depends entirely on the application's domain.  A lot of
>applications will merrily use a float and perform floating point
>operations and have no care at all whether the underlying
>implementation is IEEE-754 or some freakish VAX implementation.

True, but I happen to work in such domain that just I have to care. But I
guess we all do. ;)

>You can inspect an implementation's internal representation by using
><float.h> and inspecting the associated predefined constants.  These
<...>
I am aware of that, but I don't find it particularly useful, except for
stuff like: assert(FLT_MANT_DIG>=24). Honestly, have you ever made an app
that dynamically adjust itself depending on number of bits in mantissa? Most
code I see uses things like typedef int INT32; and adjusts it with #ifs for
different platforms. Not to say that a generic int shouldn't be available,
for people that want it, but for sanity sake, standards could just add
int16, int32 etc. and get over with the mess. Am I wrong?

Alen

Re: [GD-General] The joy of type aliasing and C

[Colin F. <cp...@ea...>]

>>> that claim to adhere to it.  These will give you the min, max,
>>> radix (FLT_RADIX), precision in digits (FLT_DIG), etc.
>>>
>>> I feel so ashamed for knowing this stuff...

Well, maybe you'd feel a little less ashamed if you took a
look at Section 2.1 of Game Programming Gems 2: 
"Floating-Point Tricks: Improving Performance with IEEE
Floating Point" (Yossarian King, Electronic Arts Canada).
It's 14 pages of this stuff!

It begins like this (which is "aliasing" not "punning", right?):

  typedef union
  {
  int   i;
  float f;
  } INTORFLOAT;

The author points out that "(int)f" costs about 60 cycles
on a Pentium II, and then shows the following faster code:

  INTORFLOAT  n;     // floating-point number to convert
  INTORFLOAT  bias;  // "magic" number

  bias.i = (23 + 127) << 23; // bias constant = 1 x 2^23
  n.f = 123.456f;            // some floating-point number

  n.f += bias.f; // add as floating-point
  n.i -= bias.i; // subtract as integer
  // n.i is now 123 - the integer portion of the original n.f

The author says this reduces the conversion time from 60 cycles
to about 5 cycles (assuming everything is in cache).  Wow!

Later in the article the author mentions a fast absolute
value:

  INTORFLOAT  ftmp;
  ftmp.f = f;
  ftmp.i &= 0x7fffffff;
  f = ftmp.f;

But I'm not sure how this compares with the inline __fabs()
instruction.

The author shows an improved version of the old square-root
trick (bit shift followed by add), taking about 16 cycles 
instead of 80 on a Pentium II; five times faster.

The Intel "Software Optimization Cookbook" (2002) has fun items
like this:

  float FastSqrt( float f )   // roughly 5% error
  {
    float RetVal;
    __asm
      {
      mov  eax, f
      sub  eax, 0x3f800000
      sar  eax, 1
      add  eax, 0x3f800000
      mov  RetVal, eax
      }
  return RetVal;
  }

But, check it; they have the following code on p. 157
(taken out of context):

  return (*((int *)&f) - IT_FTOI_MAGIC_NUM) >> 1;

Type punning!  Intel compiler?

--- Colin

Re: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> Surely, most hardware cannot work with float16 natively, but it is
> still useable for lossy compression of some data. As long as I
> define what I want my float16 to look like, it is not less portable
> than any other user defined type.

Sure.

> Generally, trying to look at a float as if it's some kind of a
> black box that stores real numbers, is kinda silly. 

I think this depends entirely on the application's domain.  A lot of 
applications will merrily use a float and perform floating point 
operations and have no care at all whether the underlying 
implementation is IEEE-754 or some freakish VAX implementation.

> You have to be
> aware of its internal representation, or you can't work with it
> (without getting yourself into various precision losses, etc). 

You can inspect an implementation's internal representation by using 
<float.h> and inspecting the associated predefined constants.  These 
are a part of the C standard and must exist on all implementations 
that claim to adhere to it.  These will give you the min, max, radix 
(FLT_RADIX), precision in digits (FLT_DIG), etc.

I feel so ashamed for knowing this stuff...

Brian

RE: [GD-General] packing fun

[Daniel V. <vo...@ep...>]

My problem was that it's not documented what the compiler exactly does wrt
to packing for inheritance with VC++ (my last post contained the
confirmation from Microsoft that it's doing what you would expect with no
nasty surprises) and that the variant of gcc 3.1 we used for Mac and Linux64
versions of UT2003 packed in the strange way I mentioned in a previous post.
This seemed to have been as a regression as 3.3.2 packs like VC++ again.

Our scripting language requires properties to match up exactly with auto-
generated C++ headers so knowing exactly how different compilers pack (and
how to get them all to pack the same way) is vital for us :)

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Scoubidou944
> Sent: Tuesday, December 30, 2003 1:09 PM
> To: gam...@li...
> Subject: Re: [GD-General] packing fun
> 
> Don't sure about what your problem is on padding.
> 
> #pragma pack(push)
> #pragma pack(4)
> struct Alice
> {
>     int Integer1;
>     char Char1;
>     // HERE COMPILER WILL ADD PADDING BYTES TO 0
>     char u8Padding1[3];  // == 0
> };
> 
> struct Bob : Alice
> {
>     char Char2;
>     // HERE COMPILER WILL ADD PADDING BYTES TO 0
>     char u8Padding2[3];  // == 0
> };
> #pragma pack(pop)
> 
> So in memory, we will have 2 structure which are both aligned 
> on 4 bytes :
> Integer1    Char1    u8Padding1    Char2    u8Padding2
> |     4             1              3           |     1               3
> |
> +-------------------------------+---------------------+
> |                  Alice                       |              Bob
> |
> 
> If you don't want to loose space in memory (is there any 
> warrior of low
> memory using in C++ coding ;p) push & pop the stack to fit to 
> the minimum
> size required or reduced size of variables like this :
> 
> struct Alice
> {
>     int         i24Integer1 : 24;           // Will have 
> previous Integer1
> which fit in 24 bits instead 32
>     int         i8Integer1   : 8;            // Will have 
> previous Char1
> };
> ==> sizeof (Alice) = 4 instead 8 and we keep 4 bytes alignment.
> 
> Vincent
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

RE: [GD-General] The joy of type aliasing and C

[Neil S. <ne...@r0...>]

> 
> Casting to a void * or (unsigned) char * will force this.
> 

Hmm, slightly freakish though. Also, I think I prefer the idea of using
"restrict" to tell the compiler what's safe to bugger about with, rather
than it assuming everything's fair game until it sees one of these casts,
especially when it rarely knows what it's safe to assume.

- Neil.

Re: [GD-General] packing fun

[Scoubidou944 <Sco...@ho...>]

Don't sure about what your problem is on padding.

#pragma pack(push)
#pragma pack(4)
struct Alice
{
    int Integer1;
    char Char1;
    // HERE COMPILER WILL ADD PADDING BYTES TO 0
    char u8Padding1[3];  // == 0
};

struct Bob : Alice
{
    char Char2;
    // HERE COMPILER WILL ADD PADDING BYTES TO 0
    char u8Padding2[3];  // == 0
};
#pragma pack(pop)

So in memory, we will have 2 structure which are both aligned on 4 bytes :
Integer1    Char1    u8Padding1    Char2    u8Padding2
|     4             1              3           |     1               3
|
+-------------------------------+---------------------+
|                  Alice                       |              Bob
|

If you don't want to loose space in memory (is there any warrior of low
memory using in C++ coding ;p) push & pop the stack to fit to the minimum
size required or reduced size of variables like this :

struct Alice
{
    int         i24Integer1 : 24;           // Will have previous Integer1
which fit in 24 bits instead 32
    int         i8Integer1   : 8;            // Will have previous Char1
};
==> sizeof (Alice) = 4 instead 8 and we keep 4 bytes alignment.

Vincent

RE: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> 2) What is the most portable way (that avoids risk of alias
> optimisation) of getting a float into binary representation, in
> native form and/or a particular standard form (IEEE, etc.)?

float f =3D 1.0f;
const unsigned char *c =3D ( const unsigned char * ) &f;
int i;

for ( i =3D 0; i < sizeof( f ); i++ )
{
   store_some_byte( c[ i ] );
}

That is 100% legal, as long as it stays in char form.  That is how 
you're expected to transmit it over, say, a network connection if 
necessary, assuming the machine on the other side understands the same 
floating point format.

Floating point in the C standard is borderline disastrous.

Factoid #1: signed integer representation is not specified in the 
standard, so you could conceivably run on a system with, say, 
ones-complement arithmetic.

Factoid #2: C99 introduced support for IEEE-754 floating point 
operations and formats officially, but it's an optional extension that 
can be examined by checking __STDC_IEC_559__

Factoid #3: There's a standard #pragma to tell the compiler not to 
dork with the floating point control and status words while you do 
stuff that relies on that state remaining constant.

Brian

RE: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> An alternative would be to have an "alias" keyword, which is used
> to tell the compiler what *not* to perform these optimisations on.

Casting to a void * or (unsigned) char * will force this.

Brian

RE: [GD-General] The joy of type aliasing and C

[Neil S. <ne...@r0...>]

> The problem with int x=*(int *)&f; is sort of side effect here.
> I don't really know for sure why there must be a problem, 
> because the aliasing of the values is sort of obvious, and 
> could be deduced separately.  Maybe the comittee just wanted 
> to keep the definitions simple?

The aliasing in that example is fairly obvious, but it can easily become
non-obvious, which is why compilers give you the option to switch "assume no
aliasing" off.

Optimisation with optimal handling of aliasing is a virtually unsolvable
problem in C/C++, as they give you more than enough rope to hang yourself
several times over. The committees have tried to go down the "tightening up"
route, where they make it illegal to do certain things that will break the
optimiser but this has, on the whole, failed, mainly because the compilers
can't stop you doing it.

The "restrict" keyword was another attempt to solve the problem, by letting
programmers tell the compiler which pointers it is safe to assume no
aliasing on. The advantage of this approach is that the optimiser will not
make any mistakes, the downside being that the compiler will not be able to
perform certain optimisations without it, so you have to put it almost
everywhere if you want full optimisation. You could argue that you only need
full optimisation in a few places, so the use of restrict could be kept
quite small in practice.

An alternative would be to have an "alias" keyword, which is used to tell
the compiler what *not* to perform these optimisations on. The obvious
advantage is that it will optimise a lot more stuff, but the penalty is that
if you forget to use it where it's needed, your code will break.

- Neil.

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

> I think the aliasing rules
> make it easier to compete with fortran compilers here.

Of course, I understand the reasoning on why hidden aliasing needs to
reduced/eliminated. But if some part of code _needs_ to access the bit pattern
of some data then there must be a legal way to tell the compiler "look, I'm
doing something nasty here". Is there?

> The problem with int x=*(int *)&f; is sort of side effect here.
> I don't really know for sure why there must be a problem,
> because the aliasing of the values is sort of obvious, and could
> be deduced separately.

Seconded.

Alen

Re: [GD-General] The joy of type aliasing and C

[Eero P. <epa...@ko...>]

Alen Ladavac wrote:


> Generally, trying to look at a float as if it's some kind of a black box that
> stores real numbers, is kinda silly. You have to be aware of its internal
> representation, or you can't work with it (without getting yourself into
> various precision losses, etc). And once you are aware, you should be able to
> access it. But I believe we all agree on that, and it's the standard that has
> a wrong approach here.
> 

I think that the standard has the aliasing rules, not
because the comittee wanted to deny float->integer-bit-pattern
conversions but because the comittee wanted the compiler
produce better code in some other common situations.

For example for some floating point vector library it is
useful for the compiler to be sure that none of the
limit/index integer values change, when the floating
point results are written out. I think the aliasing rules
make it easier to compete with fortran compilers here.

The problem with int x=*(int *)&f; is sort of side effect here.
I don't really know for sure why there must be a problem,
because the aliasing of the values is sort of obvious, and could
be deduced separately.  Maybe the comittee just wanted to
keep the definitions simple?


		Eero

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

> int x = ( int & ) f;
> int x = * ( int * ) &f;
>
> In both cases 'f' is an lvalue (in this example).

But it doesn't have to be.

int x = ( const int & ) f;
int x = * ( const int * ) &f;

would work just as well. Now, this depends on definition of lvalue. Perhaps
(const int &) might be considered an lvalue, but according to the origin of
the name, it should be rvalue (lvalue is by definition of name "value that can
be used on the left side of assignment expression"). I didn't check the
standard, but I guess that they define lvaue somewhat different, marking those
two examples as "constant lvalue", and making my note pointless. Anyway, it
was quite a digression.

What might be of more interest is: What does C++98 say on using
reinterpret_cast?

i = reinterpret_cast<int&>(f);

The reinterpret_cast operator is _designed_ to be used for type punning, isn't
it?

--
Alen

RE: [GD-General] The joy of type aliasing and C

[Crosbie F. <cr...@cy...>]

> From: Alen Ladavac
>
> Didn't see the whole thing, so perhaps this is a stupid
> question, but... is
> there any particular reason that they mention an lvalue? Because, as I
> understand, we are accessing the stored value of a float
> through an rvalue of
> type int, not lvalue of type int. (I mean, it could have just
> as well been
> (const int*), wouldn't make a difference.)


int x = ( int & ) f;
int x = * ( int * ) &f;

In both cases 'f' is an lvalue (in this example).

Perhaps one might avoid aliasing if one declared f as register or as
volatile, but it's pretty tricky to get the binary representation of a float
without going via an lvalue of some sort.

Which then prompts the questions:

1) Is it possible to convert a float to its native binary representation
without going via an lvalue (not even indirectly)?

2) What is the most portable way (that avoids risk of alias optimisation) of
getting a float into binary representation, in native form and/or a
particular standard form (IEEE, etc.)?

Re: [GD-General] The joy of type aliasing and C

[Alen L. <ale...@cr...>]

>In C99, it's section 6.5, paragraph 7, where it specifically says "An
>object shall have its stored value accessed only by an lvalue
>expression that has one of the following types:"

>In the C++ 98 standard, 3.10 paragraph 15, there's the statement "If a
>program attempts to access the stored value of an object through an
>lvalue of other than one of the following types the behaviour is
>undefined:"

Didn't see the whole thing, so perhaps this is a stupid question, but... is
there any particular reason that they mention an lvalue? Because, as I
understand, we are accessing the stored value of a float through an rvalue of
type int, not lvalue of type int. (I mean, it could have just as well been
(const int*), wouldn't make a difference.)

Alen