removal of 'using namespace std;' in ofMain.h

[oxillo]

Hello,

I've just spent some hours to investigate the conflict between std::byte and a typedef in rpcndr.h to finally find that it was caused by this using namespace std; statement in ofMain.h.

Generally, it's a bad practice to use "using namespace std;" but removing it will break a lot of existing code.

Proposal 1

have a new include file "ofAll.h" that includes all the of include files and keep ofMain.h that is only :

#pragma once

#include "ofAll.h"

using namespace std;

All new code should then include "ofAll.h" instead of "ofMain.h".

Proposal 2

guard the "using namespace std;" directive with a #ifndef or #ifdef.

#ifndef OF_NO_STD_NAMESPACE
using namespace std;
#endif

or

#ifdef OF_BACKWARD_COMPATIBLE
using namespace std;
#endif

[ofTheo]

100% agree that we need to solve this.
I ran into the same issue a while back.

I think the questions is how do we do this in the least breaking way?

Proposal 3

Figure out the common types that might break and put them in the off:: namespace?

#ifdef OF_LEGACY_STD
namespace of{
  using string = std::string; 
  using vector = std::vector; 
}
#endif 

then instead of
using namespace std;
using namespace of;

Downside is there would be a lot of edge cases we might miss.

[oxillo]

I like the idea of keeping common types (vector, string, shared_ptr) exposed.

For C++ beginners, it leaves the namespace concept away.

Maybe a simple

using std::string;
using std::vector;

is enough ?

Still, it will break some addons

[ofTheo]

yeah, this seems like a good compromise way to go.
the default could be something like the following:

using std::string;
using std::vector;
using std::map;
using std::cout;
using std::endl;
using std::shared_ptr;
using std::weak_ptr;
using std::make_shared;

(The last three are in a lot of the addons I use.)

With an #ifdef option to do using namespace std; or nothing at all in ofConstants.h

[dimitre]

good

• cout, endl, min, max, unsorted_map, list and some more

[oxillo]

I've tried to compile all examples in MSYS2 without "using namespace std;".

I had to add the following to succeed :

using std::string;
using std::stringstream;
using std::endl;
using std::vector;
using std::max;
using std::make_shared;
using std::deque;
using std::cout;
using std::swap;
using std::pair;
using std::map;
using std::shared_ptr;
using std::to_string;

// I would not include the following statements in official ofMain.h but rather upgrade the examples..
using std::unique_lock;
using std::mutex;
#include <regex>
using std::regex;
using std::smatch;
//using std::regex_constants;
using std::match_results;
using std::sregex_iterator;

I haven't managed to compile the regularExpressionExample due to the use of regex_constants::icase in some statements.

[ofTheo]

@oxillo thanks!!

Let's do a PR for this.

Can we add one more to the above list?
using std::weak_ptr;

[dimitre]

Proposal 4

we remove from ofMain.h and add in ofBaseApp.h

[dimitre]

yes youre right.

[ofTheo]

doh - yeah I had the same idea, include it in ofApp.h and then realized it wouldn't work for any other addons.
there will def be some pain with this transition, just a matter of how much :)

[dimitre]

Yes. maybe we can break this later if you prefer, but once we have a release out it is ok to break
we could have a good index of up to date addons, maybe a github badge (combatible with 0.12.x)
and we can help submitting PRs. After ofxSyphon updates everything else will be easier if mantainers are around

[oxillo]

I'm not in favor in moving the statement to another include file. It is just moving/hiding the problem. It will come back one day!

[dimitre]

Yes but this option would at least move any problem inside OF core (there is none), so the CI tests can catch any inconsistency, we can always use explicit std::byte for ex.

[ofTheo]

Okay so for now we have a fix which should in the least fix the std::byte conflict @oxillo was seeing on msys2.
https://github.com/openframeworks/openFrameworks/pull/7636/files

Thanks @oxillo @dimitre @artificiel for help on this!