asutton / origin Goto Github PK

Several test programs in Origin make use of the C library's assert macro, which is problematic because three of CMake's predefined build configurations ("Release", "MinSizeRel", and "RelWithDebInfo") use the compiler flag -DNDEBUG, which causes assert to become a no-op. Unless this is the intended behavior, test programs should use an alternate assert macro/function.

Note: The "Debug" configuration has no such problem, as does building Origin without explicitly specifying a configuration (the default option).

Prior to commit 2aa1056, the Destructible concept was defined in terms of std::is_destructible. Following that commit, it is defined using a requires expression that uses an explicit destructor call and requires that a pointer to the type can be constructed.

The current Destructible concept fails for some types that are destructible according to the libstdc++ std::is_destructible implementation; specifically for reference types and arrays of known bound. The following example demonstrates this:

$ cat destructible.cpp

#include <type_traits>

template<typename T>
concept bool 
Destructible() 
{ 
#if USE_IS_DESTRUCTIBLE
  return std::is_destructible<T>::value;
#else
  return requires (T* t) { t->~T(); };
#endif
}

template<Destructible T>
void f();

void bar() {
    f<char[5]>(); // constraints not satisfied; ok with is_destructible
    f<int&>();    // constraints not satisfied; ok with is_destructible
}

$ g++ -c -std=c++1z -DUSE_IS_DESTRUCTIBLE destructible.cpp

<no errors>

$ g++ -c -std=c++1z destructible.cpp

destructible.cpp: In function ‘void bar()’:
destructible.cpp:18:16: error: cannot call function ‘void f() [with T = char [5]]’
     f<char[5]>(); // constraints not satisfied; ok with is_destructible
                ^

destructible.cpp:15:6: note:   constraints not satisfied
 void f();
      ^

destructible.cpp:15:6: note:   concept ‘Destructible<char [5]>()’ was not satisfied
destructible.cpp:19:13: error: cannot call function ‘void f() [with T = int&]’
     f<int&>();    // constraints not satisfied; ok with is_destructible
             ^

destructible.cpp:15:6: note:   constraints not satisfied
 void f();
      ^

destructible.cpp:15:6: note:   concept ‘Destructible<int&>()’ was not satisfied

I don't know what motivated the change to the Destructible concept definition. Unless there is good reason to avoid std::is_destructible, I recommend reverting the change to the concept definition.

Relevant C++ DRs:

• http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2049

Hello,

This simple program yields a compiler error:

#include <origin/core/concepts.hpp>

void foo(origin::Number x) { }

int main()
{
  foo(10);
}

The error is the following:

/home/jalospinoso/concepts/main.cpp: In function ‘int main()’:
/home/jalospinoso/concepts/main.cpp:7:9: error: invalid reference to function concept ‘template<class T> concept bool origin::Ordered()’
   foo(10);
         ^
/home/jalospinoso/concepts/main.cpp:7:9: error: cannot call function ‘void foo(auto:1) [with auto:1 = int]’
/home/jalospinoso/concepts/main.cpp:3:6: note:   constraints not satisfied
 void foo(origin::Number x) { }
      ^~~
In file included from /home/jalospinoso/concepts/main.cpp:1:0:
/usr/local/include/origin/core/concepts.hpp:442:10: error: invalid reference to function concept ‘template<class T> concept bool origin::Ordered()’
   return Ordered<T>
          ^~~~~~~~~~
/usr/local/include/origin/core/concepts.hpp:440:14: note: within ‘template<class T> concept bool origin::Number() [with T = int]’
 concept bool Number()
              ^~~~~~
/home/jalospinoso/concepts/main.cpp:7:9: note: ill-formed constraint
   foo(10);
         ^
CMakeFiles/concepts.dir/build.make:62: recipe for target 'CMakeFiles/concepts.dir/main.cpp.o' failed
make[2]: *** [CMakeFiles/concepts.dir/main.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/concepts.dir/all' failed
make[1]: *** [CMakeFiles/concepts.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Is this related to this GCC bug?

Thanks in advance. The concepts TS is very exciting.

uninitialized_copy and uninitialized_move algorithms do not contain any return statement, and thus returning garbage. Supposedly they should return the final iterator into the second range.

In file included from /home/walter/workspace/study/asutton-origin-4358f0d/origin/memory/memory.cpp:4:
/home/walter/workspace/study/asutton-origin-4358f0d/origin/memory/memory.hpp: In function ‘void origin::construct(T*, Args&& ...)’:
/home/walter/workspace/study/asutton-origin-4358f0d/origin/memory/memory.hpp:25:46: error: return-statement with a value, in function returning ‘void’ [-fpermissive]
return new(p) T(std::forward(args)...);

"origin/core/type.hpp" uses the C++ standard library function std::to_string(), which, along with all the other numeric conversion functions (e.g. std::stoi(), std::stol(), std::stoul(), etc.) is not defined by libstdc++ on Cygwin (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61580#c3).

origin/core/concepts.hpp declares a Convertible concept that relies on a compiler supplied __is_convertible_to intrinsic. Recent gcc builds fail to compile this concept due to removal of the intrinsic.

__is_convertible_to was removed in gcc svn revision 215735:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=215735

Example reduced test case using a recent gcc trunk build (5.0, c++-concepts, svn revision 219158):

$ cat convertible.cpp
template<typename T, typename U>
concept bool
Convertible() {
return __is_convertible_to(T, U);
}

$ g++ --version
g++ (GCC) 5.0.0 20141112 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -std=c++1z -c convertible.cpp
convertible.cpp: In function ‘constexpr bool Convertible()’:
convertible.cpp:4:33: error: expected primary-expression before ‘,’ token
return __is_convertible_to(T, U);
^
convertible.cpp:4:36: error: expected primary-expression before ‘)’ token
return __is_convertible_to(T, U);
^
convertible.cpp:4:36: error: there are no arguments to ‘__is_convertible_to’ that depend on a template parameter, so a declaration of ‘__is_convertible_to’ must be available [-fpermissive]
convertible.cpp:4:36: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)