How is it this code compiles without errors in VS 2013 ?

[Bob Langelaan]

#include <iostream>

int main()
{
char array[30];
strcpy(array, "How is this possible?");
}

I thought the cstring library would need to be included.

Thanks,
Bob

[Melzzzzz]

It needs to be included. It compiles with your compiler but not with
mine.

[Ian Collins]

cstring *header*

It does.

Standard headers are free to include others.

--
Ian Collins

[Paavo Helde]

Bob Langelaan <bobl...@gmail.com> wrote in news:ea61b269-d359-4f43-827d-
b722d8...@googlegroups.com:

I think this is covered by 17.6.2.1/3:

"A translation unit [...] shall include the header lexically before the
first reference in that translation unit to any of the entities declared
in that header. No diagnostic is required."

and 1.4/2:

"If a program contains a violation of a rule for which no diagnostic is
required, this International Standard places no requirement on
implementations with respect to that program."

IOW, your program may compile or then not, and may appear to work, or
then not.

hth
Paavo

[Paavo Helde]

Paavo Helde <myfir...@osa.pri.ee> wrote in
news:XnsA3ED66E2ECD2Fm...@216.196.109.131:

> I think this is covered by 17.6.2.1/3:
>
> "A translation unit [...] shall include the header lexically before the
> first reference in that translation unit to any of the entities declared
> in that header. No diagnostic is required."

Clarification: this rule talks about the standard library headers only.

[Jorgen Grahn]

Sounds serious, so I'll elaborate. What happens in practice is that:

- It's hard to remember to include the exact right set of headers --
but it helps somwehat to stop for a moment like "ok, now I'm using
std::strcpy for the first time in this file -- let's see if I've
included <cstring>".

- There are no tools that I'm aware of that let you find stuff like
this.

- When you use a new compiler or library [version] on the code for the
first time, more of these problems may pop up (because they may have
tightened up <iostream> so it doesn't pull in <cstring>. So you fix
these problems and move on.

In other words: it's annoying, but nothing to really worry about.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[JiiPee]

yes, thats why I think its not a good programming practice as not
working "out of box" on other compilers.

[Richard]

[Please do not mail me a copy of your followup]

Bob Langelaan <bobl...@gmail.com> spake the secret code
<ea61b269-d359-4f43...@googlegroups.com> thusly:

It compiles by accident because somewhere inside the MSVC
implementation of <iostream> they end up including another header that
happens to declare strcpy.

If you had included <cstring>, then you should have used std::strcpy.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Geoff]

In the case of Visual Studio, it is. Headers may include headers and
the cascade eventually finds your cstring header. In the IDE you can
view the External Dependencies tree in the Solution Explorer to see
the effects of including or not including a header. Open the External
Dependencies tree and see the list of headers implicitly included due
to your inclusion of iostream, then comment the inclusion out and
watch them disappear.

[Richard]

[Please do not mail me a copy of your followup]

Geoff <ge...@invalid.invalid> spake the secret code
<lkf17a98aret4o41q...@4ax.com> thusly:

>On Fri, 21 Nov 2014 20:50:20 -0800 (PST), Bob Langelaan
><bobl...@gmail.com> wrote:
>
>>#include <iostream>
>>
>>int main()
>>{
>> char array[30];
>> strcpy(array, "How is this possible?");
>>}
>>
>>I thought the cstring library would need to be included.
>
>In the case of Visual Studio, it is.

Yes. Best practice is to not rely on the transitive include
dependencies from your implementation and always include the headers
for all the stuff you use.

There is a nice google project called "include what you use" that does
its best to analyze your source files and alert you when you are not
explicitly including the headers for the things you are using:
<https://code.google.com/p/include-what-you-use/>

[Geoff]

On Sat, 22 Nov 2014 18:33:42 +0000 (UTC),
legaliz...@mail.xmission.com (Richard) wrote:

>[Please do not mail me a copy of your followup]
>
>Geoff <ge...@invalid.invalid> spake the secret code
><lkf17a98aret4o41q...@4ax.com> thusly:
>
>>On Fri, 21 Nov 2014 20:50:20 -0800 (PST), Bob Langelaan
>><bobl...@gmail.com> wrote:
>>
>>>#include <iostream>
>>>
>>>int main()
>>>{
>>> char array[30];
>>> strcpy(array, "How is this possible?");
>>>}
>>>
>>>I thought the cstring library would need to be included.
>>
>>In the case of Visual Studio, it is.
>
>Yes. Best practice is to not rely on the transitive include
>dependencies from your implementation and always include the headers
>for all the stuff you use.
>
>There is a nice google project called "include what you use" that does
>its best to analyze your source files and alert you when you are not
>explicitly including the headers for the things you are using:
><https://code.google.com/p/include-what-you-use/>

FWIW, it also compiles correctly on Xcode's LLVM compiler.

[Juha Nieminen]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> - It's hard to remember to include the exact right set of headers --

I really wish they made inclusion of standard library headers
optional. In other words, the the compiler would "include" such
headers automatically when it sees that a standard function, type
or macro is referenced in the code.

(If this could potentially be a source of problems, then I would
be completely ready to accept that the automatic inclusion of
standard header files is done only when you use the std:: prefix
in the name of the function or type. This ought to be easy for
the compiler to do.)

Code would become cleaner, less prone to errors due to forgotten
#include lines, and might even compile a bit faster (because the
compiler doesn't need to parse #include lines nor, possibly, the
header files themselves).

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---