Visual C++ 2010 missing iostream - c++

Let me start by saying, I've never done raw C++ coding before. I've used a C-based language inside of a premade engine, so I understand in a general sense how the syntax works.
I know every script requires a header file that declares most of the basic functions to operate properly, and for C++, this header would be iostream. My issue is the general "Hello world" issue. I've browsed for a few days but never found an appropriate solution, nor does my situation seem to be the same as anyone else's. Here's my script.
#include <iostream.h>
using namespace std;
int main(){
cout<< "Hey" << ;
return 0 ;
}
So yeah. This should compile appropriately. But the issue comes from the first line, which is the #include.
Here is the error message I get when trying to build it:
1>------ Build started: Project: compiler test, Configuration: Debug Win32 ------
1>Compiler test.cpp
1>Compiler test.cpp(1): fatal error C1083: Cannot open include file: 'iostream.h': No such
file or directory
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
This would normally tell me that the header isn't in the proper directory, but when I check the /VC/include directory, iostream is just sitting there. Almost seems like Visual C++ is refusing to acknowledge that it exists. Anyone have a solution to this?

first thing to try is #include <iostream>
There is no .h in the C++ headers

(a) - when asking questions please include the operating system and compiler you are using. The behavior differs between platforms and, sometimes, between releases of the compilers. FRom the looks of the messages, it looks like the compiler is a version of Microsoft's Visual C++.
(b) general usage is to use " (quotes) surrounding header files with .h and angle brackets (< >) around headers without the .h. Note that this is a general usage. The standards governing the two languages (C and C++) actually rule. And they say it's "implimentation-defined" (see this relevant StackOverflow question for excruciating detail). Both usages will bring in the function headers, constants and code to provide the requested functionality. Under MS C++ the iostream header provides linkages to the cout, cin, clog and cerr functions, and the equivelant wide character stream functions wcout, wcin, wclog and wcerr ("wide character" support is, broadly, a way to accomodate character representations that are outside the common ASCII or EBCDIC universe)
(3) Once the header file is being brought in, you will get an error, as Sean noted, on the "hey" statement, because the trailing "<<" is expecting anothjer operand, either another string or a variable of some sort (the "endl" is used to close off the output string you have been building and display it. This is also sometimes referred to as "flushing the buffer.")
(4) if you look through the answer/question database here you will find some lively discussion on the use of "using namespace std" as opposed to specifying the usage for each function in the namespace that you want to use. such as "using std::cout;"
I'm attaching a minimally reworked version of your program below (even showing that you could surround the iostream #include by quotes, which should start a a little flame war):
c:\gpp_code>type text3.cpp
#include "iostream"
using namespace std;
int main()
{
cout<< "Hey" << endl ;
return 0 ;
}
c:\gpp_code>text3
Hey
c:\gpp_code>

Related

Raise compile error if braces not closed at end of file (C++)

