On Sat, 2005-07-09 at 15:04 +0400, Alexandre Prokoudine wrote:
On 7/9/05, Matt Squires <matthew.squires@...854...> wrote:
Here is where I am on the dxf importing so far. A few weeks ago I checked the dxf libraries that are already out there (dime, Qcad (dxflib), blender were specifically mentioned in the proposal) and found all are GPL'd. After a discussion with Jon about licensing I became more aware of the possibility of releasing under several licenses. So I decided to write a dxf importing code using STL containers to hold the various levels of data. I hope that it will be something others can reuse.
So you will write yor own library from scratch?
Ok, this worries me a bit. STL is nice as an implementation tool, but why would using it be a feature? Are STL containers to be a visible part of the proposed library's external interface?
Often that's not a good use of STL... especially as it tends to force users of the library away from the prefered STL iterator model and can get very ugly with inlining. It's generally better to provide your own types implementing an STL container/iterator interface on top of a straightfoward base API.
Similarly, when you're using STL containers as part of your internal representation, it's best to keep them encapsulated within objects that provide more domain-specific interfaces. Otherwise when you e.g. decide that your std::list really needs to be a std::vector with a parallel index beside it, you end up having to rewrite all of that object's clients. Typedefs help, but no two containers are 100% interchangable.
Also, using a GPL-licensed library isn't a problem for us. I thought the main goal of the SoC proposal was to add DXF support to Inkscape, not to create a DXF library?
-mental