«

On 08/01/2012 11:12 AM, TheGunslinger wrote:
> On Wed, 01 Aug 2012 10:02:01 -0500, TheGunslinger
> <> wrote:
>
>> On Wed, 01 Aug 2012 10:58:31 -0400, Eric Sosman
>> <> wrote:
>>
>>> On 8/1/2012 10:49 AM, TheGunslinger wrote:
>>>>
>>>> I am assuming you are unfamiliar with some of the libraries.
>>>>
>>>> I would suggest a Google search on: C STL floor function
>>>
>>> First seven hits are for C++, eighth is for the mythical
>>> language "C/C++", ninth is for C++, tenth is a pediatrician.
>>>
>>>> I am guessing you haven't added this library which defines the floor
>>>> function:
>>>>
>>>> #include <cmath>
>>>
>>> I'm confident you're trying to help, but you seem not to
>>> have noticed that the question was about C, not about C++. In
>>> particular, there's no <cmath> header in C.
>>
>>
>> With all due respect, you apparently did not notice this is a "C"
>> forum, and should have been posted in a "C++" forum then...
>>
>> MJR
>
> That said, I am fully aware that that this is a "C" forum, and as
> indicated in my response, I searched with "C" as a parameter.

You may have been aware of it, but nothing you wrote in your response
reflected that awareness, other than the use of C in your recommended
search string. However, your use of STL in that same string negates
that. Since STL is commonly used as an abbreviation for the Standard
Template Library which eventually became a major part (but NOT the
entirety) of the C++ standard library, adding STL to the search
virtually guarantees exclusion of C-specific web sites.

....
> And the website I listed is a C programming support site.

No, it's a C and C++ programming site, which like many such sites, does
not do a good job of dealing with the differences between C and C++. In
particular, the particular page you cited documents exclusively the C++
version of the floor() function.

I checked, and most of the pages at that site for other standard library
functions document both the C and the C++ header file name, so it was
just bad luck that the page for floor() does not.

> So, if you have a problem with my response, perhaps you should really
> take it up with the website referenced.

The last paragraph of your original message was written entirely by you.
Neither of the mistakes in that paragraph was the responsibility of
anyone other than yourself, and that paragraph could not have been
written by someone who was, as you claim to have been, 'fully aware that
this is a "C" forum'.

On 8/1/2012 11:12 AM, TheGunslinger wrote:
>
> That said, I am fully aware that that this is a "C" forum, and as
> indicated in my response, I searched with "C" as a parameter.

Then why did you offer a C++ answer? (As it happens, even
if the O.P. had been using C++ your answer would not have helped;
his problem was not with compilation, but with linking.)

> One of the bigger problems today is that many of the newer compilers
> are not strictly "C" systems.

Not sure what you mean by this, or why it would matter. If
Compiler X conforms imperfectly to the C Standard, does it then
make sense to answer as if for COBOL?

> And the website I listed is a C programming support site.

No; the web site's *title* says its about C. But the site
itself is not! Here's the code from the page you linked to:

//Example will output 5.9 rounded down
#include <cmath>
#include <iostream>

using namespace std;

int main()
{
cout<<"5.9 rounded down: "<<floor(5.9);
}

> So, if you have a problem with my response, perhaps you should really
> take it up with the website referenced.

First, it wasn't very smart of you to offer a link to a
poor-quality web site. (The site may have other fine qualities,
but for the question at hand its quality is poor.) Second, your
own text in the body of your own message -- something you can't
blame on a web site -- was a C++ answer, not applicable to C.

> Disclaimer: Have a FLAME. Take it to somebody who cares! Here's your
> sign... "I am stupid!" , Jeff Foxworthy

Earlier I wrote that I thought you were trying to be helpful.
I'm starting to doubt myself.

--
Eric Sosman
d

Andre <> writes:
[...]
> printf("%d\n\r",floor(2.2333));
[...]

Apart from the type mismatch, the "\r" is not necessary. Printing
"\n" to a text stream will emit whatever is needed to mark the end
of a line.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <kst-> writes:

> Andre <> writes:
> [...]
>> printf("%d\n\r",floor(2.2333));
> [...]
>
> Apart from the type mismatch, the "\r" is not necessary. Printing
> "\n" to a text stream will emit whatever is needed to mark the end
> of a line.

Furthermore, when both \r and \n are used, the normal order is
\r\n (CR LF, not LF CR).

On 08/01/2012 01:43 PM, Ben Pfaff wrote:
> Keith Thompson <kst-> writes:
>
>> Andre <> writes:
>> [...]
>>> printf("%d\n\r",floor(2.2333));
>> [...]
>>
>> Apart from the type mismatch, the "\r" is not necessary. Printing
>> "\n" to a text stream will emit whatever is needed to mark the end
>> of a line.
>
> Furthermore, when both \r and \n are used, the normal order is
> \r\n (CR LF, not LF CR).

According to <http://en.wikipedia.org/wiki/Newline>, LF+CR is used for
"Acorn BBC and RISC OS spooled text output".

James Kuyper <> writes:

> On 08/01/2012 01:43 PM, Ben Pfaff wrote:
>> Keith Thompson <kst-> writes:
>>
>>> Andre <> writes:
>>> [...]
>>>> printf("%d\n\r",floor(2.2333));
>>> [...]
>>>
>>> Apart from the type mismatch, the "\r" is not necessary. Printing
>>> "\n" to a text stream will emit whatever is needed to mark the end
>>> of a line.
>>
>> Furthermore, when both \r and \n are used, the normal order is
>> \r\n (CR LF, not LF CR).
>
> According to <http://en.wikipedia.org/wiki/Newline>, LF+CR is used for
> "Acorn BBC and RISC OS spooled text output".

I stand by my claim about "normal" order. I admit that there may
be systems that use an abnormal order.

In article <>,
Ike Naar <> wrote:
>>
>> printf("%d\n\r",floor(2.2333));
>
>Type mismatch; floor returns a double, but the
>"%d" format expects an integer.

Oh, and get rid of the '\r' in the format string. The
C stdio library will handle line endings correctly for
you.

--
-Ed Falk,
http://thespamdiaries.blogspot.com/

Ben Pfaff wrote:

> I stand by my claim about "normal" order. I admit that there may
> be systems that use an abnormal order.

The problem with "norms" is that they are moving targets

On Wed, 2012-08-01, Ike Naar wrote:
> On 2012-08-01, Andre <> wrote:
>> I must have missed something as it compile Ok but result of floor(2.233)
>> is 0??
>>
....
>> printf("%d\n\r",floor(2.2333));
>
> Type mismatch; floor returns a double, but the
> "%d" format expects an integer.

Might as well mention this: turn on more warnings from the compiler
to avoid such errors. For gcc it's something like

-W -Wall -pedantic -ansi -g -O2

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Wed, 2012-08-01, Ben Pfaff wrote:
> James Kuyper <> writes:
>
>> On 08/01/2012 01:43 PM, Ben Pfaff wrote:
....
>>> Furthermore, when both \r and \n are used, the normal order is
>>> \r\n (CR LF, not LF CR).
>>
>> According to <http://en.wikipedia.org/wiki/Newline>, LF+CR is used for
>> "Acorn BBC and RISC OS spooled text output".
>
> I stand by my claim about "normal" order. I admit that there may
> be systems that use an abnormal order.

Or /have been/ in this case. I haven't heard about Acorn for 20 years.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .