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)

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.

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.

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.

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?

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]

You guys know I hate it when you fight in front of me! [bawling]

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).

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?