conflicting byte definitions

[oxillo]

When compiling examples from ofxIO, compilation errors appear :

C:/N/msys64/mingw64/include/rpcndr.h:64:11: error: reference to 'byte' is ambiguous
   64 |   typedef byte cs_byte;
      |           ^~~~
In file included from C:/N/msys64/mingw64/include/c++/13.2.0/bits/memory_resource.h:38,
                 from C:/N/msys64/mingw64/include/c++/13.2.0/string:58,
                 from C:/N/openframeworks/openFrameworks/libs/openFrameworks/utils/ofConstants.h:13,
                 from C:/N/openframeworks/openFrameworks/libs/openFrameworks/ofMain.h:6,
                 from C:/N/openframeworks/openFrameworks/addons/ofxIO/examples/json/example_json_utils/src/ofApp.h:11:
C:/N/msys64/mingw64/include/c++/13.2.0/cstddef:69:14: note: candidates are: 'enum class std::byte'
   69 |   enum class byte : unsigned char {};
      |              ^~~~
C:/N/msys64/mingw64/include/rpcndr.h:63:25: note:                 'typedef unsigned char byte'
   63 |   typedef unsigned char byte;

This is due to the using namespace std; in ofMain.h.
Removing the statement solves the problem.

temporary solution

replace "ofMain.h" by all needed include files

long term solution

To be discussed as just removing it can break existing codebase !

[c-mendoza]

I'm going to second this, because it is a serious problem now that OF is using C++17 (this is why the issue presents itself, because C++17 has std::byte).

Removing using namespace std; from ofMain.h would indeed be a breaking change for lots of code, including some OF library code, but so is leaving it for several addons that are important to the community (ofxSpout is affected by this as well, for example). I get why using namespace std was used at the global namespace level when OF was initially designed (it would have made C++ a lot less confusing to use for people that we coming from Processing) but it has always been thought of as bad practice, and now we are seeing why. I think that we should rip the bandage and remove it from ofMain, but maybe there can be some #ifdef sugar that we can use to ameliorate the side effects.

[artificiel]

the decision to remove it was made 2013-15 in #2581. most of the work was done in #7005 making OF itself not reliant on it (and I've just PR'd #7635 which addresses a batch of main.cpp for examples and tests).

there is no good reason to carry this forward. the IDE's should provide clear enough guidance, ex Xcode:

for the benefit of people having user-friendly string name; int their old ofApp.h (and documentation/tutorials) using std::string; using std::vector; could replace using namespace std and will cover ~99% of use cases. that could be a temporary measure until most tutorials/docs such as https://openframeworks.cc/learning/08_other/readfiletostringvector/ are updated.

in the spirit of velocity there's here's an easy PR to pull: #7636