DLIB_ISO_CPP_ONLY is broken

[emptyVoid]

Here's what I get when trying to use dlib::shape_predictor with DLIB_ISO_CPP_ONLY defined:

In file included from /usr/local/include/dlib/threads/posix.h:4:0,
                 from /usr/local/include/dlib/threads/threads_kernel.h:13,
                 from /usr/local/include/dlib/threads.h:11,
                 from /usr/local/include/dlib/image_processing/shape_predictor.h:14,
                 from test.cpp:12:
/usr/local/include/dlib/threads/threads_kernel_2.h:7:2: error: #error "DLIB_ISO_CPP_ONLY is defined so you can't use this OS dependent code.  Turn DLIB_ISO_CPP_ONLY off if you want to use it."
 #error "DLIB_ISO_CPP_ONLY is defined so you can't use this OS dependent code.  Turn DLIB_ISO_CPP_ONLY off if you want to use it."
  ^

Please note, (at least as of 19.1) commenting out dlib::shape_predictor_trainer in dlib/image_processing/shape_predictor.h fixes the issue.

[davisking]

It's not broken. This is just what happens when you disable that part of the code. I don't know what you would expect to happen.

Although, honestly, I'm tempted to remove the DLIB_ISO_CPP_ONLY switch since I suspect mightily that no one really uses it.

[emptyVoid]

I don't know what you would expect to happen.

Wouldn't you expect it to work as outlined in the "documentation"?

This is a #define directive that you can set to cause the library to exclude all non ISO C++ code (The things in the API wrappers section and any objects that depend on those wrappers).

[davisking]

Yes. Some things depend on that stuff. Like part of the shape prediction tooling.

[emptyVoid]

Though the predictor itself doesn't depend on threads, and the trainer's declaration could be moved to a separate header (not sure why the thread part has to be OS dependent in the first place, since DLib requires a C++11 compiler why can't it use std::thread?).

[davisking]

Because a lot of dlib was written before there was C++11 support in compilers. Also, yes, many things could be split up. You can almost always split source files into smaller parts, we could make it so there are 10,000 source files instead of about 1000. But I'm not doing that.

Do you have a use case that is somehow impacted by what you are posting about?

[emptyVoid]

The use case is pretty simple: all I use from DLib is the shape predictor, and since it's implemented solely in headers I'd like to benefit from a header-only part of DLib, not having to build it for various platforms.

[davisking]

Sure. If you want to move the shape_predictor to its own header then submit it as a PR :). Do make sure you don't break any existing code though.

[emptyVoid]

Sorry, had no idea how to link PR to an issue... so here it is #599

[davisking]

No worries. Thanks for the PR :)