[Liblas-devel] Some ideas for class organization

[Mateusz Loskot]

Howard Butler wrote:
> 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've not walked through the current implementation in details, so I'll
be back with comments in some time.

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

Hobu, what you mean as "to link into"?
Do you mean to include liblas to GDAL/OGR source tree, as json-c is?

If we'll put everything into namespaces, then we avoid clashes.

> 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 don't understand.
Could you tell more about the "except in the case of ctor/dctor" ?
Throwing an exception is the only way to signal error condition in
constructor. Throwing is forbidden from destructors.

IMO, we should decided at the very beginning about using or not using
exceptions as the further design decisions will depend on that.
Also, if we use memory allocation with malloc or new, etc.
If we use new/delete (and any other throwing entities) and we do not use
exceptions, then we need to catch inside liblas and translate to return
code.

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

I'm supportive to namespaces use.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net