Sign in to follow this  

SOLVED - The Day The Math.h Died

This topic is 3459 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've recently switched from using Dev-C++ (a very very good program) to Visual C++ 2008 (also very good and now making me learn my c++ strictly). I'm shocked to find that VC++2008 doesn't come with a math.h header, what's up? Is the math.h header an unofficial header and so not included? or is VC++2008 just a little lacking in certain departments? Anyway, I'm trying to include PI for some equations ... which is the official header file to use?

Share this post


Link to post
Share on other sites
You should never use <math.h> in C++ -- you should have been using <cmath> The constant is also generally M_PI -- when it exists -- but this is an extension. C++ itself doesn't actually have this constant. For VS I believe you need to #define USE_MATH_DEFINES before #include <cmath> to enable them.

That said, you may just have your include paths set up incorrectly.

Share this post


Link to post
Share on other sites
Quote:
Original post by frogtag
I've recently switched from using Dev-C++ (a very very good program) to Visual C++ 2008 (also very good and now making me learn my c++ strictly). I'm shocked to find that VC++2008 doesn't come with a math.h header, what's up? Is the math.h header an unofficial header and so not included? or is VC++2008 just a little lacking in certain departments? Anyway, I'm trying to include PI for some equations ... which is the official header file to use?


Since math.h is a standard C header, it should be present.

It should be noted that in C++ you should #include <cmath> anyways

[edit]

Did you write #include <Math.h> instead of #include <math.h> (lower case) ?

Share this post


Link to post
Share on other sites
As I've said VC++2008 is new to me and I'm a little confused between where the include files are stored, but I've found math.h in another location(!) ... but that said the info on cmath.h is really what i'm looking for. Thank You.

Share this post


Link to post
Share on other sites
Quote:
Original post by frogtag
cmath.h is really what i'm looking for. Thank You.


In C++ you're supposed to omit the ".h" on C++ standard headers, regardless of what the file is actually named in your filesystem. There is a historical reason for this and is defined by the specification.

You should just write:

#include <cmath> //C++

[edit]

Edited for clarity.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
You should never use <math.h> in C++

Unless you want the functions in the global namespace in addition to the std namespace, in which case you would use math.h.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by jpetrie
You should never use <math.h> in C++

Unless you want the functions in the global namespace in addition to the std namespace, in which case you would use math.h.


Erm,

Quote:
From ISO/IEC 14882:2003

Annex D
(normative)
Compatibility features

  1. This clause describes features of the C++ Standard that are specified for compatibility with existing implementations.

  2. These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.
  • ...
  • D.5 Standard C library headers
  1. For compatibility with the Standard C library, the C + + Standard library provides the 18 C headers, as shown in Table 100:

Table 100--C Headers

<assert.h> <iso646.h> <setjmp.h> <stdio.h> <wchar.h>
<ctype.h> <limits.h> <signal.h> <stdlib.h> <wctype.h>
<errno.h> <locale.h> <stdarg.h> <string.h>
<float.h> <math.h> <stddef.h> <time.h>



Red colored emphasis added.

Share this post


Link to post
Share on other sites
Uh huh. Now give me a honest estimation of the probability that it would be removed from the standard anytime in the next 20 years, keeping in mind that doing so would effectively break millions of lines of existing code, not to mention future compatibility with header files for C libraries.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Uh huh. Now give me a honest estimation of the probability that it would be removed from the standard anytime in the next 20 years, keeping in mind that doing so would effectively break millions of lines of existing code, not to mention future compatibility with header files for C libraries.


Pretty unlikely, but that's a poor excuse for using deprecated things for no other purpose than to shit all over the root namespace. I know a lot of code was broken when they yanked <conio.h> and company too!

Share this post


Link to post
Share on other sites
conio.h was never part of the C or C++ standard. math.h is part of both. And you're going to be stuck with the symbols in the global namespace either way since most major standard library implementations (e.g. gcc and MSVC) pull the symbols into both the root namespace and the std namespace when you include cmath anyways, and many programs written in C++ depend on that fact.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
conio.h was never part of the C or C++ standard. math.h is part of both.

Which is exactly why I say "pretty unlikely" instead of "way too ****ing probable to encourage this".

Quote:
And you're going to be stuck with the symbols in the global namespace either way since most major standard library implementations (e.g. gcc and MSVC) pull the symbols into both the root namespace and the std namespace when you include cmath anyways, and many programs written in C++ depend on that fact.

So, "It's okay because everyone does it"? That attitude is exactly why I give non-library projects their own namespace anyways. But, ignoring that, and all the wonderful little details like "will the root namespace's trig functions be overloaded?" and "What about the overloads for std::complex?" and having the answer vary by compiler regardless of what the standard says -- you're right, there's totally nothing wrong with #including <math.h>, go ahead and use it, it's not like it's deprecated for any of those so called "reasons".