Is there a way to raise a warning or error if the C++ compiler comes to the end of file without all braces being closed? We never use headers which spill a scope into another file and would like to receive compiler warnings if it happens by accident. Compiler MSVC 2010, but others might be of interest too.
// Utilities.hpp
namespace example
{
class Utilities
{
}
//<EOF> -> should warn or error
Edit: I am willing to put a marker/pragma/Macro at the end of each file, where I know the brace level should be 0.
A reasonable method is
#define AT_GLOBAL_SCOPE namespace { }
because that can only appear at global or namespace scope. So it unfortunately won't catch that missing } from another namespace, but it will catch the class-case, as well as missing parentheses and semicolons.
In principle, this isn't known by the compiler proper - the preprocessor is sufficiently separate from the compiler proper that different files are "not known", it's just one long stream of source-code as far as the compiler is concerned.
One of the problems here is that the "understanding of the source code" is different at different levels. The preprocessor which inserts the #include ... into the source stream doesn't really know anything about { and } in other ways than "they are not alphanumeric" [which affects how macros and such are handled]. And consider that you could have [even if it's perhaps a bad idea]:
#define START {
#define END }
start
...
...
end
(The C preprocessor CAN be used for other things than C-code, so it's not "meant" to understand the language it is compiling)
I guess you could write a small tool that parses code and just counts up for { and down for }, and check for equality [you have to care for quotes and comments, but everything else should be counted]. But of course, the compiler will eventually tell you in some way, so I'm not sure that's much use. That assumes that there are no uneven sets of braces in macros.

C++ problems with string

I am doing some arduino development using cpp and h files and I am having some troubles using string with them. Currently I have
#include <string>
at the top of both the cpp and the h file. When I do that it gives me the error:
string: no such file or directory
If I go into the h file and change it to
#include <string.h>
then it gives me the error:
std::string has not been declared
Anytime I use the string I use: std::string to declare it. I am not using namespace std and these files were working together fine before I started to try to use string. I am new to C/C++ so I appreciate any help. Thanks!
In short, there is a way to use std::string with the Arduino.
TL;DR:
link to the arduino STLv1.1.2
NOTE
Please note that currently the harrdwareserialstream class provided by this STL should be considered broken (as per my testing, with version 1.6.5 of the IDE, and possibly anything after 1.0.6). therefore, you can't use
hardwareserialstream << "Hi there person number " << (int)i
and so on. it seems to no longer work due to taking a reference to the serial port it would interact with rather than a pointer - in short, continue using
Serial.print("Hi there person number");
Serial.print((int)i);
Lastly the serial classes don't know what a std::string is, so if using them, give it std::string.c_str() instead
Background
As McEricSir says in the comments, the arduino does provide its own string class, though i have found it to have problems related to memory leakage, which eventually ate all of the memory i had and the program stopped running - though this was in the arduino IDE v 1.0.5, it may have been fixed since then.
I had the same problem, and found someone who had created a version of the STL for the arduino (props to Andy Brown for this) which is a cutdown version of the SGI STL. it provides std::string, std::vector and a large amount of the STL to the arduino.
there are some things to be aware when using it though; if you have a board with very little memory, you will fill it quite quickly using the smart containers and other advanced features.
Using the Library
To use the library, you'll need to read the article, though I'll summarise the main points for you here:
Installation
simply extract the library to (assuming you are using the standard Arduino IDE) hardware\tools\avr\avr\include folder and you are good to go.
Using It
To actually use the new libraries, you need to include 2 additional things as well as the library you wanted.
firstly, you need to include the header iterator BEFORE any libraries that come from this STL - and in every file you reference the STL in.
Secondly, you also need to include the file pnew.cpp to provide an implementation of the new operator for the STL to work with.
Lastly, include any header files as you would normally.
to make use of the types gained from them, don't forget the the std:: namespace notation for them. (std::string and so on)
Bugs with it
Since Andy posted the library, there have been two bugs (that i'm aware of).
The first one Andy himself rectifies and explain in the blog post:
The compiler will spit out a typically cryptic succession of template errors, with the key error being this one:
dependent-name std::basic_string::size_type is parsed as a non-type,
but instantiation yields a type c:/program files (x86)/arduino-1.0/
hardware/tools/avr/lib/gcc/../../avr/include/string:1106: note:
say typename std::basic_string::size_type if a type is meant
Basically the STL was written a long time ago when C++ compilers were a little more forgiving around dependent types inherited from templates. These days they are rightly more strict and you are forced to explicitly say that you mean a type using the typename keyword.
Additionally, he provides the updated version for you to grab.
Lastly, there are reports in the comments about a bug in the newer versions of the IDE pertaining to the vector class where the compiler complains about the use of _M_deallocate without a prepending this->, which you can fix if you search for them inside the vector class
For your convenience
As i use this quite frequently, i've packaged up the current version, which can be found here (this includes both the fixes i have commented on)
Lastly
When using this, make sure to keep an eye on your free memory, and to that end i recommend the excellent class MemoryFree Library found here
on a side note if you #include<string> inside the header you won't need to include it in the relevant .cpp file

How to define a constant in C++?

I complied a linux program on windows via Mingw. However, the conversion was not perfect.
For example, on Windows the output is this (I get 'zu' instead of real numbers):
Approximated minimal memory consumption:
Sequence : zuM
Buffer : 1 X zuM = zuM
Table : 1 X zuM = zuM
Miscellaneous : zuM
Total : zuM
It turns out that Mingw does not support %zu but it offers an workaround. On their web site they say:
This will never work since you are using Microsoft's implementation.
Use mingw_printf directly or define USE_MINGW_ANSI_STDIO to 1 before
including stdio.h.
So, I did a search in my program and I have found that cdhit-common.h is the only file that has a #include line. So, I defined the USE_MINGW_ANSI_STDIO above that line and compiled:
#include<iostream>
#include<fstream>
#include<iomanip>
#include<cstdlib>
#define USE_MINGW_ANSI_STDIO 1
#include<stdio.h>
...
It compiles but the program still outputs 'zu' instead of numbers. Is it ok what I have done? Why didn't worked?
Note: The solution with USE_MINGW_ANSI_STDIO is for mingw64 while I use mingw. I hope is for both platforms.
The macros that I managed to google right now is: __USE_MINGW_ANSI_STDIO. Try it.
You are setting a pre-processor flag. That means that when the compiler reads <stdio.h> it will have USE_MINGW_ANSI_STDIO set to 1. This would potentially used in a compiler directive #if or #ifdef.
It is generally preferable to put these flags into your compile flags e.g.
-DUSE_MINGW_ANSI_STDIO=1 rather than into the code.
( Note: it appears it might be -D__USE_MINGW_ANSI_STDIO=1 )
If you do put it into the code, do so either
In a header that is always included before anything else, e.g. some "platform related" header.
Before any other includes in your file.
It is possible that one of the C++ streaming headers implements using <stdio.h>

I need help figuring out why this C++ program will not build and run in codeblocks using the GNU CC compiler

I do not understand why this C++ program will not build and run using Codeblocks and the GNU CC compiler.
#include <iostream>
using namespace std;
int main()
{
string firstName;
firstName = "Brandon";
cout << "Hello " << firstName << endl;
return 0;
}
Want to use strings? You'll need to #include it.
#include <string>
In general, when you use a class, function or such, you should look up (unless you have memorised it from using it many times) what header the class or type should.
For example, this page is the first hit in google for C++ string:
http://www.cplusplus.com/reference/string/string/
On this particular page, it shows <string> on the left-hand side of the page, to indicate that <string> is the header for this particular class.
Occassionally it is possible to use a class or function without including its correct header. It is, however, very bad form to RELY on such behaviour (unless you are in direct control of that header, of course). It appears that your example, when it does #include <iostream>, is indeed relying on that also doing #include <string>. It would then appear that this is not the case in your combination of OS & Compiler, hence you get an error.
And unfortunately, the error messages when you use << for output of unknown types or otherwise make a mistake in that type of code, can be extremely unhelpful and often quite verbose as well (e.g. I missed out the << between the actual output stream and some text the other day, and I got a good page full of error messages, none of which made much sense at all - but it gave me which line was wrong, and that was enough for me to eventually spot the error).

C++ can't find non-standard C functions in global namespace

We have a fairly large C++ project which I am now in the process of moving to VS2010 and also updating a few libs along the way. So far everything builds just fine now, except I get (to me) quite weird errors where apparently a number of (edit: non-)standard C functions and symbols are not defined:
error C2039: 'strdup' : is not a member of '`global namespace'' ...\ACE_wrappers\ace\OS_NS_string.inl 222
...
error C2065: 'O_WRONLY' : undeclared identifier ...\ACE_wrappers\ace\OS_NS_unistd.inl 1057
...
This affects the following functions and symbols for me:
strdup getcwd O_WRONLY
putenv swab O_TRUNC
access unlink S_IFDIR
chdir mkdir S_IFREG
rmdir tempnam O_RDONLY
isascii
One part in the include file from ACE I experimented with was the strdup part which looks like this:
ACE_INLINE char *
ACE_OS::strdup (const char *s)
{
# if (defined (ACE_LACKS_STRDUP) && !defined(ACE_STRDUP_EQUIVALENT)) \
|| defined (ACE_HAS_STRDUP_EMULATION)
return ACE_OS::strdup_emulation (s);
# elif defined (ACE_STRDUP_EQUIVALENT)
return ACE_STRDUP_EQUIVALENT (s);
# elif defined (ACE_HAS_NONCONST_STRDUP)
return ::strdup (const_cast<char *> (s));
#else
return ::strdup (s);
# endif /* (ACE_LACKS_STRDUP && !ACE_STRDUP_EQUIVALENT) || ... */
}
There are loads of similar sections for other functions above and below, all of which compile just fine.
The path taken in my case is the last one, i.e. return ::strdup (s);. If I hit F12 on the ::strdup VS takes me to the declaration in string.h of the C standard library.
If I remove the namespace qualifier it builds, although IntelliSense tells me that it's now a recursive call so it probably won't work. If I change the namespace to std:: I get around 270 more errors, this time from several other projects. If I change the function to ::_strdup it builds. Including string.h as the very frst thing changes nothing.
(Nota bene: “it builds” refers to “this particular compiler error disappears at that location, but it still leaves the errors about the other functions, obviously.)
I'm a little at a loss here. I noticed that many larger libraries either build their own abstraction over the standard library or provide things that are not there by default and that was a point where ACE and ImageMagick already clashed (in both typedefing ssize_t but with incompatible definitions). Since we pull in quite a few libraries (I don't have an exact overview either, right now) this could well be another clash, caused by the wrong include order and similar things. This is also hinted at by the fact that the same includes from ACE apparantly work fine in other projects in the same solution.
Anyone have an idea what I could look for here at least? The build log with /showIncludes is just 24k lines so I don't exactly see many patterns there, except that string.h gets included way before the problematic ACE header.
And I wouldn't want to modify the library source code as that will only bite us again if we update to a newer version.
"a number of standard C functions and symbols are not defined"
strdup is not a standard C function. It is defined in POSIX, but not in C or C++. Quoting MSDN:
These POSIX functions are deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _strdup, _wcsdup, _mbsdup instead.
It appears to me that none of the symbols you list are standard C functions.
With Mark B's comment which prompted me to look at 12 MiB of Preprocessor output I was able to solve it. In string.h the snippet where strdup is defined looks like this:
#if !__STDC__
...
_Check_return_ _CRT_NONSTDC_DEPRECATE(_strdup) _CRTIMP char * __cdecl strdup(_In_opt_z_ const char * _Src);
It so happened that this single project defines the __STDC__ symbol which causes a lot of non-standard-C-but-still-in-the-C-standard-library (thanks, Robφ for nitpicking but not solving the issue) functions to disappear completely.
I know they're deprecated, I got plenty of warnings that tell me so. But as noted, I'm not maintaining project-specific patches to 3rd-party libraries we use just to have the same fun all over again if we ever update them.
If I understand VS correctly, the strdup, etc. function names are deprecated nowadays (not POSIX compliant, I think). You should use the underlined versions.
When this happened for me, I ran a global search and replace, since it seemed like a sensible thing to do and keeps the source code in good condition for the future (VS 2012 is already out! :) ).