[vtk-developers] Request for a gentler tone in commit message verbiage...

David Lonie david.lonie at kitware.com
Thu Apr 30 08:02:10 EDT 2015


On Wed, Apr 29, 2015 at 4:04 PM, Robert Maynard <robert.maynard at kitware.com>
wrote:

> "
> Following a breaking change between the C++98/03 and C++11 standards,
> using explicit template arguments to call make_pair()—as in
> make_pair<int, int>(x, y)—typically does not compile in Visual C++ in
> Visual Studio 2012. The solution is to always call make_pair() without
> explicit template arguments—as in make_pair(x, y). Providing explicit
> template arguments defeats the purpose of the function. If you require
> precise control over the resulting type, use pair instead
> of make_pair—as in pair<short, short>(int1, int2).
>

Thanks for finding that. That explains why the std::make_pair<double,
X*>(double, X*) call failed. Strange, but I see they're justifying it.

Another breaking change between the C++98/03 and C++11 standards: When
> A is implicitly convertible to B and B is implicitly convertible to C,
> but A is not implicitly convertible to C, C++98/03 and Visual C++ 2010
> permitted pair<A, X> to be converted (implicitly or explicitly) to
> pair<C, X>. (The other type, X, is not of interest here, and this is
> not specific to the first type in the pair.) Because C++11 and Visual
> C++ in Visual Studio 2012 detect that A is not implicitly convertible
> to C, they remove the pair conversion from overload resolution. This
> is a positive change for many scenarios. For example, overloading
> func(const pair<int, int>&) and func(const pair<string, string>&), and
> calling func() with pair<const char *, const char *> will compile with
> this change. However, this change breaks code that relied on
> aggressive pair conversions. Such code can typically be fixed by
> performing one part of the conversion explicitly—for example, by
> passing make_pair(static_cast<B>(a), x) to a function that expects
> pair<C, X>.
> "
>

I'm still missing something here. One on of my attempts to get this to
compile simultaneously across all of our windows dashboards, this call was
failing:

std::pair<double, X*>(someDouble, NULL);

As I understand it, if NULL is defined as either (int)0, (void*)0, or
nullptr (depending on implementation/standard), all of those expressions
are implicitly convertible to X* without going through an intermediate,
right? To fix it, I had to explicitly cast the NULL to X* for compilation
to succeed. What am I missing here?


> The reason that we haven't seen this with other compilers is either
> they haven't enabled C++11 (with c++11 standard library) or they
> compile options are lax and allow this behavior.


My guess is the latter. Backward compatibility is a nice thing to have in a
compiler ;)

On Wed, Apr 29, 2015 at 5:52 PM, David Cole <DLRdave at aol.com> wrote:

> Thanks for the discussion.
>
> I did try what you said, and I do reproduce the error you saw, ... but
> I still say it's not a general problem with double and make_pair.
>

Correct. It'll happen with any explicit type specification on make_pair.


> make_pair ought to be use-able without specifying types. If you have
> to specify the type of a pair, then you should just use pair<type1,
> type2> directly as you've ended up with. The extra cast you needed for
> VS2010 is the real shame.
>

Agreed. I only added the explicit template arguments as a hint that the
NULL should be cast to X*. You can imagine my surprise when that failed
because it didn't like the 'double'!

I will propose a patch that rephrases the in-code comments about this
> if nobody else has the time to do so.
>

I can see about making the comment I introduced more palatable (I thought
you were referring to the commit message earlier...).

BTW, if my comments were enough of a turn-off to spark this thread, you may
want to grep the code for things like "stupid", "dumb", "moron", "idiot",
"s***" and "f***". These all appear in our source code (albeit the stronger
language is in contributed modules) and are significantly stronger than any
language introduced by my patch. Some are even directed at poor ol'
Windows. Might want to check those out and see if you want to air any
further grievances ;)

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150430/a1613270/attachment.html>


More information about the vtk-developers mailing list