(aside: jpetrie was missing an underscore, it's _USE_MATH_DEFINES)

Share this post


Link to post
Share on other sites
So are you going to personally go through and rewrite all the C++ files that ever existed that use things like cos() and FILE in the root namespace and include the math.h and stdio.h rather than cmath and cstdio? If so, then you can justify a statement like "You should never use <math.h> in C++". If you aren't willing to spend the rest of your life dedicated to such a pointless cause, I suggest you drop the attitude and join people in the real world. There's no reason to be vulgar about this, unless you're trying to come off as needing to swear in order to make your point due to lack of actual reasonable arguments.

There are very few absolutes in the realm of programming; this isn't one of them.

Share this post


Link to post
Share on other sites
I also think Visual Studio does some things a bit weirdly. I notice that some of the header files are done in such a way that the methods automatically have a using clause for them. You have to access them using the scope resolution opperator.

::rand()

instead of

std::rand()

it seems that the header has the using clause included

using std::rand() so you don't have to use the std namespace to access it.

I find it strange that Microsoft did this.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
So are you going to personally go through and rewrite all the C++ files that ever existed that use things like cos() and FILE in the root namespace and include the math.h and stdio.h rather than cmath and cstdio?

No, I take "not using math.h" to mean "not using math.h" rather than "beginning a crusade to hack into every computer on the intertubes and fixing all code everywhere in all existance including in the past to not use math.h".

You don't like jpetrie's wording, fine. "Never use math.h in new C++ code" better for you? Or are you insulting his intelligence as well?
Quote:
There are very few absolutes in the realm of programming; this isn't one of them.

Sure. Especially if, say, working with a deficient pre-standard C++ compiler which doesn't even provide <cmath> for some platform with no alternative, that would be an acceptable use of math.h for even new C++ code.

Generally speaking, though, that's hardly an argument to use math.h everywhere, or to argue against avoiding math.h where possible.

Quote:
There's no reason to be vulgar about this, unless you're trying to come off as needing to swear in order to make your point due to lack of actual reasonable arguments.

Maybe you missed where I was giving an example of an statement I was not making and contrasting myself against that. Because words censored to the point of only being identifiable as a continuous verb with a 4 letter root are so vulgar.

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
Generally speaking, though, that's hardly an argument to use math.h everywhere, or to argue against avoiding math.h where possible.

And I never said to use math.h everywhere. As you may not have noticed, what I actually said "Unless you want the functions in the global namespace in addition to the std namespace, in which case you would use math.h." There are cases where it is desirable, or even necessary such as dealing with legacy code or code that you want to be portable. Whether you like it or not, in the real world people have to write code for platforms with deficient compilers, and using math.h is far more portable than using cmath, deprecated or not, even for new code. If you don't believe me, try submitting patches for existing cross-platform open source projects to use cmath, cstdio, etc. and the std namespace rather than math.h, stdio.h and the root namespace and watch as the platform targets fail to build.

Quote:
Original post by MaulingMonkey
Because words censored to the point of only being identifiable as a continuous verb with a 4 letter root are so vulgar.

Quote:
Original post by MaulingMonkey
Pretty unlikely, but that's a poor excuse for using deprecated things for no other purpose than to shit all over the root namespace.

That doesn't look censored to me. Let's say your censored verb there was just an added example of what seems like an indication that you would rather rely on shock value than arguments that stand up in the real world.

Bottom line: math.h puts the identifiers in the root namespace, and if you want them there, then use math.h rather than cmath. You may argue that you shouldn't put them there, but it does not change the fact that when you need it, that's what you do. If you think that stating that is insulting your intelligence, well, I'm sorry, but I can't change how the world works just because you got your feelings hurt. If you want a world where everyone uses cmath and the std namespace in every situation, then I suggest going out there and fixing all the compilers. Oh and wiping C from the face of the planet, since as long as C exists headers designed for both languages will need to use the .h versions. Easy, right?

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by MaulingMonkey
Generally speaking, though, that's hardly an argument to use math.h everywhere, or to argue against avoiding math.h where possible.

And I never said to use math.h everywhere. As you may not have noticed, what I actually said "Unless you want the functions in the global namespace in addition to the std namespace, in which case you would use math.h."

This brings up a point I missed: Just using math.h won't put them in the global namespace "in addition" to the std namespace. It will put them into the global namespace only (at least in practice, I can cite the example of MSVC2k8), not that this affects either of our arguments.

Quote:
There are cases where it is desirable, or even necessary such as dealing with legacy code or code that you want to be portable. Whether you like it or not, in the real world people have to write code for platforms with deficient compilers, and using math.h is far more portable than using cmath, deprecated or not, even for new code.

Now you're beginning to have something resembling an actual point. Good job! Now explain why a newbie should start working with deficient tools for an already deficient language, thus establishing why that point justifies him catering to those tools.

Quote:
If you don't believe me, try submitting patches for existing cross-platform open source projects to use cmath, cstdio, etc. and the std namespace rather than math.h, stdio.h and the root namespace and watch as the platform targets fail to build.

You were talking about pointless causes? [lol]

Seriously though, feel free to give some examples where you've done this. Most of them will be using the GNU toolchain for all platforms which means they have a working C++ implementation, no? But I assume you've encountered this problem in the past...

Quote:
Quote:
Original post by MaulingMonkey
Because words censored to the point of only being identifiable as a continuous verb with a 4 letter root are so vulgar.

Quote:
Original post by MaulingMonkey
Pretty unlikely, but that's a poor excuse for using deprecated things for no other purpose than to shit all over the root namespace.

That doesn't look censored to me.

My apologies. It seemed clear you were referring to my latest post at that time. I was mistaken.
Quote:
Let's say your censored verb there was just an added example of what seems like an indication that you would rather rely on shock value than arguments that stand up in the real world.

You're entitled to make whatever assumptions you like. Any more ad hominem you'd like to share?

Quote:
If you think that stating that is insulting your intelligence,

No, the whole treating-at-all-semi-seriously-even-as-an-intentionally-absurd-example the suggestion of rewriting working code under the guise of some sort of attempt to reach standardese nirvana with nanopie in the sky is what is insulting. I have to say, repeating the suggestion in the rest of the paragraph I quoted in your "apology" is what we call "especially smooth".

[Edited by - MaulingMonkey on June 27, 2008 11:53:55 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
No, the whole treating-at-all-semi-seriously-even-as-an-intentionally-absurd-example the suggestion of rewriting working code under the guise of some sort of attempt to reach standardese nirvana with nanopie in the sky is what is insulting. I have to say, repeating the suggestion in the rest of the paragraph I quoted in your "apology" is what we call "especially smooth".

It is, however, what is necessary for your revised statement "Never use math.h in new C++ code" to be valid. Since you regard that scenario as absurd, then your contention "Never use math.h in new C++ code" is also absurd. But of course, you can't actually be arguing that since you then contradict yourself in the paragraph after you revised your position. So exactly what is your position? It apparently isn't "Never use math.h" either.

Quote:
Seriously though, feel free to give some examples where you've done this. Most of them will be using the GNU toolchain for all platforms which means they have a working C++ implementation, no? But I assume you've encountered this problem in the past...

Ok, here's an entire category: BeOS has the interesting property that a lot of it's API is written in C++ rather than C as is traditional for most operating systems. Therefore using a compiler that isn't ABI compatible with the BeOS ABI is something of a bad idea. Unfortunately, the BeOS ABI is compatible with gcc 2.95, but not compatible with gcc 3.x. With gcc 2.95.3, here is the complete contents of the cstdio header:

// The -*- C++ -*- standard I/O header.
// This file is part of the GNU ANSI C++ Library.

#ifndef __CSTDIO__
#define __CSTDIO__
#include <stdio.h>
#endif

As you can see, the stdio.h contents aren't placed in namespace std at all. Therefore using #include <cstdio> and then trying something like std::printf() will fail to compile if built with -fhonor-std. -fhonor-std is in turn necessary to work around some template instantiation issues, and isn't link compatible with -fno-honor-std. And, for reasons I fail to understand, a few open source projects still target BeOS as a platform (e.g. PhysFS and some SDL libraries).

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by MaulingMonkey
No, the whole treating-at-all-semi-seriously-even-as-an-intentionally-absurd-example the suggestion of rewriting working code under the guise of some sort of attempt to reach standardese nirvana with nanopie in the sky is what is insulting. I have to say, repeating the suggestion in the rest of the paragraph I quoted in your "apology" is what we call "especially smooth".

It is, however, what is necessary for your revised statement "Never use math.h in new C++ code" to be valid. Since you regard that scenario as absurd, then your contention "Never use math.h in new C++ code" is also absurd. But of course, you can't actually be arguing that since you then contradict yourself in the paragraph after you revised your position. So exactly what is your position? It apparently isn't "Never use math.h" either.

It seems I've erred in trying to explain my position by example rather than being more thorough in my wording.

My exact position is that one should avoid using math.h in new C++ code where possible within reasonable limits, which is to say, the vast majority of them. I consider the act of putting the functions contained within into the global namespace to be, in general, unnecessary, and thus insufficient to justify the writing of new code using math.h, hence the origin of our original argument.

Like with all things, there are cases where the rule doesn't hold. I'll divide by zero if you hold a gun to my head, even if I suggest "never" doing that either. Similarly, if your project must be portable to platforms lacking proper C++ support -- your BeOS being a hilariously ironic example -- that could be sufficient grounds to use math.h directly in your project. Why you're using C++ when you need to be that portable is something of an interesting question, if a whole separate side tangent. (No, I'm not disavowing the existence of a middle ground.)

Quote:
And, for reasons I fail to understand, a few open source projects still target BeOS as a platform (e.g. PhysFS and some SDL libraries).

Any C++ examples you care to name?

Share this post


Link to post
Share on other sites

This topic is 3459 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this