[Qt-interest] anyone know why QDir::mkpath() isn't static?

Constantin Makshin cmakshin at gmail.com
Tue Apr 12 19:18:05 CEST 2011


What about static makePath(const QString& path) function (may be also removePath(const QString& path) for "symmetry", as a static version of rmpath())? Then:

bool QDir::mkpath (const QString& dirPath) const
{
    return makePath(QFileInfo(dirPath).isAbsolute() ? dirPath : absoluteFilePath(dirPath));
}

bool QDir::rmpath (const QString& dirPath) const
{
    return removePath(QFileInfo(dirPath).isAbsolute() ? dirPath : absoluteFilePath(dirPath));
}

In that case you'll both keep API compatibility and solve the problem/inconvenience of using mkpath() and rmpath() with absolute paths.

On Tuesday 12 April 2011 20:26:31 Thiago Macieira wrote:
> Em terça-feira, 12 de abril de 2011, às 09:19:38, Scott Aron Bloom escreveu:
> > I have found there are a number of little idiosyncrasies in the QFile,
> > QFileInfo, and QDir code that can be confusing and worst case create a
> > bug..  You just get used to them
> > 
> > With mkpath... I would prefer if there was a static as well as a non-static
> > member...  I wouldn't even mind if the QDir threw an assert on the static
> > member if the path sent in was relative.
> 
> For those interested, we're still having a discussion on the ugliness and 
> wrongs of QFile, QDir and QFileInfo in the #qt-labs channel. There's a lot 
> that could be done better and the developers agree.
> 
> The question is: when the time comes for when a source-incompatible is 
> permitted, what is better, to keep compatibility with thousands of existing 
> programs or to make a new, better but incompatible API?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110412/c0fa9865/attachment.bin 


More information about the Qt-interest-old mailing list