I am working on an older project that still has the deprecated "#include iostream.h" inclusions. I understand that iostream.h is deprecated and should not be used, but some of the systems that this code has to run/compile on are old solaris machines running CC and do not have iostream available. My question is: how can I make my more modern g++ compiler accept the iostream.h inclusions.
EDIT: The compilier cannot find the iostream.h file so I am assuming that none of the .h versions of the library are available to g++.
The easiest solution is probably to create a local header file called iostream.h which just includes <iostream> and imports the namespace std. Then, in order for the compiler to allow #include <iostream.h> you add the local path to your include file search path. For g++, this works:
g++ -I local_folder [other flags] …
Incidentally, your remark about
… the deprecated "#include iostream.h"
isn’t quite correct: this isn’t deprecated because it has never been legal C++.
I'd take a step back and write another intermediate header you use everywhere instead that does something like:
#if defined(sun) || defined(__sun)
# if defined(__SVR4) || defined(__svr4__)
/* Solaris */
#include <iostream>
# else
/* SunOS */
#include "iostream.h"
# endif
#else
/* Sane, modern system */
#include <iostream>
#endif
Related
I have a C++ project in Netbeans on my Linux Mint 17.2 machine. I'm using the GCC 5 toolchain (e.g. g++ 5.3.0), Netbeans 8.1, and Boost 1.61.0.
I'm encountering a weird warning in my project that shows up all over the place. For instance, in my main.cpp, I #include <iostream> at the very top, and that line gets a warning. (I see this warning happen for the first file I include in every file, so it is not an issue with iostream etc.).
The warning is that there is a recursive #include in boost. Specifically, Netbeans complains that <boost/predef/os/bsd/free.h> includes <boost/predef/os/bsd.h> and that <boost/predef/os/bsd.h> includes <boost/predef/os/bsd/free.h>. For the record, this appears to be true - does anyone know why there is this recursive include in boost, and if it is really supposed to be there?
The bigger issue is that my system is not BSD, so I don't know why I'm getting these warnings from the BSD headers, which shouldn't be included or active/defined. I tried printing BOOST_PLATFORM_CONFIG from my main.cpp, and it prints out the path to boost's Linux config header, as expected - not the BSD config header. And, my program compiles and runs fine, so I'm assuming it's never actually using the BSD headers. Which means that the fact that these BSD headers are giving me warnings might be a Netbeans problem, not a boost problem.
Does anyone have any ideas on how to narrow down and fix this issue with these strange recursive include warnings?
I was having the same problem. The issue is with the boost predef/os/bsd.h header. It #includes 5 files in the #else block for the #ifndef BOOST_PREDEF_OS_BSD_H guard. This means that this header file is not guarded against recursion if any of those 5 files also includes bsd.h (which they do).
My solution was to edit the predef/os/bsd.h file and add a recursion guard in the #else block - so, starting at around line 94 my predef/os/bsd.h file now looks like:
#ifndef BOOST_PREDEF_OS_BSD_H_PREVENT_RECURSION <-- ADD THIS
#define BOOST_PREDEF_OS_BSD_H_PREVENT_RECURSION <-- ADD THIS
#include <boost/predef/os/bsd/bsdi.h>
#include <boost/predef/os/bsd/dragonfly.h>
#include <boost/predef/os/bsd/free.h>
#include <boost/predef/os/bsd/open.h>
#include <boost/predef/os/bsd/net.h>
#endif <-- ADD THIS
And now netbeans code assistance is happy and my code still links and compiles without error.
The rough way: comment
#include <boost/predef/os/bsd.h>
Everywhere (should be inside the following headers)
predef/os.h
predef/other/endian.h
I am using dirent.h 1.20 (source) for windows in VC2013.
I can't find mkdir() in it.
How am I supposed to use it? Or can I create a directory somehow only using dirent.h?
simplest way that helped without using any other library is.
#if defined _MSC_VER
#include <direct.h>
#elif defined __GNUC__
#include <sys/types.h>
#include <sys/stat.h>
#endif
void createDir(string dir) {
#if defined _MSC_VER
_mkdir(dir.data());
#elif defined __GNUC__
mkdir(dir.data(), 0777);
#endif
}
Update: Since C++17, <filesystem> is the portable way to go. For earlier compilers, check out Boost.Filesystem.
The header you are linking to is effectively turning your (POSIX) dirent.h calls into (native) Windows calls. But dirent.h is about directory entries, i.e. reading directories, not creating ones.
If you want to create a directory (mkdir()), you need either:
A similar wrapping header turning your (POSIX) mkdir() call into the corresponding (native) Windows function calls (and I cannot point out such a header for you), or
use the Windows API directly, which might be pragmatic but would lead to a really ugly mix of POSIX and Windows functions...
// UGLY - these two don't belong in the same source...
#include <dirent.h>
#include <windows.h>
// ...
CreateDirectory( "D:\\TestDir", NULL );
// ...
Another solution would be to take a look at Cygwin, which provides a POSIX environment running on Windows, including Bash shell, GCC compiler toolchain, and a complete collection of POSIX headers like dirent.h, sys/stat.h, sys/types.h etc., allowing you to use the POSIX API consistently in your programming.
Visual Studio includes the <direct.h> header.
This header declares _mkdir and _wmkdir, which can be used to create a directory, and are part of the C libraries included with Visual Studio.
The other "easy" option would be to use Windows API calls as indicated by DevSolar.
You can use sys/types.h header file and use
mkdir(const char*) method to create a directory
Following is the sample code
#include<stdio.h>
#include<string.h>
#include <unistd.h>
#include<sys/stat.h>
#include<sys/types.h>
int main()
{
if(!mkdir("C:mydir"))
{
printf("File created\n");
}
else
printf("Error\n");
}
mkdir is deprecated. Give #include <direct.h> as a header file. then write
_mkdir("C:/folder")
I'm trying to port a Linux library to run on VxWorks. I have successfully built binutils and gcc to target i486-wrs-vxworks and I can successfully build a simple C program. However, when I try to compile C++, things break.
I have a simple Hello World program:
#include <string>
#include <iostream>
int main()
{
std::string s = "Hello World";
std::cout << s << std::endl;
return 0;
}
To build it, I call:
i486-wrs-vxworks-gcc -I/home/kyle/vxworks-6.9/target/usr/h -I/home/kyle/vxworks-6.9/target/usr/h/c++ hello.cpp
This always fails with the message:
In file included from /home/kyle/vxworks-6.9/target/usr/h/c++/cerrno:4:0,
from /home/kyle/vxworks-6.9/target/usr/h/c++/xlocnum:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/ios:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/ostream:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/istream:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/string:4,
from hello.cpp:1:
/usr/local/lib/gcc/i486-wrs-vxworks/4.6.4/../../../../i486-wrs-vxworks/include/yvals.h:4:24: fatal error: yvals.h: No such file or directory
If I go look inside /usr/local/i486-wrs-vxworks/include/yvals.h, this is what I see:
/* yvals.h values header for conforming compilers on various systems */
#if (defined(__cplusplus) && defined(__GNUC__))
/* GCC C++ has it's own yvals.h */
#include_next <yvals.h>
#else /* __cplusplus && __GNUC__ */
#ifndef _YVALS
#define _YVALS
#ifdef _NO_WINDRIVER_MODIFICATIONS
#include <stdarg.h>
#endif
...
It appears that there is another yvals.h that needs to be included, but I can't find it anywhere. Did I just fail at building gcc correctly, or is there a way to fix this?
Which version of VxWorks are you using for this?
I have a fuzzy recollection that when upgrading VxWorks versions in the past there was a syntax error in yvals.h that was I needed to work around and it was fixed in a subsequent version.
Also, you can get the gcc cross compiler pre-built from WindRiver. Just login to windriver.com/support with your licence number and head to "Downloads" for your product version.
I went through a recent cross compiling nightmare myself (not VxWorks related) except that instead of yvals.h, I was having grief with stddef.h. The problem turned out to be that I needed to specify the include paths for the system header files.
Here are the steps it took me to solve my error messages. Feel free to modify as appropriate.
Create a file foo.c
#include <stddef.h> /* The problem header file (yvals.h for you?) */
int main (void) {
return 0;
}
Compile it with your compiler of choice
$(CC) foo.c -E
Note the include paths it uses and set them as your system header file list using the
-isystem <include path>
option.
Hope this helps.
As per this answer, I tried printing a uint64_t, but it gives me an error:
error: expected ``)' before 'PRIu64'
Following is the minimal code showing what I am trying to do:
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
#include <cstdio>
class X {
X() {
uint64_t foo = 0;
printf("%07" PRIu64 ": ", foo);
}
};
int main() {}
This minimal code compiles, but my actual code does not. However, I have tried with the 2 lines inside X::X() exactly the same in my actual code, and that does not work.
What should I look for to debug this further? My actual code also #includes other headers. Could that be causing the problem? Does order of including the headers matter?
Edit
PRIu64 is defined as follows on my machine:
# if __WORDSIZE == 64
# define __PRI64_PREFIX "l"
# define __PRIPTR_PREFIX "l"
# else
# define __PRI64_PREFIX "ll"
# define __PRIPTR_PREFIX
# endif
# define PRIu64 __PRI64_PREFIX "u"
In C++ the macros are not automatically defined just by including the file.
You need to add the following:
#define __STDC_FORMAT_MACROS 1
before
#include <inttypes.h>
How to printf uint64_t? Fails with: "spurious trailing ‘%’ in format"
One other possibility for this issue I just found in my own code is if another header already pulls in <inttypes.h> before you define __STDC_FORMAT_MACROS. For example:
Utils.h (Perhaps originally written for C, as it was in our case):
#include <inttypes.h>
// ... Function declarations
MyFile.cpp:
#include "Utils.h"
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
Since inttypes.h has already been included by Util.h, the compiler doesn't include it again, and doesn't see the declaration of __STDC_FORMAT_MACROS.
The solution is either to edit Utils.h to include #define __STDC_FORMAT_MACROS, or to make sure to define it before doing any includes in MyFile.cpp.
#define __STDC_FORMAT_MACROS
#include "Utils.h"
#include <inttypes.h>
The original setup actually compiled just fine on GCC 4.8 on Ubuntu, but failed with an old ltib GCC 4.3 toolchain for PowerPC, which made it all the more perplexing at first.
PRIu64 is not defined where you use it.
Replace it with the string "llu" and your code will compile (but that is not a fix, it just demonstrates the problem)
Maybe the include is missing. Maybe over zealos include guards and it being included without the magic token block the define. Maybe your pch is busted.
If you are on android JNI platform. Put this in your Android.mk:
LOCAL_CPPFLAGS := -D__STDC_FORMAT_MACROS
I have the following source code. Which compiles fine in visual studios and g++ 3.4.6; but not with g++ 4.4.3 (on a newer ubuntu machine). The newer compiler requires that I explicitly include to use atoi. I am just trying to figure out what might have changed to cause this behavior. Is it sstream header file previously included cstdlib and no longer does so. Or is it the compiler behavior that has changed.
#include <sstream>
int main()
{
char str1[]="123";
int i = atoi(str1);
printf ("value = %d",i);
return 0;
}
You also need to include <cstdio> for printf().
Technically, if you include the headers of the form <cname> instead of <name.h>, you also need to qualify the names from the standard library using std::. A lot of standard library implementations are relaxed when it comes to this, though, and also put the names into the global namespace.
It's implementation-dependent which headers are included by which other headers, so you should always be sure to include all the headers that you need and not assume that they will be included automatically.
I'm using GCC 4.4.5 on Debian, and the headers have changed so you will not bring in the headers necessary. You need to #include <cstdlib> and #include <cstdio> to get atoi and printf, as the compiler complained about both being missing.
#include <sstream>
#include <cstdio>
#include <cstdlib>
int main()
{
char str1[]="123";
int i = std::atoi(str1);
std::printf ("value = %d",i);
return 0;
}
Well yes. That is common. You should always include ALL headers that you are directly using and not depend on the fact that those headers are already included.
Compiler behavior is what would have changed... the <sstream> doesn't use atoi.
Arguably you should have always done #include <cstdlib>, and you'd gotten lucky with your previous compilers.
As James McNeillis points out, you should also #include <cstdio> in order to use the printf function.