[Liblas-devel] Some ideas for class organization

[Howard Butler]

Phil,

I really like the idea of collecting the file operations into a single  
class and using it for both the read and write operations.  In my  
opinion, the current read/write code expects the caller to do too much  
direct file manipulation, and it would be nice to encapsulate this a  
bit more.

I think some typedef'd names for the basic types like char, long long,  
etc might be in order to provide us some portability shielding.  You,  
me, and Mateusz are all quite familiar with CPL <http://trac.osgeo.org/gdal/browser/trunk/gdal/port 
 >, but I don't think we'd need to go quite so far as that.  Also, I  
am expecting to link libLAS into GDAL/OGR, so we must take some care  
not to clash symbols, etc.

With regard to exceptions, I'm generally supportive except in the case  
of constructor/destructors, which can cause hard problems to deal with  
sometimes.  Simple return values are as natural to me as exceptions,  
and I can be swayed either way.

I had asked Martin earlier about what he thought about namespaces.   
Did you have any ideas?

Also, I should introduce you :)  Phil was a Google Summer of Code  
student with the GDAL <http://www.gdal.org> project, and he's been an  
active contributor and whiz at all of the obscure satellite data  
formats.  So sequential, big binary data like LAS is right up his  
alley.  Welcome aboard, and thanks for pitching in.

Howard


On Dec 16, 2007, at 3:22 PM, Philippe Vachon wrote:

> Hi everyone,
>
> I threw together a quick trac page on how I might go about structuring
> libLAS, from the C++ perspective.
>
> See: http://liblas.org/wiki/ClassStructure
>
> I would be interested in any ideas/feedback/limitation you see. I
> haven't really thought out the writing side of things, but I think  
> that
> there will need to be an interface for the LASFile class to allow the
> various parameters of interest (offset, scaling factors,  
> georeferencing
> information) be set, then written out when some sort of flush() method
> is called (and/or when the class' destructor is called, of course).
>
> The other thing I wasn't sure about was exception handling. I would  
> like
> to go with structured exception handling, exposing a generic exception
> class perhaps to client applications so we can just throw that and let
> the application using the library catch it. Anyways, points to  
> ponder, I
> guess?
>
> Cheers,
> Phil
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at mail.hobu.net
> http://mail.hobu.net/mailman/listinfo/liblas-devel
>