I think a more critical item than whether or not to use STL containers to map the translations is the issue of what DXF format to support. Autocad has more or less changed DXF formats with each release with many being totally incompatible with previous versions. Most of the Linux programs that support DXF, support it thru R14, which is quite a few years old. Newer versions have included more data items which may or may not be needed. I'm not sure of the DXF exported versions used by some other programs such as Visio, Microstation, etc. Maybe this was addressed in the detailed proposal which I haven't seen, but if not, would be a good early item to address and solicit some feedback from the Inkscape maillist.
Looking forward to seeing this project come about and will be happy to supply some examples and do some testing as it progresses.
MenTaLguY wrote:
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