Comment On Fixing Compiler Warnings

"In C," writes Keith Lucas, "literal floating point number are interpreted as double precision floating point numbers. For example, if you have '0.0' in your code, the compiler will determine the type of '0.0' to be 'double'. In some compilers, such as the Visual C++ 6 compiler that we use, if a literal 'double' is used for a function with a 'float' parameter, a compiler warning is issued because the literal could be less accurate." [expand full text]
« PrevPage 1 | Page 2Next »

Re: Fixing Compiler Warnings

2008-02-18 08:01 • by Dascandy (unregistered)
1.0f post !

Re: Fixing Compiler Warnings

2008-02-18 08:04 • by David Schwartz (unregistered)
Is it really that hard to turn off the warning? VC++ even gives you a nice 'pragma' line that you can use to turn off a specific warning, which you can put in the same header file you were going to put all that crap into.

Re: Fixing Compiler Warnings

2008-02-18 08:07 • by bstorer
177488 in reply to 177487
David Schwartz:
Is it really that hard to turn off the warning? VC++ even gives you a nice 'pragma' line that you can use to turn off a specific warning, which you can put in the same header file you were going to put all that crap into.

The correct solution isn't disabling the warning. How hard is it to add the freaking 'F'?

Re: Fixing Compiler Warnings

2008-02-18 08:12 • by Pyro (unregistered)
abusing define is so 1980

Re: Fixing Compiler Warnings

2008-02-18 08:23 • by SomeoneWhoWroteAccessOnce (unregistered)
177494 in reply to 177488
bstorer:
The correct solution isn't disabling the warning. How hard is it to add the freaking 'F'?

Indeed, it always amazes me that people consider warnings to be added to the compiler by "annoying consultants with nothing better to do than scream at honest programmers", instead of "honest programmers who have run into bug X so often they want to warn people that behavior Y really increases the chance of bug X".

Re: Fixing Compiler Warnings

