Opened 12 years ago

Last modified 5 years ago

#5192 reopened Feature Requests

Serialization of Boost.Filesystem path

Reported by: gast128@… Owned by: Robert Ramey
Milestone: To Be Determined Component: serialization
Version: Boost 1.45.0 Severity: Optimization
Keywords: Cc:

Description

I came across Johan Rade's post about serialization of a filesystem path (see http://lists.boost.org/Archives/boost/2008/09/142550.php).

However I couldn't spot it in the source code. Maybe a suggestion? Ofc the C4127 should be addressed then.

Note: the mail thread is also about in which library the solution should be placed. My suggestion is to put it in serialization library, with the rationale that 'path' is a more basic concept (comparable to string, vector etc.) than serialization is. It would be more natural for serialization to use the filesystem library than the other way around.

Change History (5)

comment:1 by Robert Ramey, 12 years ago

Resolution: wontfix
Status: newclosed

This is a bad idea. It would then make the serialization library dependent on the file system library. This violates the current practice and signs me up for more maintenance forever which is unsustainable. The correct solution is to add a header file to the file system library boost/filesystem/serialization/path.hpp or maybe boost/filesystem/path/serialization.hpp

Robert Ramey

comment:2 by gast128@…, 7 years ago

Pity that Robert feels this way. Should the filesystem library be dependent on Serialization then? You always have basic libraries and advanced libraries which built on the basic (primitive) types. Imho date time and filesystem are the primitive types which other libraries should use when dealing with date/time and files.

comment:3 by anonymous, 7 years ago

In large part it's about responsibility. I can't be responsible for serialization of all the boost types. If it's really important get the author of the particular library to do it. If he doesn't think it's important enough to do, I can't get excited about signing up to maintain something like this.

Traditionally, one author has been responsible for the code in one library directory. Under some circumstances this has some problems which show up in dependencies. But the only proposed solutions require that I would sign up to invest a huge amount of effort in re-organizing the library.

Of course you could always do it yourself.

comment:4 by anonymous, 5 years ago

Resolution: wontfix
Status: closedreopened

I think this needs revisiting now that boost::filesystem is going into the C++ standard.

IMO, this will soon require it to be supported by the serialization library anyway.

BTW, does anyone have an update to the original code, since boost::filesystem has been significantly updated on its way to standardization?

comment:5 by jon@…, 5 years ago

Sorry, that last update was from me...

Note: See TracTickets for help on using tickets.