Std explicit

[tgfrerer]

use explicit std, in header files, using namespace std in .cpp files. This is necessary for latest openFrameworks, which (finally) has more stricter handling of namespaces.

• also inlines glsl for engineVk

[tgfrerer]

i've changed this here, as the base engine should be agnostic of its final rendering backend - and GLuint inserts a dependency to OpenGL.

[jvcleave]

What's the benefit of explicit std?

[tgfrerer]

It looks like openFrameworks > 0.10 will be a bit more picky about namespaces.

... it allows us to keep the global namespace a bit cleaner - oF before 0.10, inofConstants.h, did import the full std namespace into the global namespace, which is considered bad practice.

The strongest itch comes from having this using directive in a header file - and because headers include each other, and other headers, you could never be sure about the state of the global namespace if you included an oF header...

Note that it's perfectly ok to do using namespace std in a .cpp file, because this using directive is only valid for the current "compilation unit", i.e. the current .cpp file, and does not "infect" any other files.

The namespace drive is part of a more general drive of disentangling the oF headers, and streamlining dependencies, all yak shaving operations to ultimately reduce complexity and compile times :)

[jvcleave]

I'm super skeptical about modern cpp practices and the promises it brings. I tend to agree with this comment

I guess it's best to fall in line with what our dependency is doing. You seem to be working on this more than I am so I've invited you as a collaborator - if you want just join and merge whenever you see fit

[tgfrerer]

Oh, it's not a modern cpp practice - using namespace xy in header files has been discouraged for over 17 years now ;)

The way i read the comment you linked, it seems to approve of not using using namespace std in header files.

I believe openFrameworks had the line using namespace std in ofConstants.h because initially, it made things easier, and for folks coming from other languages, which don't use namespaces, the code looked friendlier.

But oF has grown, and there are many libraries that somehow interact with it, and the more oF makes sure to keep the global namespace tidy, the less unintended side-effects we might run into in the future. Debugging header-dependency- and namespace collisions is really tough...

[jvcleave]

I wish 17 years seemed like a long time ago.

It's entirely possible I don't fully understand the issue and will look at some of the links. (I've only had a conflict once with ctime.h which clashed with boost).

[valillon]

Hi guys,

I tried to compile ofxImGui against the current OF master branch and experienced those namespace errors that weren't in OF 0.9.8.

Not sure it's due to pre-release or simply because as @tgfrerer mentioned OF has embraced that safer practice. In any case, adding std:: make it compile cleanly.