Boost logo

Boost :

Subject: Re: [boost] [filesystem.v3] possible bug in replace_extension
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-02-10 15:43:10

Frédéric Bron wrote:
> > replace_extension seems to have the wrong behaviour if the
> > provided new extension does not start with a dot.
> I found that this has already been registered a long time
> ago:
> (at the time of
> 1.45.0).
> A patch has even been proposed. Could it be fixed for 1.49.0?

I ran into this today. The issue is that replace_extension() extracts the extension() from its argument and uses that as the new extension. Thus, if there's no dot in the argument, it has no extension. That's reasonable for a path argument. Indeed, I think the patch is wrong.

The confusion comes when the argument is a string. An implicit path is constructed from the string and, since it has no dot, there's no extension to replace. I think there should be an overload that takes a string. Then, the whole argument is used as the extension, if it contains no dot, and the tail is used if there is. Reasonable?

Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP


IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Boost list run by bdawes at, gregod at, cpdaniel at, john at