itoa undeclared?

[curlious]

I'm having trouble with itoa
I included <stdlib.h>
but get
/home/curlious/assignment7/src/alescore.cpp:109: error: `itoa' undeclared (first use this function)

#include "alescore.h"
#include "beerscore.h"
#include "ourstr.h"
#include <stdlib.h>
#include <iostream>
using std::ostream;
using std::istream;
using std::cin;
using std::cout;
using std::endl;
.
.
.
void AleScore::Write(vector<string>& MessageOut) const
{
  char Buffer[20];
  MessageOut.push_back(Name);
  MessageOut.push_back(itoa(GetMaxPoints(), Buffer));//****errrorrr here
  cout << "Maximum points possible: " << GetMaxPoints() << endl;
  cout << "Points recieved: " << GetPoints() << endl;
  cout << "Extra Credit: " << GetExtraCredit() << endl;
  cout << "Rating: " << GetRating() * 100 <<" percent"<< endl;
}//end Write()

Any ideas

[Stack Overflow]

Hello,

The function itoa() is not part of standard C or C++. If using C, you can use sprintf; if using C++, you can use an ostringstream.

C++ Example:

• Example 1: Using ostringstream

Here are some local examples:

C: sprintf():

#include <stdio.h>

int main() {
	char number_str[10];
	int number = 25;

	sprintf(number_str, "%d", number);

	return 0;
}

C++: ostringstream:

int main() {
	std::ostringstream number_str;
	int number = 25;

	number_str << number;
	std::cout << "number = '" << number_str.str() << "'" << std::endl;

	return 0;
}

- Stack Overflow

[hk_mp5kpdw]

The correct header should be cstdlib and not stdlib.h. That aside, itoa is not a standard function. It is provided by some implementations but not others. There are alternatives you can use including string streams and the use of sprintf. What compiler are you using?

[curlious]

g++

I must note I am using a non standard string class that are instructor made and is asking us to use. I'll lookup sprintf.

I know the correct header is cstdlib but in my frustration I attempted stdlib.h which is what all the refrences quote for iota

Thanks for the quick response.

When I get done with this project I want to post it so you all can get a good laugh.

[Sang-drax]

The correct header should be cstdlib and not stdlib.h.

Clarification: Both <cstdlib> and <stdlib.h> are standard C++. The former puts its function in the std namespace, the latter does not. cstdlib is preferred.

[Hunter2]

>>Both <cstdlib> and <stdlib.h> are standard C++.
I thought <stdlib.h> and friends were deprecated?

[jlou]

Yes. In this case, deprecated means that it is standard, but that it might be removed from the standard in future versions, and the newer versions are preferred.



Standards compliant compilers must provide the old-style C standard library headers even though they are deprecated. They do not have to provide old-style C++ standard library headers because they are not standard at all.

[Hunter2]

Right. But what I meant was, there's a good reason for preferring <cstdlib> over the .h version, it's not just a preference or stylistic thing

[sigfriedmcwild]

Yes. In this case, deprecated means that it is standard, but that it might be removed from the standard in future versions, and the newer versions are preferred.



Standards compliant compilers must provide the old-style C standard library headers even though they are deprecated. They do not have to provide old-style C++ standard library headers because they are not standard at all.

I thought that headers like stdlib.h were part of the c standard as opposed to headers like cstdlib which are part of the c++ standard. (note that the 2 are not necessarily compatible, in fact there's a few incomaptibilities already if I recall correctly between the 2 standards)

[Stack Overflow]

Hello,

Let's take iostream.h for example. Our objective is to narrow out all *.h header files.

Typically if you use depreciated headers, e.g. iostream.h instead of iostream, you do not need the directive. This is because compilers that support depreciated headers for backward compatibility declare the "using namespace std;" directive prior to including the ANSI header. However this mechanism is supported for backward compatibility, and you should avoid relying upon it in new code.

Keep in mind iostream is part of the C++ standard, iostream.h isn't. iostream is somewhat more restrictive than the older iostream.h. One would possibly avoid problems by careful use of namespaces, but it would be a lot smarter to stick with one or the other.

You should avoid using the *.h version as much as possible, because some implementations have bugs in their *.h version. Moreover, some of them support non-standard code that is not portable, and fail to support some of the standard code of the STL.

Furthermore, the *.h version puts everything in the global namespace. The extension-less version is more stable and it's more portable. It also places everything in the std namespace.

iostream.h is an old style method of including std C++ headers, and in opposite to iostream you don't have to declare that you're using the std namespace.

For example the string class which needs string, rather than string.h is a C header, and is not the same. It is equivilent to cstring which should be used instead.

In VC++ 6 iostream.h works, which is different than iostream. The *.h version was assembled before there was a standard for C++.

P.S. This pertains to most, if not all, *.h header files.


- Stack Overflow

[Prelude]

>Typically if you use depreciated headers, e.g. iostream.h instead of iostream
iostream.h isn't deprecated, it was never a part of ISO C++.

>compilers that support depreciated headers for backward compatibility
Compilers that support deprecated headers have no choice if they want to claim conformance with the standard. Compilers that support pre-standard C++ headers do so for backward compatibility, but that's quickly changing.

>declare the "using namespace std;" directive prior to including the ANSI header
Not necessarily. There are subtle differences between pre-standard headers like iostream.h and standard headers like iostream. That's excluding the difference of namespaces. Simply opening up namespace std and including the standard header may break pre-standard code that expects different behavior.

>This pertains to most, if not all, *.h header files.
Perhaps, though the standard C headers are supported (if deprecated) and well defined. All other .h headers are non-portable extensions.

[Hunter2]

>>declare the "using namespace std;" directive prior to including the ANSI header
As a further note, the <cstdlib> etc. headers do the inverse. They include the C headers, then move the functions to the std namespace. For example, <cstring> from MSVC 2005:

#include <string.h>

namespace std{
using ::size_t; using ::memchr; using ::memcmp;
using ::memcpy; using ::memmove; using ::memset;
using ::strcat; using ::strchr; using ::strcmp;
using ::strcoll; using ::strcpy; using ::strcspn;
using ::strerror; using ::strlen; using ::strncat;
using ::strncmp; using ::strncpy; using ::strpbrk;
using ::strrchr; using ::strspn; using ::strstr;
using ::strtok; using ::strxfrm;
}

Although really, I imagine different compilers will have different methods of doing much the same thing

[CornedBee]

As a further note, the <cstdlib> etc. headers do the inverse. They include the C headers, then move the functions to the std namespace.

While this is the usual method, it's not necessarily the way it's done.
I'm citing from a draft here:

The facilities of the Standard C Library are provided in 18 additional headers, as shown in Table 3:
<cassert> <ciso646> <csetjmp> <cstdio> <ctime>
<cctype> <climits> <csignal> <cstdlib> <cwchar>
<cerrno> <clocale> <cstdarg> <cstring> <cwctype>
<cfloat> <cmath> <cstddef>
Except [...] , the contents of each header cname shall be the same as that of the corresponding header name.h [...]. In the C++ Standard library, however, the declarations and definitions (except for names which are defined as macros in C) are within namespace scope of the namespace std.

Names which are defined as macros in C shall be defined as macros in the C++ Standard library, even if license is granted in C for implementation as functions.

Each C header, whose name has the form name.h, behaves as if each name placed in the Standard library namespace by the corresponding cname header is also placed within the namespace scope of the namespace std and is followed by an explicit using-declaration.

Example: The header <cstdlib> provides its declarations and definitions within the namespace std. The header <stdlib.h> makes these available in the global name space, much as in the C Standard.

So the standard suggests that it should be the other way round: cxxx should declare the elements in the std namespace and xxx.h should import them to the outside. The standard also has more stringent requirements on the macro/function nature of the elements, which means that some C libraries might not be appropriate to be used in a fully conformant C++ implementation.

[xErath]

>>Both <cstdlib> and <stdlib.h> are standard C++.
I thought <stdlib.h> and friends were deprecated?

stdlib.h is C standard, therefore can't be deprecated.
C++ standard defines other practices.

[Prelude]

>stdlib.h is C standard, therefore can't be deprecated.
Only if you're talking about standard C. The C++ standard is very clear that the .h C headers are deprecated. however, that doesn't mean they aren't supported, just not recommended.