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

C++ implicitly calls the default constructor for all members that are not initialized in the containing class's constructor initializer list. Note that only *objects* are default initialized this way, atomic types are not (int, pointers, ...). They contain garbage until you assign 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 write the constructor this way:

Container() : member(42) {}

 

I'm not sure whether you should add a parameterless constructor to Inkscape::URI. I mean, is an empty uri valid? Does it make sense to be able to create an uri this way, or is it's "path" necessary for the 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 of the code works.

 

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

 

A missing piece was zipfile support.

 

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

 

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

 

Thoughts?

 

Best Regards, Martin Owens