OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Interoparability and optional dependencies


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Robert Osfield
Guest





PostPosted: Mon Dec 01, 2008 11:29 am    Post subject:
Interoparability and optional dependencies
Reply with quote

Hi Sukender,

On Mon, Dec 1, 2008 at 11:18 AM, Sukender <> wrote:
Quote:
Alright then. I guess adopting a kind of Path structure is not on the agenda, or is it? Smile
Thank your for answering.

Adding boost dependencies to the core, even an optional build one, is
not something I'm going to accept for inclusion into the core OSG.

Major external dependencies are only inclined into the OSG when they
are encapsulated as a plugin or its own module.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Mon Dec 01, 2008 12:02 pm    Post subject:
Interoparability and optional dependencies
Reply with quote

Hi Robert, hi JP,

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". Smile

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? Smile

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...).
- And more (See references).

References:
Boost filesystem doc: http://www.boost.org/doc/libs/1_36_0/libs/filesystem/doc/index.htm
Boost filesystem path doc: http://www.boost.org/doc/libs/1_36_0/libs/filesystem/doc/reference.html#Class-template-basic_path

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Mon, 01 Dec 2008 12:29:36 +0100, Robert Osfield <> a écrit:

Quote:
Hi Sukender,

On Mon, Dec 1, 2008 at 11:18 AM, Sukender <> wrote:
Quote:
Alright then. I guess adopting a kind of Path structure is not on the agenda, or is it? Smile
Thank your for answering.

Adding boost dependencies to the core, even an optional build one, is
not something I'm going to accept for inclusion into the core OSG.

Major external dependencies are only inclined into the OSG when they
are encapsulated as a plugin or its own module.

Robert.




------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Mon Dec 01, 2008 3:06 pm    Post subject:
Interoparability and optional dependencies
Reply with quote

Hi Sukender,

On Mon, Dec 1, 2008 at 12:02 PM, Sukender <> wrote:
Quote:
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". Smile

That's not what you suggested in your first post - you were advocating
doing a typedef to the boosts path structure...


Quote:
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? Smile

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.


------------------
Post generated by Mail2Forum
Back to top
Sukender
Guest





PostPosted: Mon Dec 01, 2008 4:21 pm    Post subject:
Interoparability and optional dependencies
Reply with quote

Hi Robert,

Quote:
Quote:
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". Smile

That's not what you suggested in your first post - you were advocating
doing a typedef to the boosts path structure...

Yes, but as you said it was better not to include, then I changed Smile

Quote:
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.


Alright. I think I'd rather leave the subject for now: it seems I'm the only interested in doing such a modification! Even if separating "path" from "string" may be useful later.
Anyway, if I don't do that, I will have more time to spend on osgAudio...
Thank you for answering.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Happy New Year to all OSG Users Chris Hanson General 0 Mon Jan 07, 2019 10:17 am View latest post
No new posts osg-users Digest, Vol 138, Issue 27 Zachary1234 General 0 Tue Jan 01, 2019 1:16 am View latest post
No new posts osg-users Digest, Vol 137, Issue 14 poweruserm@live.com.au General 0 Fri Nov 16, 2018 11:16 pm View latest post
No new posts General Users starting questions in O... A Z General 1 Mon Oct 15, 2018 3:59 am View latest post
No new posts osg-users Digest, Vol 136, Issue 8 jonasydy General 0 Wed Oct 10, 2018 12:40 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP