ANSI C functions on unix not working/recognized 1

[qednick]

Hi, I've only just started writing C/C++ programs for the UNIX platform. However, I've noticed that many of the basic ANSI C functions are not recognized by the server's compiler.
These functions include:
ltoa(), fcvt(), strrev(), strupr(), strlwr(), floor(), ceil() and more...

Can anybody tell me why these basic functions do not seem to be available even with the appropriate headers included?
I've had to write my own implementations of these very basic ANSI functions.

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[2016nc]

Well, in any case I would like to know the answer as well, but here is what little I have to offer...

What libraries are you including?

on my system anyways...

#include <cmath> (math.h with std namespace) has the ceil() and floor() functions

#include <cstdlib> (stdlib.h with std namespace) has atoi..but not itoa last I looked...

 

[qednick]

i tried <math.h> & <cmath> as well as the all the other headers (stdlib.h & cstdlib, etc etc). These are really basic fundamental ANSI C functions - I just can't believe they're not included on UNIX systems.

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[chipperMDW]

ltoa(), fcvt(), strrev(), strupr(), and strlwr() don't sound like ANSI functions to me. floor() and ceil() are, though. Do you link to the math library?

i.e.
[tt]g++ -lmath myfile.cpp
[/tt]


As for those others, I'm positive strrev(), strupr(),and strlwr() aren't ANSI. There's a toupper() and a tolower(). ltoa() is nonstandard just like itoa(). I'm not familiar with fcvt().

 

[xwb]

_strrev () - string reversal
_strupr () - convert to uppercase
_strlwr () - convert to lowercase
_itoa () - integer to ascii
_ltoa () - long to ascii
_fcvt () - floating point conversion

These are all MS specific. Basically most routines which begin with an underscore are MS specific: they are not ANSI. If you look up the MS help pages, when they are ANSI, it will say so.

 

[qednick]

Yes I know - I'm talking about the versions that do not begin with the underscore!

eg. strrev() NOT _strrev ()

However, I did find a site on the net which explains that (like chipper said) they are not 'strict' ansi.

Thanks anyway.

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[jstreich]

cstdlib and ctype has a lot of those old ANASI functions... It is where most of the type conversians and char tests are like isAlpha()... I'd assume that they are there. I'd look it up, but the god of all refrence books is already packed (in proccess of moving).

Those aren't that difficult to write though, so instead you might just get the gumption to give up the search and just write it your self. It always helps to keep a library of your own arrond with little functions that you seem to forget where in the standard C libraies they are, or something that you tend to do alot and isn't done the way you like in the standard libraries.

Happy hunting, sorry I couldn't do more.

 

[PhilMumf]

As others have said, apart from ceil() and floor() these are not ANSI functions - that is why you can't find them! The following URL explains which are standard.

http://www.cplusplus.com/ref/cstdlib/

Have you tried &quot;man fcvt ltoa&quot; etc to see if they are supported in some special library/header. You might find that all you need to do is include some extra header in order to get them but you might also need to link in an extra library. e.g. on solaris fcvt requires <floatingpoint.h> however it does not support ltoa

Other than that maybe gnu supplies an implementation of them that you could copy into your code? I had a *very* quick search on the web but didn't find an implementation.

 

[palbano]

cplusplus.com ? Just when I was absolutely positive I didn't know crap about anything, it was acutely confirmed! LOL

-pete

 

[jstreich]

itoa ltoa fcvt -> just use a string stream... The converse are ANASI, though.

string iterator and use for each, passing toupper and tolower.

besides, there are implementations out there of these (perhaps should be) standard but not standard functions.

 

[qednick]

I'd actually rewritten some of my own variations on these as a substitute to using sprintf() - shortly afterwards I came across some similar code in C/C++ Users Journal that claims to be a lot more efficient than the good old sprintf. One thing I find incredibly annoying though - why the hell does Microsoft keep &quot;rewriting&quot; the standards for there own compilers?

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[chipperMDW]

Well, there's a difference between rewriting the Standard and providing extensions to it. Microsoft provides extensions to both the language and library, which is perfectly legal; you can provide more than the Standard requires, just not less. All commercial compilers do it to attract users: Microsoft provides those useful, yet nonstandard functions; gcc/g++ provides an alignof operator; many compilers provide a typeof operator. This is a good thing; it helps the language grow and evolve. I can't tell you that alignof or typeof will be in the next C++ Standard, but I can nearly guarantee that someone will make a proposition for them, and I think they both have a pretty high chance of being accepted. Microsoft has already solved many of the language issues the Standards Committee is concerned with, and they're seriously considering adopting some of Microsoft's extensions to the language in the next Standard.

The more annoying thing is that Microsoft disregards the Standard. It's five years after it was approved, and Microsoft still has basic problems such as the incorrect scope for variables declared in for loops. That's not to mention the big problems they have with templates (although admittedly, no compiler has gotten them perfect yet, as far as I know) and namespaces.

Word on the street is that Microsoft's next C++.NET compiler will be highly Standards-conformant, though.

 

[qednick]

From what I understand, Microsoft has only just started going to the standards meetings and providing some input. Also, why the hell did Microsoft feel inclined to rewrite their own version of the STL? Because of this and the fact that I currently use three different compilers, I find myself writing my own variations of &quot;built-in&quot; functionality which will work across 3 platforms rather than using the so called &quot;standard&quot; implementations which should work across standard C/C++ compliers!

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[chipperMDW]

Yeah, that's true; they've just started attending the meetings. Their next compiler (in its beta version now) is already very conformant (at least to the last Standard), though. You've probably read the same article I have on the topic; &quot;Standard C++ Meets Managed C++&quot; or something to that effect. It was linked to on the CUJ site.

Give me an example of a place where Microsoft has written its own version of the STL. I wasn't aware they had made any major changes to it, but I don't use it as often as I do g++.

 

[qednick]

Well, I can't remember where I read it (probably CUJ) but I had some problems recently with some very simple vector code which worked fine in G++ and CodeWarrior but not VC++. I guess it's got something to do with the VC++ compiler and how it works internally. Perhaps MS have to re-write some of the standards to make it work on their compiler.

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[chipperMDW]

Ah, ok. In that case, it may not be that they've chosen to rewrite the STL, just that they've made some mistakes in writing it in the first place. That's not hard to believe; it is Microsoft, you know.

 

[qednick]

LOL

[sup]programmer (prog'ram'er), n A hot-headed, anorak wearing, pimple-faced computer geek.[/sup]​

 

[jstreich]

Microsoft and standards mentioned in the same thread... :0 !!!

I think the reason why MS has been slow to adopt standards officially is because they don't want it to be easily ported to other compilers... &quot;Hey, cool, here's an open source windows project...&quot; (ten minutes later) ..&quot;Hmmm, I need the MFC to compile it... Which mean I guess I'll have to buy it.&quot; Either that, or they figgure that since they have more money, they get to decide what &quot;standard&quot; is... &quot;Screw ANASI, ISO, ASA, unicode, ASCII (oh wait they use that one, without modification)... I'm Lord Gates of king of the (Red) mound. Bow to my money!&quot; *cough* sorry, I'm ranting.

When is the next standards meeting, anyone know? (just curious)

 

[chipperMDW]

Also, they've been reluctant to go Standard because doing so would disrupt so much of their existing code base. For example, a lot of their code relies on being able to declare variables in for loops, then use them after the for loop finishes. If they fixed that bug, too much of their existing code would no longer compile.

I believe the next meeting is in April.