[Debian-med-packaging] Bug#811866: More C++ help needed (Was: Bug#811866: fixed in hyphy 2.2.6+dfsg-4)
Manuel A. Fernandez Montecelo
manuel.montezelo at gmail.com
Sun Aug 14 20:39:02 UTC 2016
2016-08-14 20:53 Andreas Tille:
>Hi again,
>
>On Sat, Aug 13, 2016 at 09:11:52PM +0200, Andreas Tille wrote:
>> _HYColor chartColors [HY_CHART_COLOR_COUNT] = {
>> {255*.94, 255*.12, 255*.11 },//(Red)
>> {255*.41, 255*.46, 255*.91 },//(Evening Blue)
>> {255 , 255*.91, 255*.34 },//(Banana)
>> {255*.18, 255*.55, 255*.13 },//(Clover)
>> {255*.55, 255*.38, 255*.21 },//(Dirt)
>> {255*.42, 255*.09, 255*.69 },//(Royal Violet)
>> {255*.09, 255*.29, 255*.51 },//(Sea Blue)
>> {255 , 255*.57, 255*.09 },//(Orange)
>> {255*.67, 255*.67, 255*.67 },//(Concrete)
>> {255*.85, 255*.27, 255*.42 } //(Carnation)
>> };
>>
>> the narrowing conversion in this case is absolutely intended here
>> obviously. Is there any more elegant solution for these case than
>> something like
>>
>> s:\.\([0-9][0-9]\):\1/100:g
>
>Since there was no answer to this question I just did this since it
>seems like a working solution.
Disclaimer: I haven't read the code around to know if it's sensible or
if it needs to be casted to another type (char, unsigned char, uint8_t,
etc).
Disclaimer #2: I haven't read the previous e-mail either and I deleted
it know, so I don't know more of the context other than what you say
here.
That said:
You can force/acknowledge the narrowing, something like
"static_cast<chartColors>(255*.94)" (of course, it's very
ugly/unreadable to have them like that, but...).
Also, if you substitute e.g. "255*.94" for "255*94/100", make sure that
you use parentheses as in "(255*94)/100", otherwise you can end up with
"255*(94/100) -> 255*0 -> 0" for all such values (I cannot recall the
rules now, but I think that / takes precedence over *).
>Unfortunately there are further build
>issues I can't deal with:
>
>...
>/usr/bin/c++ -DGDK_PIXBUF_ENABLE_BACKEND -D_HYPHY_LIBDIRECTORY_=\"/usr/lib/hyphy\" -D_SLKP_LFENGINE_REWRITE_ -D_SLKP_USE_SSE_INTRINSICS -D__AFYP_REWRITE_BGM__ -D__HYPHYCURL__ -D__HYPHY_64__ -D__HYPHY_GTK__ -D__UNIX__ -I/build/hyphy-2.2.6+dfsg/src/core/include -I/build/hyphy-2.2.6+dfsg/src/lib/Link -I/build/hyphy-2.2.6+dfsg/src/new/include -I/build/hyphy-2.2.6+dfsg/src/gui/include -I/build/hyphy-2.2.6+dfsg/src/gui/include/Components -I/build/hyphy-2.2.6+dfsg/src/gui/include/WindowClasses -I/build/hyphy-2.2.6+dfsg/contrib/gtest-1.7.0/include -I/build/hyphy-2.2.6+dfsg/tests/gtests -I/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent -I/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent/include -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -I/usr/include/gtk-2.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/build/hyphy-2.2.6+dfsg/src/gui/gtk/include -I/build/hyphy-2.2.6+dfsg/src/gui/gtk/include/Components -I/Developer/Headers/FlatCarbon -g -O2 -fdebug-prefix-map=/build/hyphy-2.2.6+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fpermissive -msse3 -o CMakeFiles/HYPHYGTK.dir/src/gui/HYChartWindow.cpp.o -c /build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp
>/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp: In function 'bool ReadDataFromFile(_String, char, _Matrix&, _List&)':
>/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:3010:54: error: no matching function for call to '_Formula::_Formula(_String&, NULL, bool)'
> _Formula f (*thisString,nil,false);
> ^
>In file included from /build/hyphy-2.2.6+dfsg/src/core/include/parser.h:54:0,
> from /build/hyphy-2.2.6+dfsg/src/core/include/batchlan.h:44,
> from /build/hyphy-2.2.6+dfsg/src/gui/include/Components/HYTableComponent.h:13,
> from /build/hyphy-2.2.6+dfsg/src/gui/include/WindowClasses/HYChartWindow.h:11,
> from /build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:54:
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:88:5: note: candidate: _Formula::_Formula(_PMathObj, bool)
> _Formula (_PMathObj, bool isAVar = false);
> ^~~~~~~~
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:88:5: note: candidate expects 2 arguments, 3 provided
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:87:5: note: candidate: _Formula::_Formula(_String&, _VariableContainer*, _String*)
> _Formula (_String&,_VariableContainer* theParent=nil,_String* errorString = nil);
> ^~~~~~~~
Again, disclaimer that this e-mail is written without looking at
surrounding the code, but...
To me, this is the only variant of the function that "makes sense" in
the context or is kind of compatible. Probably in previous versions of
the compiler the "false" was silently converted to 0 and so was
interpreted as a NULL pointer.
So I'd change:
_Formula f (*thisString,nil,false);
to:
_Formula f (*thisString,nil,nil);
(or the more standard "nullptr", but since they already use 'nil', which
I guess that it's an alias... I don't want to break their style).
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:87:5: note: no known conversion for argument 3 from 'bool' to '_String*'
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:86:5: note: candidate: _Formula::_Formula()
> _Formula (void);
> ^~~~~~~~
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:86:5: note: candidate expects 0 arguments, 3 provided
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:79:9: note: candidate: _Formula::_Formula(const _Formula&)
> class _Formula // a computational formula
> ^~~~~~~~
>/build/hyphy-2.2.6+dfsg/src/core/include/formula.h:79:9: note: candidate expects 1 argument, 3 provided
>/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp: In member function 'virtual void _HYDistributionChartWindow::AddVariable(_String*)':
>/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:4530:45: error: no matching function for call to '_Formula::_Formula(_String&, NULL, bool)'
These don't seem a good candidate in this case.
In any event, it's probably upstream who should take a look at this,
because changing the code without knowing exactly what it does is never
a good idea :-)
Hope that helps!
--
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
More information about the Debian-med-packaging
mailing list