0

Basically, the program is compiling on codeblocks, but not on visual studio 2015 unless I add 

#include <string>

to one of the files, then I get about errors from the first line of the code

1>------ Build started: Project: ConsoleApplication2, Configuration: Release Win32 ------
1>  pytanie.cpp
1>pytanie.cpp(25): error C3861: 'getline': identifier not found
1>pytanie.cpp(42): error C2679: binary '<<': no operator found which takes a 
right-hand operand of type 'std::string' (or there is no acceptable 
conversion)

and about 200 lines of this stuff

'std::basic_ostream<char,std::char_traits<char>>
&std::basic_ostream<char,std::char_traits<char>>::operator <<(const void *)'

So the question is, why codeblocks can compile and run this program, but visual studio needs

#include <string>

I found out - thanks to this forum - that using getline and << operator requires including the 'include string' line, but why can codeblocks work without it, or why visual studio 2015 CAN'T?

edit: yes, codeblock is using GNU GCC compiler and VS2015 is using default one

dinguspapaj
  • 85
  • 2
  • 8
  • 2
    Some other header is including `` (or some subset of it) in your codeblocks case. C++ permits standard headers to include other standard headers in unspecified ways. Apparently that is happening with whatever toolchain you're using in codeblocks, but not with Visual Studio. – Michael Burr Feb 28 '16 at 20:01
  • 2
    this has nothing to do with Visual Studio vs CodeBlocks. This has to do with their underlying toolchains' headers, namely that of MSVC and the apparently non-MSVC toolchain CodeBlocks uses (likely GCC+glibc). Apparently, glibc's iostream header includes ``, while that of MSVC doesn't. – The Paramagnetic Croissant Feb 28 '16 at 20:03
  • Neither Visual Studio nor CodeBlocks are compilers. They are programs which invoke compilers. That does not make them compilers, much like `cmd.exe` does not become a compiler just because `cl.exe` is started from there. – Christian Hackl Feb 28 '16 at 20:32
  • @Christian And the standard doesn't talk about compilers, only implementations. – Alan Stokes Feb 28 '16 at 20:33
  • @AlanStokes: Well, it does talk about compilers a few times, but mostly in notes and footnotes. The *only* normative sentence with the word "compiler" in it is *"This property indicates an absence of aliasing and may be used to advantage by optimizing compilers."* in §26.6.2.4 (valarray element access) :) – Christian Hackl Feb 28 '16 at 20:36
  • 1
    @Christian And that should probably be a note anyway ;-) – Alan Stokes Feb 28 '16 at 20:37

1 Answers1

2

Any standard header file is allowed, but not required, to include any other.

So on one compiler one of the headers you're including does include <string>, and on the other compiler none of them do.

This is generally tricky (by which I mean it's extremely hard to get right, even for experts), but for portability I'm afraid you need to know which headers include the declarations you use, and make sure you include all of them.

Alan Stokes
  • 18,815
  • 3
  • 45
  • 64
  • If you use something that is specified to be declared/defined in a certain header you need to include that header because even for a certain platform or compiler the unspecified includes within a file might change It is neither tricky nor hard I think. Relying on anything else is imho a kind of UB. – Pixelchemist Feb 28 '16 at 20:29
  • @Pixelchemist I find it tricky; YMMV. In particular you have to know exactly which overloads you are using (consider `operator >>`, or `getline`), and if you make a mistake you don't get any warnings until you try a different compiler. Example: what headers are required for `std::cout << "hello world" << std::endl;`? (Ignoring the advisability or otherwise of `endl`.) – Alan Stokes Feb 28 '16 at 20:32
  • `#include ` - but the point is: If you do not know which header you need you would have to look it up. That may be annoying but I wouldn't consider it to be difficult. – Pixelchemist Feb 28 '16 at 20:40
  • 3
    @Pixelchemist: Your answer is correct only since C++11. Before that, `` was not guaranteed to include ``, and `std::endl` is in ``. – Christian Hackl Feb 28 '16 at 20:44
  • _"This is generally tricky (by which I mean it's extremely hard to get right, even for experts)"_ What's difficult about it? Google the symbol you're using, click on the first result (which will be a link to cppreference.com), then read the header name at the top of the page. I'll grant you the operators theoretically present a problem, but in practice the library is well enough designed that they mostly don't. – Lightness Races in Orbit Feb 28 '16 at 21:20
  • I forget which toolchain it was, but I have run across at least one that didn't define `std::endl` when you included ``. Very irritating, I'm glad that C++11 fixed that. – Michael Burr Feb 28 '16 at 22:20
  • It also might be helpful for people to know that the C standard does not allow one standard header to include another. In C a standard header is only permitted to define/declare those things that the standard calls out (items in the implementation reserved namespace are obviously excluded, as are non-standard extensions the implementation might have). – Michael Burr Feb 28 '16 at 22:30
  • @ChristianHackl: I know. So your point is that there are different standard versions available? I do not consider this "challenge" to be specific for the "which header do in need to include problem" but it applies to C++ in general. You have to check whether it (whatever you want to use) and the syntax you're using are valid for your compiler or the standard version it is (hopefully) compliant to, anyway. – Pixelchemist Feb 28 '16 at 23:08
  • @Pixelchemist: No, I happen to agree with you about how it's actually easy to get the `#include`s right when you have access to documentation like cppreference.com or even the standard itself or a draft thereof. But your answer to the `std::endl` question was a bad example because, well, the fact that the answer was not entirely correct/complete showed the opposite of what you wanted to say. – Christian Hackl Feb 29 '16 at 07:07