Why do I need the second argument? - c++

I have a method
class FooInterface {
bool put(uint8_t* array, unsigned array_length);
}
The test needs to verify that array of {1, 2, 3, 4, 5}, which has 5 elements is being passed to the put In My TEST_F(), I have the following code.
uint8_t arr[5] = {1, 2, 3, 4, 5}; // Values for 'array' the out parameter
MockFoo foo;
FooInterface* fooI = &foo;
EXPECT_CALL(foo, put(_, 5))
.With(Args<0,1>(ElementsAreArray(arr, 5)));
This seems to work, but it is driving me crazy because, it seems like instead of Args<0,1>, I should have Args<0> since I am matching array for the first parameter and the array size is set to 5. Changing to:
EXPECT_CALL(BFO, put(_, 5))
.With(Args<0>(ElementsAreArray(arr, 5))); // Here is 'Args<0>'
Produces these errors:
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-matchers.h:3114:34: error: no type named 'value_type' in 'std::tr1::tuple<const unsigned char *>'
typedef typename StlContainer::value_type Element;
~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-matchers.h:3532:28: note: in instantiation of template class 'testing::internal::ElementsAreMatcherImpl<const std::tr1::tuple<const unsigned char *> &>' requested here
return MakeMatcher(new ElementsAreMatcherImpl<Container>(
^
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-matchers.h:555:12: note: in instantiation of function template specialization 'testing::internal::ElementsAreArrayMatcher<unsigned char>::operator Matcher<const std::tr1::tuple<const unsigned char *> &>' requested here
return polymorphic_matcher_or_value;
^
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-matchers.h:531:12: note: in instantiation of member function 'testing::internal::MatcherCastImpl<const std::tr1::tuple<const unsigned char *> &, testing::internal::ElementsAreArrayMatcher<unsigned char> >::CastImpl' requested here
return CastImpl(
^
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-matchers.h:628:45: note: in instantiation of member function 'testing::internal::MatcherCastImpl<const std::tr1::tuple<const unsigned char *> &, testing::internal::ElementsAreArrayMatcher<unsigned char> >::Cast' requested here
return internal::MatcherCastImpl<T, M>::Cast(polymorphic_matcher_or_value);
^
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-matchers.h:666:34: note: in instantiation of function template specialization 'testing::SafeMatcherCastImpl<const std::tr1::tuple<const unsigned char *> &>::Cast<testing::internal::ElementsAreArrayMatcher<unsigned char> >' requested here
return SafeMatcherCastImpl<T>::Cast(polymorphic_matcher);
^
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-generated-matchers.h:221:24: note: in instantiation of function template specialization 'testing::SafeMatcherCast<const std::tr1::tuple<const unsigned char *> &, testing::internal::ElementsAreArrayMatcher<unsigned char> >' requested here
: inner_matcher_(SafeMatcherCast<const SelectedArgs&>(inner_matcher)) {}
^
/home/sporty/ws-ccs/googletest/googlemock/include/gmock/gmock-generated-matchers.h:288:28: note: in instantiation of function template specialization 'testing::internal::ArgsMatcherImpl<const std::tr1::tuple<const unsigned char *, unsigned int> &, 0, -1, -1, -1, -1, -1, -1, -1, -1, -1>::ArgsMatcherImpl<testing::internal::ElementsAreArrayMatcher<unsigned char> >'
return MakeMatcher(new ArgsMatcherImpl<ArgsTuple, k0, k1, k2, k3, k4, k5,
^
/home/sporty/ws-ccs/hw_1_5/miwt-os/coap/unittest/cbor_encoder_test.cpp:176:15: note: in instantiation of function template specialization 'testing::internal::ArgsMatcher<testing::internal::ElementsAreArrayMatcher<unsigned char>, 0, -1, -1, -1, -1, -1, -1, -1, -1, -1>::operator Matcher<const std::tr1::tuple<const unsigned char *, unsigned int> &>' requested here
.With(Args<0>(ElementsAreArray(arr, 5)));
^

A pointer is not an array; it is simply an address to a spot in memory. The system has zero way of knowing how long the memory you reserved for the array is. The second argument is specifically for that purpose. You know when you create it how long it is so you have to pass that information along.
However, unless you are forbidden to do so, I would recommend taking the time to learn how to use templates to handle your arrays and array type structures. The std::array is very nice and has all kinds of bells and whistles you can use. Best of all it handles all of the hassle that goes with maintaining your array.

Related

assert() leads to maybe-uninitialized gcc warning

The following code compiles fine, with no warnings/errors:
#include <bitset>
#include <Eigen/Core>
using Array = Eigen::Array<float, -1, 1, 0, 3, 1>;
struct Tree {
Array array;
std::bitset<8> bitset;
};
auto func(Tree* tree) {
int c = tree->array.rows();
int d = tree->bitset.count();
//assert(c==d);
Array e(c);
for (int k = 0; k < d; ++k) e(k) = k;
return e.sum() / (e + 1);
}
int main() {
Tree tree;
func(&tree);
return 0;
}
Compilation cmd:
g++ -O3 -Wall -I anaconda3/envs/dev/include/eigen3/ test.cpp
However, when I uncomment the assert(), I get a maybe-uninitialized warning:
In file included from anaconda3/envs/dev/include/eigen3/Eigen/Core:253,
from test.cpp:2:
In member function ‘Eigen::internal::scalar_sum_op<LhsScalar, RhsScalar>::result_type Eigen::internal::scalar_sum_op<LhsScalar, RhsScalar>::operator()(const LhsScalar&, const RhsScalar&) const [with LhsScalar = float; RhsScalar = float]’,
inlined from ‘static Eigen::internal::redux_impl<Func, Evaluator, 3, 0>::Scalar Eigen::internal::redux_impl<Func, Evaluator, 3, 0>::run(const Evaluator&, const Func&, const XprType&) [with XprType = Eigen::Array<float, -1, 1, 0, 3, 1>; Func = Eigen::internal::scalar_sum_op<float, float>; Evaluator = Eigen::internal::redux_evaluator<Eigen::Array<float, -1, 1, 0, 3, 1> >]’ at anaconda3/envs/dev/include/eigen3/Eigen/src/Core/Redux.h:278:19,
inlined from ‘typename Eigen::internal::traits<T>::Scalar Eigen::DenseBase<Derived>::redux(const Func&) const [with BinaryOp = Eigen::internal::scalar_sum_op<float, float>; Derived = Eigen::Array<float, -1, 1, 0, 3, 1>]’ at anaconda3/envs/dev/include/eigen3/Eigen/src/Core/Redux.h:418:56,
inlined from ‘typename Eigen::internal::traits<T>::Scalar Eigen::DenseBase<Derived>::sum() const [with Derived = Eigen::Array<float, -1, 1, 0, 3, 1>]’ at anaconda3/envs/dev/include/eigen3/Eigen/src/Core/Redux.h:463:25,
inlined from ‘auto func(Tree*)’ at test.cpp:17:15:
anaconda3/envs/dev/include/eigen3/Eigen/src/Core/functors/BinaryFunctors.h:42:122: warning: ‘((const float*)((char*)&e + offsetof(Eigen::Array, Eigen::Array<float, -1, 1, 0, 3, 1>::<unnamed>.Eigen::PlainObjectBase<Eigen::Array<float, -1, 1, 0, 3, 1> >::m_storage)))[3]’ may be used uninitialized [-Wmaybe-uninitialized]
42 | EIGEN_DEVICE_FUNC EIGEN_STRONG_INLINE result_type operator() (const LhsScalar& a, const RhsScalar& b) const { return a + b; }
| ~~^~~
test.cpp: In function ‘auto func(Tree*)’:
test.cpp:15:9: note: ‘e’ declared here
15 | Array e(c);
| ^
My question is this: why does the presence of the assert() affect whether or not gcc reports a maybe-uninitialized warning?
The example I show happens to use the eigen3 library, but I think my question is more general. How can the inclusion of an assert() that merely compares two int values lead to a compiler warning like this?
I want to note that this code is a minimal reproducible example for this assert-dependent-warning behavior. Removing the for-loop inside func(), for instance, makes the warning appear even without the assert. Replacing e.sum() / (e + 1) with a simpler expression like e + 1 makes the warning disappear with the assert. Replacing the std::bitset with something else also makes the warning disappear with the assert.
I am using gcc-11.3.0 and eigen-3.4.0.
This is apparently due to a gcc bug. The bug is present in gcc-12 or lower, and is fixed in gcc-13. A fix might be coming in gcc-12.
Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108230

C++ Function Template is not deducing Eigen vector sizes

I have written a function
template <int N>
bool checkColinear(const std::array<Eigen::Vector<double, N>, 3>& points) noexcept;
which takes three N-D points and returns true if they are collinear within a certain tolerance. Everything works if I call the function and explicitly specify N:
std::array<Eigen::Vector3d, 3> points = {Eigen::Vector3d{0.0, 1.0, 0.0},
Eigen::Vector3d{0.0, 3.0, 0.0},
Eigen::Vector3d{0.0, 2.0, 0.0}};
auto result = checkCollinear<3>(points);
But if I try to call the function without specifying N explicitly the compiler reports an error:
auto result = checkCollinear(points);
The error I get is "error C2672: 'checkCollinear': no matching overloaded function found".
Is it possible for the compiler to deduce the template argument in this case? I am using MSVC143 (VS2022) and using C++20.
I have already tried to explicitly change the Eigen::Vector3d to Eigen::Vector<double, 3> and Eigen::Matrix<double, 3, 1>, but that neither of those fix it. I have also tried making the type of N a std::size_t too, but that doesn't help either.
As mentioned in the comments, this is likely a bug. A workaround is to spell out the full type name for Vector<double, N> as:
Matrix<double, N, 1, 0, N, 1>
^ ^ ^ ^
col row/col major max rol max col
And your function signature will become:
template <int N>
bool checkCollinear(const std::array<Eigen::Matrix<double, N, 1, 0, N, 1>, 3>& points) noexcept;
Demo

Creating an unindent algorithm using boost::range

I'm creating an unindent algorithm for a text-editor. I've managed to obtain the range to operate on, but when I want to do the Gtk::TextBuffer::erase, it fails:
void unindentSelection(const Glib::RefPtr<Gtk::TextBuffer> &buffer)
{
Gtk::TextBuffer::iterator start, end;
buffer->get_selection_bounds(start, end);
auto selRange = boost::make_iterator_range(start, end);
auto buffRange = boost::make_iterator_range(buffer->begin(), buffer->end());
auto prevRangeRev = boost::make_iterator_range(buffRange.begin(), selRange.begin()) | boost::adaptors::reversed;
auto prevRangeLineRev = boost::find<boost::return_begin_found>(prevRangeRev, '\n');
auto prevRangeLine = prevRangeLineRev | boost::adaptors::reversed;
auto afterRange = boost::make_iterator_range(selRange.end(), buffRange.end());
auto afterRangeLine = boost::find<boost::return_begin_found>(afterRange, '\n');
auto exSelRangeAux = boost::join(prevRangeLine, selRange);
auto exSelRange = boost::join(exSelRangeAux, afterRangeLine);
show_range(exSelRange);
while (true)
{
auto spaceRange = boost::find_if<boost::return_begin_found>(exSelRange, findNonspaceNL);
if (boost::distance(spaceRange))
{
buffer->erase(spaceRange.begin(), spaceRange.end());
}
}
}
TextEditor.cpp:501:31: error: no viable conversion from 'boost::range_detail::join_iterator >, Gtk::TextIter, unsigned int, unsigned int, boost::iterators::bidirectional_traversal_tag>, Gtk::TextIter, unsigned int, unsigned int, boost::iterators::bidirectional_traversal_tag>' to 'const iterator' (aka 'const Gtk::TextIter')
buffer->erase(spaceRange.begin(), afterRangeLine.end());
^~~~~~~~~~~~~~~~~~
/usr/include/gtkmm-3.0/gtkmm/textiter.h:145:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'boost::range_detail::join_iterator >, Gtk::TextIter, unsigned int, unsigned int, boost::iterators::bidirectional_traversal_tag>, Gtk::TextIter, unsigned int, unsigned int, boost::iterators::bidirectional_traversal_tag>' to 'const Gtk::TextIter &' for 1st argument
class TextIter
^
/usr/include/gtkmm-3.0/gtkmm/textiter.h:145:7: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'boost::range_detail::join_iterator >, Gtk::TextIter, unsigned int, unsigned int, boost::iterators::bidirectional_traversal_tag>, Gtk::TextIter, unsigned int, unsigned int, boost::iterators::bidirectional_traversal_tag>' to 'Gtk::TextIter &&' for 1st argument
class TextIter
^
/usr/include/gtkmm-3.0/gtkmm/textbuffer.h:378:34: note: passing argument to parameter 'range_begin' here
iterator erase(const iterator& range_begin, const iterator& range_end);
Any ideas?
I had to create an iterator type that contained a templated 'Iterator it' inside (which in my case is the Gtk::TextIter), using 'boost::iterator_facade'. All operations to the iterator where forwarded to 'it', except the operator*(), that just gave the plain iterator. So the erasing was done in this way:
buffer->erase(*spaceRange.begin(), *spaceRange.end());
This new type of iterator will be very useful manipulating ranges. Not sure this is the best solution, but works.

Compilation Error Using template programming with Eigen C++ library

I downloaded Eigen (3) library and started using it. I wrote a template function and declared a local variable of 'template type' inside the function. I am getting the following compilation error.
$ g++ EigenTest.cpp
EigenTest.cpp: In instantiation of ‘void myFunc(Eigen::MatrixBase<Derived>&) [with Type1 = Eigen::Matrix<double, -1, -1>]’:
EigenTest.cpp:24:10: required from here
EigenTest.cpp:16:26: error: conversion from ‘Eigen::DenseCoeffsBase<Eigen::Matrix<double, -1, -1>, 1>::Scalar {aka double}’ to non-scalar type ‘Eigen::Matrix<double, -1, -1>’ requested
Type1 tmp = matrix(0, 0);
"EigenTest.cpp" is given below.
#include "Eigen/Dense"
#include <iostream>
template<typename Type1>
void myFunc(Eigen::MatrixBase<Type1>& matrix)
{
int i=matrix.rows();
Type1 tmp = matrix(0, 0); // getting compiler error here
std::cout<<"tmp is ->"<<tmp<<std::endl;
}
int main()
{
Eigen::MatrixXd m(2,2);
m.setConstant(100);
myFunc(m);
return 0;
}
I also tried using 'typename Type1 tmp = matrix(0, 0);'
This also didn't work!
How to fix this?
In normal C++ template programming (without Eigen), I can define a local variable inside a template function as 'Type1 tmp;"
In Eigen::MatrixBase<Type1>, Type1 is not a scalar type but the type of the actual expression. In your example it will be MatrixXd but if myFunc is called on, e.g., m.block(...), then Type1 will be a Block<...>. To obtain the scalar type, you can use Type1::Scalar:
template<typename Type1>
void myFunc(Eigen::MatrixBase<Type1>& matrix)
{
typename Type1::Scalar Scalar;
Scalar tmp = matrix(0, 0);
}
And if you need a matrix type that is similar to Type1, use Type1::PlainObject, e.g.:
typename Type1::PlainObject mat = 2 * matrix * matrix.transpose();
It looks like MatrixBase uses the "CRTP" (see here), the template argument is actually the type deriving from it. Thus in your use of the method myFunc(), Type1 is actually representing Eigen::MatrixXd, and I think that you think Type1 is a double. So, this line:
Type1 tmp = matrix(0, 0);
In the documnetation for this library (see here) the typedef for MatrixXd is a matrix of doubles, so I guess the return from matrix(0, 0) is a double, and as tmp is of Type1 which is Eigen::MatrixXd, the one will not go into the other.
Scanning the docummentation I think it MIGHT be better for your function to take a Matrix as an argument, that way the scalar type should be available. Something like this:
template<class T, int rows, int cols, int opts, int maxR, int maxC >
void myFunc( Eigen::Matrix<T, rows, cols, opts, maxR, maxC>& matrix )
{
T tmp = matrix(0, 0);
}
(Looks dreadful though!!! ;-) )
In your code, Type1 is deduced to be double (because Eigen::MatrixXd is defined that way).
You are then trying to do
Type1 tmp = matrix(0, 0);
And I'm afraid my Eigen knowledge isn't enough, so I ran it through Clang 3.3, and got this error:
test.cpp:9:7: error: no viable conversion from 'Scalar' (aka 'double') to
'Eigen::Matrix<double, -1, -1, 0, -1, -1>'
Type1 tmp = matrix(0, 0); // getting compiler error here
^ ~~~~~~~~~~~~
test.cpp:17:1: note: in instantiation of function template specialization
'myFunc<Eigen::Matrix<double, -1, -1, 0, -1, -1> >' requested here
myFunc(m);
^
/usr/include/eigen3/Eigen/src/Core/Matrix.h:210:5: note: candidate constructor not viable:
no known conversion from 'Scalar' (aka 'double') to
'internal::constructor_without_unaligned_array_assert' for 1st argument
Matrix(internal::constructor_without_unaligned_array_assert)
^
/usr/include/eigen3/Eigen/src/Core/Matrix.h:284:25: note: candidate constructor not
viable: no known conversion from 'Scalar' (aka 'double') to 'const
Eigen::Matrix<double, -1, -1, 0, -1, -1> &' for 1st argument
EIGEN_STRONG_INLINE Matrix(const Matrix& other)
^
/usr/include/eigen3/Eigen/src/Core/Matrix.h:272:25: note: candidate template ignored:
could not match 'MatrixBase<type-parameter-0-0>' against 'double'
EIGEN_STRONG_INLINE Matrix(const MatrixBase<OtherDerived>& other)
^
/usr/include/eigen3/Eigen/src/Core/Matrix.h:292:25: note: candidate template ignored:
could not match 'ReturnByValue<type-parameter-0-0>' against 'double'
EIGEN_STRONG_INLINE Matrix(const ReturnByValue<OtherDerived>& other)
^
/usr/include/eigen3/Eigen/src/Core/Matrix.h:303:25: note: candidate template ignored:
could not match 'EigenBase<type-parameter-0-0>' against 'double'
EIGEN_STRONG_INLINE Matrix(const EigenBase<OtherDerived> &other)
^
1 error generated.
which is telling me you cannot call matrix like that, with two 0's as arguments. It's also weird syntax because the MatrixBase class does not have an operator() which you seem to be trying to calling.

Is it possible to alias boost::make_iterator_range?

I am having trouble aliasing the function boost::make_iterator_range
(I would like to hide boost behind an alias in case this particular library gets adopted into the standard sometime in the future.)
Is there any way this can be made to work?
#include <boost/range/iterator_range.hpp>
void Foo()
{
}
template< typename T >
void Bar()
{ }
template< typename T >
void Bar(char c)
{ }
void (&FooAlias)() = Foo; // ok
void (&BarAlias)() = Bar<int>; // ok
// boost::iterator_range<const size_t*> (&MakeIterRangeAlias)(const size_t*,const size_t*) =
// boost::make_iterator_range<const size_t*>; // not ok
int main(int argc, char** argv)
{
const size_t v[] = { 3, 5, 1, 5, 29, 15 };
boost::iterator_range<const size_t*> r
= boost::make_iterator_range( std::begin( v ), std::end( v )); // want to alias this
return 0;
}
The error message is:
In file included from /usr/include/boost/iterator/iterator_categories.hpp:15:0,
from /usr/include/boost/iterator/detail/facade_iterator_category.hpp:7,
from /usr/include/boost/iterator/iterator_facade.hpp:14,
from /usr/include/boost/range/iterator_range_core.hpp:23,
from /usr/include/boost/range/iterator_range.hpp:13,
from sandbox.cpp:2:
/usr/include/boost/mpl/eval_if.hpp: In instantiation of ‘boost::mpl::eval_if_c<true, boost::range_const_iterator<const long unsigned int*>, boost::range_mutable_iterator<const long unsigned int* const> >’:
/usr/include/boost/range/iterator.hpp:63:63: instantiated from ‘boost::range_iterator<const long unsigned int* const>’
sandbox.cpp:20:10: instantiated from here
/usr/include/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c<true, boost::range_const_iterator<const long unsigned int*>, boost::range_mutable_iterator<const long unsigned int* const> >::f_ {aka struct boost::range_const_iterator<const long unsigned int*>}’
/usr/include/boost/mpl/eval_if.hpp: In instantiation of ‘boost::mpl::eval_if_c<false, boost::range_const_iterator<const long unsigned int*>, boost::range_mutable_iterator<const long unsigned int*> >’:
/usr/include/boost/range/iterator.hpp:63:63: instantiated from ‘boost::range_iterator<const long unsigned int*>’
sandbox.cpp:20:10: instantiated from here
/usr/include/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c<false, boost::range_const_iterator<const long unsigned int*>, boost::range_mutable_iterator<const long unsigned int*> >::f_ {aka struct boost::range_mutable_iterator<const long unsigned int*>}’
sandbox.cpp:20:10: error: invalid initialization of non-const reference of type ‘void (&)(const size_t*, const size_t*) {aka void (&)(const long unsigned int*, const long unsigned int*)}’ from an rvalue of type ‘<unresolved overloaded function type>’
make: *** [sandbox] Error 1
Using function pointers is a suboptimal way alias a function. It is not as flexible as the original (it can no longer be a template) and you now need to know the exact signature of the function, which may or may not be stable.
Instead try this approach.
template< typename ... Args >
auto MakeIterRangeAlias( Args&& ... args ) -> decltype( /* copy return line here */ )
{
return boost::make_iterator_range( std::forward<Args>(args)... );
}
With almost no work on your part the alias supports the exact signature of the original. Even if it dramatically changes, you're still set. Further, unlike the function pointer approach the optimizer will be able to trivially inline MakeIterRangeAlias so that there is no runtime overhead.