Unfortunately, such things are not C-specific, and thus C++ is
not a panacea. They are tackled differently, yes, but I dare say
C is not worse at that.

For example, those unused function parameters you mention. For
decades, it's been a good C programming habit to write an extra
statement like this

    (void) my_unused_function_argument;

to prevent compiler from generating a warning. I'm pretty sure I
could point out a C counterpart of every "C++ feat" in that area.
Not to say that lint is by far stricter than any C++ compiler.

You're rigth in that warnings shouldn't (must not, I would say) be
taken lightly. Somebody must take care of that.

Warp <war### [at] tagpovrayorg> wrote in message news:3b6d2f36@news.povray.org...
>   A good compiler would issue a warning there (because the condition is
> always false) and the bug would have been located immediately.
>   However, as the POV-Ray source code issues about 10000 warnings I
suppose
> that no-one has full warnings turned on in their compilers (or if they
have,
> this specific warning gets buried under all the other 9999 ones).
>
>   Warnings are always important and they shouldn't be taken lightly. This
> ideology has not been followed in POV-Ray.
>   Fortunately now that POV-Ray will be written in C++ it will be possible
to
> completely get rid of all warnings (C++ allows getting rid of certain
> warnings the C version has and you can't do anything about it: Unused
function
> parameters: Just don't give the parameter a name).
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

There is a HUGE difference between the two.

On any machine, both 01 and 1 (decimal) get translated into
0x00000001 (hex).

While 'ab' may be translated into 0x00006261, or 0x00006162,
or god knows what. The Standard does not define that.

Somebody has pointed out that using multicharacter constants
would be OK in enums... Not quite so. Multicharacter constants
do not define lexical order. What you can (only!) do with enum
elements defined as multicharacter constants is to compare then
for equality; you cannot tell which is bigger and which is smaller.

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3b6e796a$1@news.povray.org...
> In article <3b6ddda7@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
>
> >   Actually 01 is an octal number ;)
> >
> >   (In fact, that's another place where you can shoot yourself in the
foot
> > with C. You might sometimes write something like "i = 011;" to "indent"
the
> > number with other similar numbers and then you are surprised when the
> > program behaves very strangely...)
> >
> >   This is actually one place where the compiler assumes that the user
> > really wanted an octal number and that it wasn't just a mistake.
>
> Exactly.  And in my example (unlike 011) it wouldn't even make a
difference
> if one wrote 01 or 1.  So why does it make a difference if I write
'ab'? --
> Both are features of the language.  They are both a bit "unexpected", but
> still perfectly legal!
>
>
>     Thorsten
>
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3b6e92ae$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> While 'ab' may be translated into 0x00006261, or 0x00006162,
> or god knows what. The Standard does not define that.

And what is wrong with this???  Why would I even care about the integer
value?  Simple: In a properly written program, I do not (see below)!

> Somebody has pointed out that using multicharacter constants
> would be OK in enums... Not quite so.

Quite so.  It works very well and is widely used (examples: TIFF, TrueType
fonts, Mac OS, Windows, etc).  Please don't make a problem out of something
where there is _none_ and has never been in the past two decades except in
the minds of the writers of a certain compiler who seem to have been locked
in their ivory tower for too long ;-)

> for equality; you cannot tell which is bigger and which is smaller.

As I said:

>> doing a comparison like 'abcd' > 1234 it is at least very bad style (nearly
programming error).  [...]  after all comparing an enumeration value against
an integer constant is bad style. <<

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Ah, well, well... Thorsten, take this:

How are you going to *reliably* save and restore your data?
In programs made with different compilers (let alone on different
platforms)? (Please don't say "I don't want to save my data!"
You do. And please don't resort to indexing or other tricks).

There is a known way of doing this for integer values: write
byte-by-byte, then restore byte-by-byte (doing proper shifts
and additions); POV-Ray does exactly that when, say,
loads tga files.

Save your 'long' with multibyte constant (by whatever method),
then just recompile your program with different compiler, then
load your 'long' back. There is *absolutely* NO guarantee that
the following, or anything you could devise, will work:

  enum my_enum_t { MY_MB = 'ab'; };

  long my_long = MY_MB;

  if( must_save )
  {
     // PART1: save by whatever method
  }
  if( must_load )
  {
    // PART2: load by whatever method
  }
  if( my_long != MY_MB ) { /* shit happens... */ }

If PART1 is executed in the program compiled with one
compiler, and PART2 -- in that same program but compiled
with another compiler, then you *will* get into the last set
of curly braces sooner or later.

We all know Microsoft's attitude to portability, and yet
their exists the MKFOURCC() macro. Guess why.

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3b6ed53e@news.povray.org...
> In article <3b6e92ae$1@news.povray.org> , "Vadim Sytnikov"
<syt### [at] rucom>
> wrote:
>
> > While 'ab' may be translated into 0x00006261, or 0x00006162,
> > or god knows what. The Standard does not define that.
>
> And what is wrong with this???  Why would I even care about the integer
> value?  Simple: In a properly written program, I do not (see below)!
>
> > Somebody has pointed out that using multicharacter constants
> > would be OK in enums... Not quite so.
>
> Quite so.  It works very well and is widely used (examples: TIFF, TrueType
> fonts, Mac OS, Windows, etc).  Please don't make a problem out of
something
> where there is _none_ and has never been in the past two decades except in
> the minds of the writers of a certain compiler who seem to have been
locked
> in their ivory tower for too long ;-)
>
> > for equality; you cannot tell which is bigger and which is smaller.
>
> As I said:
>
> >> doing a comparison like 'abcd' > 1234 it is at least very bad style
(nearly
> programming error).  [...]  after all comparing an enumeration value
against
> an integer constant is bad style. <<
>
>     Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3b6edddf$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> How are you going to *reliably* save and restore your data?
> In programs made with different compilers (let alone on different
> platforms)? (Please don't say "I don't want to save my data!"
> You do. And please don't resort to indexing or other tricks).

I knew you would say this despite my _clear_ hint that it is no problem
(TIFF and TrueType are both cross-platform file formats and I have still to
see them not being readable anywhere).


* Let me deal with the cross-platform issue first (because its short to
answer):

As you know byte order is always an issue, so any storage format will have
to be specified in such a way that it is portable.  You simply can't store
the raw data, it won't work most of the time.  There are very different
formats for many other things, not just multicharacter constants.  Non-IEEE
floating-point numbers are just one example.


* Now to the cross-compiler issue:

Storing raw structures?  Again a very bad idea and not because of
multicharacter constants.  For example data alignment in memory.  Different
compilers may decide to use a different alignment of struct elements.  Not
to say that i.e. storing raw structures is a bad idea when it comes to more
complex data that i.e. has pointers in the structs so you end up having to
fix those anyway.

But even if all these were the same because of some common standard on that
particular platform (it is not uncommon to agree on common formats, or
formats set by some dominating force on a platform), then how likely is it
that the platform's compiler struct standard doesn't cover multicharacter
constants?

Further, if you define the file format you will have no other way but to
define it in such a way that the meaning of every byte is clear.  As you
have to do it anyway (i.e. it is even possible to have different byte orders
on the same platform) there is no additional work needed to do it for
multicharacter constants just like for any other type!  So again, here they
require no additional work that wouldn't be necessary for each and every
other data type.

Basically, you are confusing two things here: Cross-platform/compiler design
and unspecified implementation of data formats.  Both are _not_ the same
problem.  They are two very distinct problems:

The C/C++ standards also lets the representation of an integer as
implementation defined. There isn't even anything in there that says
integers have to have the same representation using different compiler on
the same platform.  However, you assume the format is the same for integers
but deny it for multicharacter constants?

Of course, by agreement on one platform the format of integers will probably
be the same, but it doesn't have to be!!!

So, if you observe all used compilers on one platform you will probably find
out that the representation of every built-in type (at least with some
compiler switch) will be the same.  In conclusion, it is reasonable to
assume (as you did with integers) cross-compiler issues that cannot be
worked around without modifying the source code on a particular platform do
not exist (sorry for this complicated sentence).

In summary, there is no cross-compiler-same-platform problem _specific_ to
multicharacter constants.

> there exists the MKFOURCC() macro.

What the macro is actually doing most of the time (not always!) is add
enough garbage to get certain compilers to not complain about the
multicharacter constants.  Apart from this, it can only change the bit
order, which in turn, assuming some common sense and will only be an issue
of byte order.  This in turn will be covered by the regular byte order
conversion you need to do anyway when reading/writing from/to disk

Of course, if someone thinks there is a particular brilliant better format
(after all the format isn't defined at all by the standard) than storing
each character in one byte in either little or big endian you would need to
to more, but there is always something like "common sense" (see above).
However, all this macro does has nothing to do with disk storage in the
first place!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten,

(if you would like to answer, please: provide code snippets
or something; not just general thoughts)

I asked you about aportable way of storing/loading of a
*single* number. You failed? You started to talk about non-IEEE
fp numbers... Thorsten, I state that non-IEEE numbers
represent a lesser problem then multicharacter constants.
If your platform/compiler deal with such numbers, for some
reason, you still can output them as, say

  fprintf( my_file, "%g", my_non_IEEE_number );

and then *reliably* read in (on a different platform) as

  fscanf( my_other_file, "%g", &my_IEEE_number );

With your multicharacter constants, what are you going to do?

Your assumption about integers' representation not been
standartized is, again, wrong. According to ISO, there is a single
possible representation for unsigned integers, plus several
possible representations for signed numbers. If I were
concerned about portability of signed integets (which is normally
not the case), I would store them as n-INT_MIN, and, after
reading, would convert to n+INT_MIN. That would be rock-solid.

Now about MKFOURCC -- you just don't understand. You write:

> What the macro is actually doing most of the time (not always!) is add
> enough garbage to get certain compilers to not complain about the
> multicharacter constants.  Apart from this, it can only change the bit
> order, which in turn, assuming some common sense and will only be an issue
> of byte order.  This in turn will be covered by the regular byte order
> conversion you need to do anyway when reading/writing from/to disk

The keywords here are 'byte order conversion'. Even just the term
'order'. This statement implies knowledge of that 'order'. And you
always have that, on each platform -- for short, int, long, float, double,
whatever -- but not for multicharacter constants. Endianness is
one thing, storing characters within long is another thing. You *first*
pack characters into 'long' (this is governed by some INTERNAL
compiler rules, UNAVAILABLE to mere mortals), and *then* put
that 'long' into memory (this is governed by 'endianness').

That's just plainly non-portable. To be able to convert, you have to
know *WHAT* on Eath do you have.

Phew...

Post a reply to this message

In article <3b6f0bc3@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> (if you would like to answer, please: provide code snippets
> or something; not just general thoughts)

Code for what?  Portable reading/writing of multicharacter constants?  As I
have now pointed out, reading and writing to disk of any binary
representation of any basic type is implementation dependent!

> I asked you about aportable way of storing/loading of a
> *single* number. You failed? You started to talk about non-IEEE
> fp numbers...

And where is the difference?  There is *no* portable way to write any binary
representation of basic types.  I tried to explain it, but it seems I did
not succeed :-(

If you have found a solution how write fully portable code (obviously
without conditional compilation) that can write binary representations i.e.
of the basic type "int" I would really like to see it!

Well, from your statement
    "There is a known way of doing this for integer values: write
    byte-by-byte, then restore byte-by-byte (doing proper shifts
    and additions); POV-Ray does exactly that when, say,
    loads tga files."
and the previous discussion I concluded that you were talking about binary
files, not text files.  Obviously I am talking about binary files (what else
are TIFF or TrueType files?)

Further, what do text files have to do with your problem with multicharacter
constants?

>  Thorsten, I state that non-IEEE numbers
> represent a lesser problem then multicharacter constants.

And can you prove it?

> With your multicharacter constants, what are you going to do?

As far as I know, the C library specification is missing functions that
output multicharacter constants.  Of course, for a C library (as it is
usually specific to a compiler to some extend), it would have been no
problem to specify such an output format in the standard.  Don't blame me
for this not being in there...

> Your assumption about integers' representation not been
> standartized is, again, wrong. According to ISO, there is a single
> possible representation for unsigned integers, plus several
> possible representations for signed numbers. If I were

Where?  In my copy of ISO/IEC 14882:1998(E) (ISO C++ Standard) I cannot find
any such specification.  To the contrary, section 3.9.1 _only_ specifies
that "Plain ints have the natural size suggested by the architecture of the
execution environment; the other signed integer types are provided to meet
special needs".  For unsigned numbers it only requires that they have the
same size, alignment requirements and "obey the laws of arithmetic modulo
2n".  The whole section, nor the whole standard contains a normative
reference to any other ISO standard that defines any of the basic types'
formats.

In particular, "even if the implementation defines two or more basic types
to have the same value representation they are nevertheless different types"
is important if you understand the term "implementation" (3.9.1.10) - in
short it refers to the compiler and thus it is up to the compiler, not the
architecture (of the platform) to specify the size of basic types!

> The keywords here are 'byte order conversion'. Even just the term
> 'order'. This statement implies knowledge of that 'order'. And you
> always have that, on each platform -- for short, int, long, float, double,
> whatever -- but not for multicharacter constants. Endianness is
> one thing, storing characters within long is another thing. You *first*
> pack characters into 'long' (this is governed by some INTERNAL
> compiler rules, UNAVAILABLE to mere mortals), and *then* put
> that 'long' into memory (this is governed by 'endianness').

Well, do you _know_ the byte order of an integer?  How so, it is also
"governed by some INTERNAL compiler rules" according to the ISO C/C++
standards (as I pointed out above)!!!

All you can know is the maximum value you can store in an integer, but you
know next to nothing about its internal representation.  In fact, the byte
order of integers, or to be more general the representation of all basic
types is completely transparent and there is no standard method to determine
it in a program in a portable way!

Indeed, this is the root of all cross-platform problems:  The C/C++
standards don't specify internal representations in order to allow you they
most flexibility when doing low level programming with a specific
compiler/platform combination.  For the standard there is no "world" outside
a single implementation of the standard.

Thus, all assumptions you make are based on your observations or good
compiler documentation, but not because they are specified that way in the
C/C++ standards!  Essentially you have proven that the information you claim
to be "UNAVAILABLE to mere mortals" is available to you because if you know
unspecified implementation dependent details like "short, int, long, float,
double".  So, using the same method you used to obtain this information can
be used to obtain the implementation dependent format of every basic type's
data, and surely the implementation dependent details of multicharacter
constants - you forgot that multicharacter constants, by specification, are
integers.  As the number of integers is finite you can obtain the
representation of every multicharacter constant in every implementation
without exception.

However, you will never need to do so because all (existing) implementations
of ISO C++ use one byte ASCII characters and store the value of each byte of
each character of a multicharacter constant either starting with the highest
or lowest byte and then following the obvious order.  Of course, this is not
part of the standard, but if you assume it and test you won't have to use
the method I outlined above in order to determine the value of every
multicharacter constant without this assumption.

> That's just plainly non-portable. To be able to convert, you have to
> know *WHAT* on Earth do you have.

Contrary to your claim above I have shown that it is possible to determine
the integer representation of every possible multicharacter constant.  Thus,
multicharacter constants are portable because the all implementation details
can be determined and proper action can be taken when reading/writing
multicharacter constants.

In summary, I get the impression you assume good C/C++ code will always be
portable *without* any implementation specific changes.  This is plain
wrong.  The very nature of C/C++, by targeting a range of applications from
GUIs to kernels and drivers, and the language specification itself
explicitly trade portability for low-level programming options in many
places.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Vadim Sytnikov wrote:
> 
> For example, those unused function parameters you mention. For
> decades, it's been a good C programming habit to write an extra
> statement like this
> 
>     (void) my_unused_function_argument;

Which will issue another warning like "code has no effect".
Which I get. ;-)

You can always get rid of all warnings. And I tend to try
that (not always being succesfull). But I have a small system
developed by me and my company which is well over 150000
lines of code and issues exactly 4 (four) warning like the
above.

Markus

Post a reply to this message

Markus Becker <bec### [at] aicossde> wrote:
: You can always get rid of all warnings.

  But you should do it the right way.
  Making awful code just in order to keep the compiler happy is not the
right way.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Markus Becker <bec### [at] aicossde> wrote:

> Vadim Sytnikov wrote:
>> 
>> For example, those unused function parameters you mention. For
>> decades, it's been a good C programming habit to write an extra
>> statement like this
>> 
>>     (void) my_unused_function_argument;

> Which will issue another warning like "code has no effect".
> Which I get. ;-)

> You can always get rid of all warnings. And I tend to try
> that (not always being succesfull). But I have a small system
> developed by me and my company which is well over 150000
> lines of code and issues exactly 4 (four) warning like the
> above.

And of the 300000 lines on the project I'm working on now (about 30-50% at a
rough guess, written by me), we generate *no* warnings at all, on three
*different* compilers, and without resorting to compiler ifdefs except with
regards to the libraries provided with the compilers themselves.

It both is possible and desireable to write code without warnings.  The
patch I'm writing for POV regularly gets checked and fixed for such things.

Geoff

Post a reply to this message