auto initalising (c++ does this right?),

C++ implicitly calls the default constructor for allmembers that are not initialized in the containing class's constructorinitializer list. Note that only *objects* are default initialized this way,atomic types are not (int, pointers, ...). They contain garbage until youassign them a value.

class Member { public: Member(int i) {} };

class Container { public: Container() {} private: Member member; };

Thus, this will not compile. Instead you'll have to writethe constructor this way: Container() : member(42) {}

I'm not sure whether you should add a parameterlessconstructor to Inkscape::URI. I mean, is an empty uri valid? Does it make senseto be able to create an uri this way, or is it's "path" necessary forthe object to have any sense at all?

Regards, Markus

-----Ursprüngliche Nachricht----- Von: Martin Owens [mailto:doctormo@...400...] Gesendet: Mittwoch, 26. Februar 2014 13:32 An: Krzysztof Kosiński Cc: Markus Engel; inkscape-devel Betreff: Re: [Inkscape-devel] URI

Digging into the job, I've ripped away dom/* and most ofthe code works.

I've ported color-profile.cpp which was using thedom::URI to Inkscape::URI and the same replacement can be done to odfextension.

A missing piece was zipfile support.

src/dom/util/ziptool.cpp/.h was a self-contained zipimplementation so I've moved that to src/util/ since it has no equivalentfunctionality.

That worked well. I've hit a small problem with Inkscape::URInot having a constructor with no-arguments which I think can be solved byadding an OdfOutput constructor which initalises the URI instead of it autoinitalising (c++ does this right?), but this seems odd to me as if the Odfshouldn't initalise the URI until it needs it.

Thoughts?

Best Regards, Martin Owens