I've found STL's power in the numeric header that computes power(TYPE T, Integer a) in O(log(a)), but when I've written that and compiled it with g++ it gave me compile error and says error: ‘power’ was not declared in this scope. Why it happens? I know writing the power function that computes in O(log(N)) is easy buy I want to know if there is a ready function in C++'s standard libraries. Isn't any feature added in C++11 standard?
That function was in SGI's original STL, but isn't in the standard library.
In the GNU library, it's available as an extension, __gnu_cxx::power in <ext/numeric>.
From the page you link:
This function is an SGI extension; it is not part of the C++ standard.
While the SGI-documentation is often helpful, be aware that it contains several deviations from the standard.
No there's no std::power or similar algorithms in C++11.
In the <cmath> header there are several overloads for the standard numeric types. Is there a particular reason you need a templated version?
Related
I'm implementing a DSL with a compiler that translates it into C. Our code is self-contained: we provide users with just one main entry point (i.e., void step()), all inputs are given in global variables with simple types (bool, signed/unsigned ints, double, float, structs, and arrays; but no pointers, and no functions as inputs).
Our main target is C99, but some people are using the arduino compiler for the code we produce, so maximum portability across standards and compilers is preferred.
I see that C99's math.h defines multiple variants of functions based on the type of the arguments (e.g., sin, sinf, sinl).
To avoid losing precision, our translator can, based on the types of the arguments, pick one of those variants. However, all functions we support are also defined by tgmath.h, so a simpler way would be to use the standard name for each (e.g., sin) and let tgmath.h pick the appropriate variant based on the types of the arguments.
I've read online that opinions on tgmath.h, and support, are mixed. Some people say it is ugly, and that not all compilers support it.
Is relying on tgmath.h a bad idea? Is this going to give us headaches down the line?
A C99 (page 165 and 335 in the standard) compliant compiler will include tgmath.h so relying on tgmath.h is ok. It's a standard header since C99.
I am using gcc 4.2.4.
According to Schildt, "C++ The Complete Reference", 1995, user defined parameterized manipulators should be defined as:
istream &mymanip(istream &stream, type param)
{
// here my code
return stream;
}
// overload
imanip<type> mymanip(type param){
return imanip<type>(mymanip, param)
}
// usage
cin >> mymanip(param);
I believe that imanip(mymanip, param) is supposed to return an object that contains mymanip and mymanip's arguments. This should be used by an overloaded operator>> to call mymanip. However, this does not work, imanip is not declared.
I also found this version:
IMANIP(int) fld(int n){
return IMANIP(int)(fld,n);
}
which also does not work.
My questions are:
does gcc 4.2.4 follow the ANSI C++ standard on this detail or not? If it does, did the standard change since 1995 in this respect?
in order to define my own parameterized manipulators do I need to understand the iostream code and write my own overloaded imanip and operator>> functions?
regardless the answer to question 2, what is the best strategy for me to understand the iostream code? Should I read the code? How do I find out the names of compiled libraries which are part of iostream? Should I read a book?
The code you posted seems out of context. imanip looks like some template, but that template is never defined anywhere in your code.
But to be honest, I would not even consider using a 1995 book on C++ any more. In 1995 C++ was not even standardized, although there existed an "annotated reference manual". Your book is over 17 years old, which means "more than extremely outdated" when it comes to programming languages. C++ has evolved a lot since then, you should consider to buy a more recent book, perhaps take a look at http://isocpp.org/get-started to give you some examples.
To give you more specific answers to your questions:
Yes, gcc follows the standard in this regard, but your book might not, because it is pre-standard.
Manipulators are made so you do not have to reimplement the op<< and op>> again. However, depending on what your manipulators are designed to do, you might need to call some of the lower level methods provided by the stream or streambuf.
"The code" does not exist, there are several implementors of standard libraries, and they all have their own, sometimes very complicated code for etc. I would recommend to search the web for information about how those libraries work. Of course, a book is even better. Consider buying "The C++ Standard Library" by N. Josuttis. There is a recent Edition that covers the standard library "as of now and tomorrow", i.e. including the additions of the C++11 standard.
I have an error while compiling a library using XCode:
'powf' is not a member of 'std'
The <cmath> is included.
Can someone explain to me what is going wrong?
Up until C++11, powf was just a Microsoft-ism. It did not appear in the ISO standard at all so is unlikely to be in XCode unless they were to adapt Microsoft's bizarre practices, something I would think unlikely.
pow, on the other hand, has been part of the C++ library for longer by virtue of the fact that it's in earlier iterations of the C library that is incorporated into C++ pre-11. Use that instead.
Since C++11, powf does appear in the ISO standard and is part of the std namespace.
Nevertheless, there are non-compliant implementations e.g., gcc libstdc++. More resources in this excerpt taken from a discussion in cppreference talk page:
Answers posted above were correct before C++11, since C++98/03 hadn't referred C99 library yet. According to the current standard, powf is declared in namespace std when is included (explicitly mentioned since C++17, implicitly mentioned in C++11/14, see also N4659, N4140 and N3337). For std::powf, gcc libstdc++ is not compliant while clang libc++ is. --Fruderica (talk) 03:49, 19 February 2019 (PST)
See also this, more recent, SO answer: https://stackoverflow.com/a/54735351 --Cubbi (talk) 08:10, 19 February 2019 (PST)
Use just pow - powf isn't standard.
It is named std::pow and overloaded for float and double.
This MSDN article states that getcwd() has been deprecated and that the ISO C++ compatible _getcwd should be used instead, which raises the question: what makes getcwd() not ISO-compliant?
There is a good discussion about that. P.J. Plauger answers to this
I'm the guy who insisted back in 1983 that the space of
names available to a C program be partitioned into:
a) those defined by the implementation for the benefit of the programmer (such as printf)
b) those reserved to the programmer (such as foo)
c) those reserved to the implementation (such as _unlink)
We knew even then that "the implementation" was too monolithic --
often more than one source supplies bits of the implementation --
but that was the best we could do at the time. Standard C++
has introduced namespaces to help, but they have achieved only
a fraction of their stated goals. (That's what happens when you
standardize a paper tiger.)
In this particular case, Posix supplies a list of category (a) names
(such as unlink) that you should get defined when and only when you
include certain headers. Since the C Standard stole its headers from
Unix, which is the same source as for Posix, some of those headers
overlap historically. Nevertheless, compiler warnings should have
some way of taking into account whether the supported environment
is "pure" Standard C++ (a Platonic ideal) or a mixed C/C++/Posix
environment. The current attempt by Microsoft to help us poor
programmers fails to take that into account. It insists on treating
unlink as a category (b) name, which is myopic.
Well, GCC will not declare POSIX names in strict C mode, at least (though, it still does in C++ mode):
#include <stdio.h>
int main() {
&fdopen;
return 0;
}
Output using -std=c99
test.c: In function 'main':
test.c:4: error: 'fdopen' undeclared (first use in this function)
You will have to tell it explicitly that you are operating in a mixed C/Posix by using feature test macros or not passing any specific standard. It will then default to gnu89 which assumes a mixed environment (man feature_test_macros). Apparently, MSVC does not have that possibility.
Functions not specified in the standard are supposed to be prefixed by an underscore as an indication that they're vendor-specific extensions or adhere to a non-ISO standard. Thus the "compliance" here was for Microsoft to add an underscore to the name of this specific function since it's not part of the ISO standard.
As others have already pointed out, getcwd is not included in ISO C++, but is part of POSIX/IEEE Std 1003.1.
Microsoft has decided to include some of the most commonly used POSIX functions in their C standard library (but prefix these functions with an underscore to essentially discourage their usage).
For the record, getcwd() wasn't deprecated by ISO. It was "deprecated" by Microsoft. Microsoft rewrote many C functions -- often with a little better security in mind (say, string functions that also take a max_length parameter). They then had their compiler spit out these warnings, which I consider bogus because no standards group deprecated any of the functions declared deprecated.
To add on to Dan Olson's post: See ANSI C Compliance page on MSDN
The names of Microsoft-specific functions and global variables begin with a single underscore. These names can be overridden only locally, within the scope of your code. For example, when you include Microsoft run-time header files, you can still locally override the Microsoft-specific function named _open by declaring a local variable of the same name. However, you cannot use this name for your own global function or global variable.
As far as I'm aware getcwd() has never been part of ISO Standard C++. _getcwd() definitely isn't, as standard names will not begin with an underscore.
In fact, the MSDN article links to a man page that says it is declared in direct.h, which is not a Standard C++ header file. The article seems bogus to me.
The MSDN article is somewhat confusing in what a normal person would conclude from just a quick reading (if they don't read it with a very careful lawyer eye).
What the MSDN article says is: getcwd() is not compliant with the ISO C++ standard. To comply with that ISO C++ standard for naming of functions (which is what getcwd violates), Microsoft properly put an _ on the front of the function, so the same function becomes _getcwd(). That is the ISO C++ compliant way of naming the function because getcwd() and _getcwd() are not an ISO C++ standard function, but are a Microsoft (vendor) specific, or implementation specific function.
The article does not indicate what a C++ ISO standard call to get the working directory would be... though thats what folks tend to read at a quick glance.
This MSDN article states that getcwd() has been deprecated and that the ISO C++ compatible _getcwd should be used instead, which raises the question: what makes getcwd() not ISO-compliant?
There is a good discussion about that. P.J. Plauger answers to this
I'm the guy who insisted back in 1983 that the space of
names available to a C program be partitioned into:
a) those defined by the implementation for the benefit of the programmer (such as printf)
b) those reserved to the programmer (such as foo)
c) those reserved to the implementation (such as _unlink)
We knew even then that "the implementation" was too monolithic --
often more than one source supplies bits of the implementation --
but that was the best we could do at the time. Standard C++
has introduced namespaces to help, but they have achieved only
a fraction of their stated goals. (That's what happens when you
standardize a paper tiger.)
In this particular case, Posix supplies a list of category (a) names
(such as unlink) that you should get defined when and only when you
include certain headers. Since the C Standard stole its headers from
Unix, which is the same source as for Posix, some of those headers
overlap historically. Nevertheless, compiler warnings should have
some way of taking into account whether the supported environment
is "pure" Standard C++ (a Platonic ideal) or a mixed C/C++/Posix
environment. The current attempt by Microsoft to help us poor
programmers fails to take that into account. It insists on treating
unlink as a category (b) name, which is myopic.
Well, GCC will not declare POSIX names in strict C mode, at least (though, it still does in C++ mode):
#include <stdio.h>
int main() {
&fdopen;
return 0;
}
Output using -std=c99
test.c: In function 'main':
test.c:4: error: 'fdopen' undeclared (first use in this function)
You will have to tell it explicitly that you are operating in a mixed C/Posix by using feature test macros or not passing any specific standard. It will then default to gnu89 which assumes a mixed environment (man feature_test_macros). Apparently, MSVC does not have that possibility.
Functions not specified in the standard are supposed to be prefixed by an underscore as an indication that they're vendor-specific extensions or adhere to a non-ISO standard. Thus the "compliance" here was for Microsoft to add an underscore to the name of this specific function since it's not part of the ISO standard.
As others have already pointed out, getcwd is not included in ISO C++, but is part of POSIX/IEEE Std 1003.1.
Microsoft has decided to include some of the most commonly used POSIX functions in their C standard library (but prefix these functions with an underscore to essentially discourage their usage).
For the record, getcwd() wasn't deprecated by ISO. It was "deprecated" by Microsoft. Microsoft rewrote many C functions -- often with a little better security in mind (say, string functions that also take a max_length parameter). They then had their compiler spit out these warnings, which I consider bogus because no standards group deprecated any of the functions declared deprecated.
To add on to Dan Olson's post: See ANSI C Compliance page on MSDN
The names of Microsoft-specific functions and global variables begin with a single underscore. These names can be overridden only locally, within the scope of your code. For example, when you include Microsoft run-time header files, you can still locally override the Microsoft-specific function named _open by declaring a local variable of the same name. However, you cannot use this name for your own global function or global variable.
As far as I'm aware getcwd() has never been part of ISO Standard C++. _getcwd() definitely isn't, as standard names will not begin with an underscore.
In fact, the MSDN article links to a man page that says it is declared in direct.h, which is not a Standard C++ header file. The article seems bogus to me.
The MSDN article is somewhat confusing in what a normal person would conclude from just a quick reading (if they don't read it with a very careful lawyer eye).
What the MSDN article says is: getcwd() is not compliant with the ISO C++ standard. To comply with that ISO C++ standard for naming of functions (which is what getcwd violates), Microsoft properly put an _ on the front of the function, so the same function becomes _getcwd(). That is the ISO C++ compliant way of naming the function because getcwd() and _getcwd() are not an ISO C++ standard function, but are a Microsoft (vendor) specific, or implementation specific function.
The article does not indicate what a C++ ISO standard call to get the working directory would be... though thats what folks tend to read at a quick glance.