> Given that this is a Qt project I think we should try to adapt Qt quidelines.
>
> Please use QString instead of std::string and one of Qt's shared pointer
> mechanisms.
Michael,
The GetName and GetPath methods are defined in xpathselect. We cannot use QStrings here since xpathselect does not (and should not) rely on Qt. Similarly, we use std::shared_ptr because that's what the interface defines.
> In fact, I'm not a big fan of shared pointers at all as in most
> cases they lead to bad design choices. So if not really necessary, try
> avoiding those.
I'm not sure what you mean - this is a classic case where shared_ptrs are necessary. Qt has it's fancy copy-on-write semantics which make passing objects around by value very cheap, but other toolkits don't have that. Since we're dealing with an interface that has to be toolkit-agnostic, we can't start using Qt's magic.
> Given that this is a Qt project I think we should try to adapt Qt quidelines.
>
> Please use QString instead of std::string and one of Qt's shared pointer
> mechanisms.
Michael,
The GetName and GetPath methods are defined in xpathselect. We cannot use QStrings here since xpathselect does not (and should not) rely on Qt. Similarly, we use std::shared_ptr because that's what the interface defines.
> In fact, I'm not a big fan of shared pointers at all as in most
> cases they lead to bad design choices. So if not really necessary, try
> avoiding those.
I'm not sure what you mean - this is a classic case where shared_ptrs are necessary. Qt has it's fancy copy-on-write semantics which make passing objects around by value very cheap, but other toolkits don't have that. Since we're dealing with an interface that has to be toolkit-agnostic, we can't start using Qt's magic.