Why construct dummy dylib's?

[Eyal Rozenberg]

The dylib class has a default ctor. Why? What is the use of a "dummy", empty, dylib? Should you not follow the RAII paradigm, and let construct correspond to opening a library, and destruction to closing it?

[Martin Olivier]

You are right, i need to remove the default ctor and the close function.
In your opinion, should i keep the open function for "reusable" purposes or get rid of it ?

[Eyal Rozenberg]

In your opinion, should i keep the open function for "reusable" purposes or get rid of it ?

What's useful about an existing instance, that remains useful after you've closed one library in order to open another?

[Martin Olivier]

I have originaly made dylib following std::ofstream syntax (default ctor, open, close, ...).
But i saw the main reason it was designed like that (not RAII compliant) is because the close process may fail, witch is not the case with dylib

What's useful about an existing instance, that remains useful after you've closed one library in order to open another?

Perhaps the user wants to open a lib, check if an existing symbol is here and if its not the case open another lib within the same instance

[Eyal Rozenberg]

Remember that streams are a very very old C++ facility, and these days would likely have been designed somewhat differently.

Perhaps the user wants to open a lib, check if an existing symbol is here and if its not the case open another lib within the same instance

Why would the user want to use the same instance? How does that help them?

auto my_lib = dylib::open("foo");
if (not my_lib.contains("my_symbol")) {
    my_lib = dylob::open("bar");
}

[Martin Olivier]

Done in #34