Re: [tgtl-devel] Hello and more

[Robert J. <rob...@gm...>]

Hi,

Firstly, sorry about the huge delay in replying to this; between my normal
ability to be distracted by 'good ideas', finding and starting work and my
email server falling off the internet I've not had a chance to reply.

Anyways; thanks for all the fixes and work you did. I've now merged them
back into the main branch and, along with a rewrite of the PNG setup code
(your reading loop is still the same, I just made some changes so it could
handle paletted, grey and grey + alpha images), I've done a 2.2 release.

Now, the bugs;

I can't see any problem with your plan to fix problem which files which
can't be opened for writing. Indeed if I had remembered about this bug I'd
have fixed it myself before the 2.2 release (2.2.1 at some point soon I
guess then).

I did however remember about what you wrote with regards to the iostreams
and boost usage;

The iostreams got used for two reasons; one being my attraction to new
things and the other being I thought they could solve various design issues.
They did in a way but reintroduced a number along the road, so yes for the
next major version I agree that they should be removed. In fact, I don't
know how compatible they would be with the concept of adding async file
loading in the next revision (optional; so you can still load as now but
also an interface will exist to allow async loading.. I'm still working on
the details).

As for kicking boost out completely, I'm not so convinced; while iostreams
is going to go until C++ gets fixed data sizes I'd much rather rely on
someone else doing the work for other platforms rather than myself (or
anyone else). Also, boost::shared_ptr<> is in the public interface for the
safe loading routines and while writing a smart pointer could be considered
trivial I'm not keen on reinventing that wheel; plus it just becomes another
interop problem as now the user needs to support whatever smart pointer we
come up with and potentially another, I'd much rather go with something more
standard (if TR1 was widely in use I'd consider dropping boost::shared_ptr
for the TR1 revision, at which point the question about the usefulness of
the fixed data sizes from boost alone could be called into question... in
fact, there is probably some logic to switching to TR1 for the next version
as boost supplies a lot of it, I'll have to try to remember to look into
that).

My final reasoning is that I would hope that GTL would be used in a large
project and, imo, any C++ programmer who is even vaguely serious about using
the language should have boost available, in header form if not compiled. 

So, in summary, while I'm behind shunting out iostreams boost itself stays
for now, unless you have some other convincing reasons you can throw at me?

With regards to the next major version I'll try to get some 'grand ideas'
down on paper soon and post them to the list.

-----Original Message-----
From: tgt...@li...
[mailto:tgt...@li...] On Behalf Of Markus
Henschel
Sent: 27 July 2007 21:24
To: tgt...@li...
Subject: [tgtl-devel] Hello and more

Hi there,

as you have noticed I'm through with my patches in the bug fixing 
branch. There is one "bug" left I would like to discuss first:

Bug:
Loading a texture from a file fails when the file cannot be opened for 
writing (read only file system!). While it would be easy to just change 
the io mode when opening the file my solution would be to just remove 
the whole writing and seeking stuff and just work with boost source like 
devices. I didn't see writing being used anywhere and I think I removed 
seeking from all the filters. Do you see any problems with that?


This leads me to another point. The whole device concept with 
boost::iostreams seems a little bit over engineered to me. While I think 
boost is a great thing and I advice it's usage in all bigger C++ 
projects I think for GTL the cost is bigger than it's value. I think it 
would be much easier for users of GTL not being forced to install 
additional dependencies to use it. The device interface could be 
implemented just as easy without boost::iostreams. The fixed size data 
types could be easyly moved to custom typedefs too.

So for the next major release I think it would be a good idea to kick 
out boost and simplify the device concept. Do you agree?

Have a nice weekend!

Markus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
tgtl-devel mailing list
tgt...@li...
https://lists.sourceforge.net/lists/listinfo/tgtl-devel