2008-02-18 08:28 • by Cosmin Marginean (unregistered)
This seems to be a "cousin" of a previous post (http://thedailywtf.com/Articles/His-Own-Way-to-Newline.aspx). What is truly adorable in these situations is, besides the "well thought" solution is the enthusiasm and passion these guys use to explain something totally abominable and sick. We all make mistakes, but being aware of a booboo you made seems to be less and less achievable.

Re: Fixing Compiler Warnings

2008-02-18 08:39 • by lgrave
177498 in reply to 177485
Dascandy:
1.0f post !


You mean 1.00000081f post

Re: Fixing Compiler Warnings

2008-02-18 08:59 • by Beeblebrox (unregistered)
The real WTF is that you're still using Visual Studio 6 when 8 is out and 9 is RTM'd. The upgrade is worth it, believe me. If your code is so broken it won't build with visual studio 8, then the problem is that your code is broken and not standards compliant, so it needs to be fixed.

If the problem is libraries that aren't controlled by you won't work properly with newer versions of visual studio, then bug the vendor about it. They probably have a newer version.

Re: Fixing Compiler Warnings

2008-02-18 09:01 • by gabba
Keith seems to have missed the most important benefit of this scheme. If some other component of the system needs a different value for, say, 0.4, they need only:

#define OTHERCOMPONENT_P40 ((float) 0.40000001)

So each component can have its own value for 0.4. Can't do that with your 'f'.

Re: Fixing Compiler Warnings

2008-02-18 09:01 • by yuumei (unregistered)
177501 in reply to 177498
lgrave:
Dascandy:
1.0f post !


You mean 1.00000081f post

Or, HMI_1P000000081 post.

Re: Fixing Compiler Warnings

2008-02-18 09:07 • by mauhiz (unregistered)
This is a great idea! One should build a library with every single float constant in the world!

Re: Fixing Compiler Warnings

2008-02-18 09:09 • by olm
The real WTF is using floats when he clearly needs fixed point values.

... but that is so widespread that a lot of people probably consider it good practice :-(

Re: Fixing Compiler Warnings

2008-02-18 09:09 • by pharago (unregistered)
as if there were not enough constants to remember, lol

Re: Fixing Compiler Warnings

2008-02-18 09:18 • by Vollhorst (unregistered)
HMI_TRUE is missing. And HMI_FALSE, HMI_FILE_NOT_FOUND and HMI_EOF. And of course HMI_ENDL. To avoid the nasty typos HMI_ENLD and HMI_ELND followed by HMI_FOUND_TON_FILE was added. Brilliant!

Re: Fixing Compiler Warnings

2008-02-18 09:20 • by NXavier (unregistered)
177509 in reply to 177499
Beeblebrox:
The real WTF is that you're still using Visual Studio 6 when 8 is out and 9 is RTM'd. The upgrade is worth it, believe me. If your code is so broken it won't build with visual studio 8, then the problem is that your code is broken and not standards compliant, so it needs to be fixed.

If the problem is libraries that aren't controlled by you won't work properly with newer versions of visual studio, then bug the vendor about it. They probably have a newer version.


Legacy, my good man. Legacy.

Re: Fixing Compiler Warnings

2008-02-18 09:25 • by Izzy (unregistered)
What about the dreaded
HMI_P333333333333333333333333333...?


Re: Fixing Compiler Warnings

2008-02-18 09:31 • by dextron
177518 in reply to 177513
Izzy:
What about the dreaded
HMI_P333333333333333333333333333...?




#define HMI_P3bar (HMI_P10/HMI_P30)

should be manissalisous

Re: Fixing Compiler Warnings

2008-02-18 09:31 • by Vollhorst (unregistered)
177519 in reply to 177513
Izzy:
What about the dreaded
HMI_P333333333333333333333333333...?

HMI_1P0DIV3P0 what else?

Re: Fixing Compiler Warnings

2008-02-18 09:33 • by d000hg.wordpress.com/ (unregistered)
177520 in reply to 177513
Izzy:
What about the dreaded
HMI_P333333333333333333333333333...?


#define HMI_P_ONE_THIRD (HMI_P10000000 / HMI_P30000000)

Re: Fixing Compiler Warnings

2008-02-18 09:38 • by Jon B (unregistered)
I made it even better:

#define 1.1 1.1
#define 1.2 1.2

Re: Fixing Compiler Warnings

2008-02-18 09:45 • by documentation man (unregistered)
177537 in reply to 177528
reading documentation is fun, but also takes a lot of time.

I mean, not everyone has the time to read up on the fact that macros can have arguments.

#define FLOAT(x) ((float) x)

Re: Fixing Compiler Warnings

2008-02-18 09:54 • by TGV
177542 in reply to 177537
I would like to up you one. Yours is too flexible and elegant. How about

#define HPI(x) (x ## f)

Isn't that much closer to the original in spirit?

Re: Fixing Compiler Warnings

2008-02-18 09:59 • by Blame (unregistered)
I like how he used a c-style cast too.

Also, what's with the trailing zeroes on 1.30 and stuff.

Fire him.

Re: Fixing Compiler Warnings

2008-02-18 10:06 • by hotkey (unregistered)
177547 in reply to 177499
In the 'real world' you don't just switch development platforms like that. The switch here from VC6 to VC7 took close to one man-month I'd say. In addition to updating all the code so it works on the new compiler (no small task), you need to change the install/upgrade code (runtime libraries and whatnot) and the build process.

And of course you still need the old compilers to support releases currently used in the field.

Re: Fixing Compiler Warnings

2008-02-18 10:41 • by OJ (unregistered)
177568 in reply to 177488
Impossible where I work. From <stdint.h> of our tool chain:

#define UINT32_C(value) ((uint_least32_t)(value))

Fortunately uint_least32_t and uint32_t are the same type. Probably they didn't have access to Gnu C library. Ironically, in our system using any of these macros causes a lint warning about unnecessary cast.

Re: Fixing Compiler Warnings

2008-02-18 10:49 • by kstengfufl (unregistered)
177572 in reply to 177537
#define FLOAT(x) ((float) x)

That should be
#define FLOAT(x) ((float)(x))

Makes your C-code more LISP-like.

BTW, I prefer:
#define FLOAT(x) x##F

Re: Fixing Compiler Warnings

2008-02-18 11:04 • by Strilanc (unregistered)
This is an issue I deal with all the time. Option Strict might be a bit annoying, but its a life saver.

What annoys me to no end is when I write a constant expression and the compiler doesn't evaluate to see if it will fit. For example:
dim u as uinteger = 1
dim i as integer = u+1 'unsigned int + signed int = signed long, compile error!

Re: Fixing Compiler Warnings

2008-02-18 11:15 • by Kanzi (unregistered)
177586 in reply to 177508
Vollhorst:
HMI_TRUE is missing. And HMI_FALSE, HMI_FILE_NOT_FOUND and HMI_EOF. And of course HMI_ENDL. To avoid the nasty typos HMI_ENLD and HMI_ELND followed by HMI_FOUND_TON_FILE was added. Brilliant!


HMI_PAULA. Brillant!

Re: Fixing Compiler Warnings

2008-02-18 11:15 • by Smash (unregistered)
I like the fact that someone carefully picked a few random numbers to turn to constants, like HMI_P07, HMI_P14 and specially HMI_P26

Re: Fixing Compiler Warnings

2008-02-18 11:25 • by Snoop (unregistered)
I actually said "what the f..." when I read the code.

Re: Fixing Compiler Warnings

2008-02-18 11:29 • by whicker (unregistered)
the real wtf (tm) is obviously the c-family languages anyway.

you've got explicit typecasting, the weird trailing-letter after a numeric constant, and octal triggered by a leading zero to contend with.

Re: Fixing Compiler Warnings

2008-02-18 11:39 • by dextron
Could HMI stand for "Human Machine Interface," and the various values given are the only valued allowed (detent positions) in the modelled system? Perhaps the code produces HMI instructions for otherwise MMI operations.

Re: Fixing Compiler Warnings

2008-02-18 11:57 • by Anonymous (unregistered)
Seems like the nightmare of someone commenting a few articles back with code like
char a()
{
char a='a';
return(a);
}
came true.

I seriously don't know how all the Computer Science department let all these morons out into the wild. I mean, one would think at least one teacher should have noticed.

Re: Fixing Compiler Warnings

2008-02-18 12:14 • by 8879Factor (unregistered)
177621 in reply to 177496

This seems to be a "cousin" of a previous post (http://thedailywtf.com/Articles/His-Own-Way-to-Newline.aspx). What is truly adorable in these situations is, besides the "well thought" solution is the enthusiasm and passion these guys use to explain something totally abominable and sick. We all make mistakes, but being aware of a booboo you made seems to be less and less achievable.

I see that behavior all the time for CSS hacks.
CSS hacks, by definition, s*ck, are weak & unreliable, and will surely break in 6 months when a browser is debugged or change any of its features.

But, there are many, many, CSS hacks advocates.

Re: Fixing Compiler Warnings

2008-02-18 13:04 • by troll (unregistered)
177633 in reply to 177504
olm:
The real WTF is using floats when he clearly needs fixed point values.

... but that is so widespread that a lot of people probably consider it good practice :-(

Yes. You can clearly see from this small excerpt of defines that the rest of the code makes no use of floating point arithmetic.

Re: Fixing Compiler Warnings

2008-02-18 13:32 • by a hat (unregistered)
177641 in reply to 177621
8879Factor:

This seems to be a "cousin" of a previous post (http://thedailywtf.com/Articles/His-Own-Way-to-Newline.aspx). What is truly adorable in these situations is, besides the "well thought" solution is the enthusiasm and passion these guys use to explain something totally abominable and sick. We all make mistakes, but being aware of a booboo you made seems to be less and less achievable.

I see that behavior all the time for CSS hacks.
CSS hacks, by definition, s*ck, are weak & unreliable, and will surely break in 6 months when a browser is debugged or change any of its features.

But, there are many, many, CSS hacks advocates.
Sometimes there's just no other way.

Re: Fixing Compiler Warnings

2008-02-18 14:06 • by Dascandy (unregistered)
177645 in reply to 177498
lgrave:
Dascandy:
1.0f post !


You mean 1.00000081f post


Ok, I'll admit:

unsigned int x = 0x3f800000;
float *f = (float *)&x;

it was the (*f)'th post.

Re: Fixing Compiler Warnings

2008-02-18 14:18 • by andreyvul
177646 in reply to 177586
Kanzi:
Vollhorst:
HMI_TRUE is missing. And HMI_FALSE, HMI_FILE_NOT_FOUND and HMI_EOF. And of course HMI_ENDL. To avoid the nasty typos HMI_ENLD and HMI_ELND followed by HMI_FOUND_TON_FILE was added. Brilliant!


HMI_PAULA. Brillant!

Hey! Stay on topic to the article (C preprocessor abuse)
#define HMI_PAULA "Brillant"

Re: Fixing Compiler Warnings

2008-02-18 16:21 • by dpm
177671 in reply to 177494
SomeoneWhoWroteAccessOnce:

Indeed, it always amazes me that people consider warnings to be added to the compiler by "annoying consultants with nothing better to do than scream at honest programmers"


I have inherited a few hundred thousand lines of C and C++ code, which results in hundreds of lines like this:

warning: implicit declaration of function 'strlen'

because the [expletive deleted] consultants "didn't have time" to GO BACK and add the _include string.h_ and other similar incredibly common directives. How many WTFs is that?

#1 What do you mean, "go back and add them"?? Why weren't they there in the first place?

#2 What do you mean, "I don't have time"?? How long does it take to cut and paste a few include directives into two or three dozen .C/.CXX files?

#3 What kind of programmer are you that you're "okay" with code that doesn't build cleanly? And don't give me that crap about how you "know" which warnings and errors can be safely ignored, you're just a lame slacker.

Re: Fixing Compiler Warnings

2008-02-18 16:22 • by Jon (unregistered)
These comics are now the Daily WTF.

Re: Fixing Compiler Warnings

2008-02-18 16:44 • by CoyneT (unregistered)
177679 in reply to 177503
mauhiz:
This is a great idea! One should build a library with every single float constant in the world!


Yeah! And the brochure can proudly say how it is the "largest and most complete library in the world"! (Definitely the largest.)

Re: Fixing Compiler Warnings

2008-02-18 17:54 • by Andrew (unregistered)
177688 in reply to 177488
bstorer:
David Schwartz:
Is it really that hard to turn off the warning? VC++ even gives you a nice 'pragma' line that you can use to turn off a specific warning, which you can put in the same header file you were going to put all that crap into.

The correct solution isn't disabling the warning. How hard is it to add the freaking 'F'?


I agree. C/C++ "Warnings" can be more serious than its Errors. I always use the GCC -Wall flag to verify code.

For example, an "implicit cast from incompatible pointer type" usually means a memory leak is ahead. If this is really what is needed, then write an explicit cast.

Re: Fixing Compiler Warnings

2008-02-19 02:02 • by Hans (unregistered)
177716 in reply to 177679
CoyneT:
mauhiz:
This is a great idea! One should build a library with every single float constant in the world!


Yeah! And the brochure can proudly say how it is the "largest and most complete library in the world"! (Definitely the largest.)


That's only until my constants library for type 'double' is released... It will be more accurate than your puny float library, and quite a bit larger as well.

I'm having some problems with typing it out though.

Re: Fixing Compiler Warnings

2008-02-19 02:27 • by Ferd (unregistered)
HMI_PI

?

Re: Fixing Compiler Warnings

2008-02-19 03:55 • by mabinogi (unregistered)
177723 in reply to 177499
Beeblebrox:
The real WTF is that you're still using Visual Studio 6 when 8 is out and 9 is RTM'd. The upgrade is worth it, believe me. If your code is so broken it won't build with visual studio 8, then the problem is that your code is broken and not standards compliant, so it needs to be fixed.

Not if you're writing C.
Microsoft have done exactly _nothing_ to their C support since VS 6 - so why go with a more resource hungry IDE and a slower compiler when it results in no actual gain to your project?

Re: Fixing Compiler Warnings

2008-02-19 04:37 • by SomeoneWhoWroteAccessOnce (unregistered)
177726 in reply to 177671
Actually my comment was in favor of programmers who make a compiler that screams warnings if you don't include string.h and the "people who consider warnings" I was refering to are the ones who "don't have time to go back and add them"

Re: Fixing Compiler Warnings

2008-02-19 06:59 • by notme (unregistered)
177733 in reply to 177518
dextron:
should be manissalisous


mani- what? I googled for that word, and guess what I found?

Re: Fixing Compiler Warnings

2008-02-19 07:14 • by MET
177734 in reply to 177723
mabinogi:

Microsoft have done exactly _nothing_ to their C support since VS 6 - so why go with a more resource hungry IDE and a slower compiler when it results in no actual gain to your project?

I am in the process of moving from 7.1 to 8, and the compiler actually seems to be a lot faster in 8. Especially in making proper use of hyperthreading or multiple cores where appropriate. Intellisense works more of the time as well.

Personally I can never understand why anyone would compile C as C, and not C++ but using fewer features. Changing the extension to .cpp costs nothing in speed and means you can use the free extra language features as appropriate - even if this is just the syntactic sugar and safer casting styles whilst ignoring the more complex features (virtual functions, templates, RTTI etc.).

Re: Fixing Compiler Warnings

2008-02-19 07:52 • by dpm
177736 in reply to 177734
MET:
Personally I can never understand why anyone would compile C as C, and not C++ but using fewer features. Changing the extension to .cpp costs nothing in speed and means you can use the free extra language features as appropriate - even if this is just the syntactic sugar and safer casting styles whilst ignoring the more complex features (virtual functions, templates, RTTI etc.).


Yeah, I can't understand that either. Now, if you'll excuse me, I need to go finish my current task: updating a program on a VAX 4000-700A running OpenVMS V6.2 using the DEC C++ version 5.6-013.

Re: Fixing Compiler Warnings

2008-02-19 09:42 • by xlq (unregistered)
177762 in reply to 177734
[quote user="MET"][quote user="mabinogi"]
Personally I can never understand why anyone would compile C as C, and not C++ but using fewer features. Changing the extension to .cpp costs nothing in speed and means you can use the free extra language features as appropriate [...][/quote]

Because C++ is *not* a superset of C - they are two different languages. Yes, some C programs are valid C++ programs too, but certainly not all. Differences include treatment of void pointers and certain keywords that are no longer valid identifiers, C++ name mangling...
« PrevPage 1 | Page 2Next »

Add Comment