Hi Sukender,
On Mon, Dec 1, 2008 at 12:02 PM, Sukender <[EMAIL PROTECTED]> wrote:
> Well, I knew the fact that boost will not be included in OSG... I was just
> talking about "a" Path structure, not "the boost's path structure". :)
That's not what you suggested in your first post - you were advocating
doing a typedef to the boosts path structure...
> I know that's *really* not important comparing to other features that are
> currently in dev, but I'm just pointing out the fact that it could be useful
> to some people. Question is: are they many? :)
>
> This Path class would:
> - Have a "/" and "/=" operators that acts as the "/" in Unix paths (Ex:
> projectFullPath / dataPath / "Textures" / "Model1/Something.jpg").
> - Handle canonical paths (Ex: transform "a/b/../c" to an unique "a/c").
> - Have to_native_file() and to_native_dir() methods to convert the Path
> structure to a platform dependent string ("C:\Dir1\File1.jpg" under Windows,
> "/Dir1/File1.jpg under linux and so on...).
> - Be much safer than using strings.
> - Be used for some filesystem related functions (create all directories of a
> path, test file/dir existence, directory iterators...).
The osgDB library already has a range of functions for managing file
paths. You could possible wrap these up under a class, but we'd need
to migrate a lot of code that current uses std::string's quite happily
to using its replacement - for instance the plugins would all have to
be converted. This is doable but it's not a trivial amount of work.
The high level functions in osgDB/ReadFile and osgDB/WriteFile could
have both the old std::string and a new osgDB::Path interfaces so is
less of an issue. One would have to have a clear value add for
undertaking this work.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
