Comments (12)
I'm working on this issue incl. optimizing vector. It's not so hard.
from fusion.
The same can be said about any std::is_trivially_***
trait.
Also, for reference, Boost.Hana doesn't seem to have this limitation:
static_assert(std::is_trivially_copyable<hana::tuple<double, int>>{});
from fusion.
Makes sense! Would you contribute a patch or a PR? ;-)
from fusion.
I did some initial testing on this a while back for C++11 vector. I didn't post it because I felt like there were already too many changes. Making it trivial to copy / move should also improve compile times since it is currently using a generic function with more template instantiations. Adding a conversion copy from vector also helped compile times (if implemented carefully). So there are multiple positive benefits to this ...
EDIT: Too many changes -> this was when I was fixing one bug and changed the constructor SFINAE implementation for C++11 vector.
from fusion.
I have a concern what I want to confirm, following code is (or will be) valid and expected, right?
static_assert(std::is_trivially_copyable<fusion::vector<int&>>{}); // OK
// because the struct is trivially copyable even if contains reference
struct S
{
int& r;
};
static_assert(std::is_trivially_copyable<S>{}); // also OK
from fusion.
from fusion.
from fusion.
@alfC thanks.
My answer as of today is "no", sometimes I use bfn::vector or std::tuple, precisely to avoid the above anomaly of C++ structs, including recursive assignment, and recursive comparison
That usage was my concern. I thought it is natural to me that tuple<int&>
is trivially copyable because basically I use tuple as just unnamed struct.
Unfortunately, In my research, makingvector<int&>
non trivially copyable is incompatible with trivially copyable vector....
from fusion.
from fusion.
Looks like in C++11 is not that difficult to solve this issue. It seems to be simply necessary to not explicitly define the operator=(tuple const&)
.
The natural result for tuples containing references is very strange. (Is it desirable?)
#include<utility>
#include<type_traits>
template<class T1, class... Ts>
struct tpl{
T1 head_;
tpl<Ts...> rest_;
/* tpl& operator=(tpl const& o){
head_ = o.head_;
rest_ = o.rest_;
return *this;
}*/
template<class Other> tpl& operator=(Other&& o){
head_ = std::forward<Other>(o).head_;
rest_ = std::forward<Other>(o).rest_;
return *this;
}
};
template<class T>
struct tpl<T>{
T t_;
/* tpl& operator=(tpl const& o){
t_ = o.t_;
}*/
template<class Other> tpl& operator=(Other&& o){
t_ = std::forward<Other>(o).t_;
return *this;
}
};
int main()
{
static_assert(std::is_trivially_copyable<tpl<int, double>>{});
tpl<int, double> t1 = {};
tpl<int, double> t2 = {};
t2 = t1;
int i1 = {};
double d1 = {};
tpl<int&, double&> tr1{i1, d1};
tpl<int&, double&> tr2{i1, d1};
tr1 = t1; // fails unless the specializations in line 15
tr2 = tr1;
t2 = tr1;
// this combination of results is strange
static_assert(!std::is_trivially_copyable<tpl<int&, double&>>{});
static_assert(std::is_trivially_copyable<tpl<int, double&>>{});
static_assert(std::is_trivially_copyable<tpl<int&, double>>{});
}
from fusion.
What do you mean that is "incompatible"? The way I see it is that unfortunately vector<int&> and vector would have to be implemented differently because they will have different implementations of operator=.
I meant, vector<int&>
requires user-defined special functions to be not trivially copyable, but vector<int>
should not have any user-defined special functions to be trivially copyable.
It can't be solved using SFINAE, because compiler generated special functions (i.e. non-templated) is viable than templated user-defined special functions (n4687 16.3.3 [over.match.best] /1 (1-6)).
IF the language didn't have the quirk it has one would be able to implement a tuple that is trivially copyable very easily by just saying.
template<class T1, class... Ts> tuple { T1 t1; tuple<Ts...> rest; }
, and operator= will work as expected for tuple<T&, ...> and it would be trivially copiable if T1 is trivially copyable and recursively tuple<Ts...> is trivially copyable.
I'm against this way, recursive may be costlier than trivially copyable.
I've got it! It might be solved using helper base class, like this.
struct non_trivial
{
non_trivial& operator=(non_trivial const&) { return *this; }
};
struct trivial
{
};
template <typename T, typename U>
struct tpl : std::conditional_t<std::is_trivially_copyable<T>{} && std::is_trivially_copyable<U>{}, trivial, non_trivial>
https://wandbox.org/permlink/k7xnlZDDAubWSI16
It may not break current optimal (non recursive) implementation.
OFF TOPIC:
// this combination of results is strange
static_assert(!std::is_trivially_copyable<tpl<int&, double&>>{});
static_assert(std::is_trivially_copyable<tpl<int, double&>>{});
static_assert(std::is_trivially_copyable<tpl<int&, double>>{});
GCC passes all, but Clang fails on second. I think Clang is correct.
Compiler generating assign of tpl<T>
is implicitly deleted (same reason as struct), and then compiler generating assign of tpl<T1, Ts...>
instantiates user defined assign (i.e. breaks trivially copyable requirements).
from fusion.
Yes, I agree, although there maybe more natural ways to obtain this result. The other problem is that for the non-trivial case, something needs to be done to operator=(tpl const& other)
. Not sure if you are looking for a solution in the space of C++11, but I found in comment #173 (comment) that it is possilble to have a very compact implementation that respects the trivially copyable requirement.
from fusion.
Related Issues (20)
- Overzealously defining __device__ functions when compiling with nvcc HOT 3
- reverse_fold has no static assert for requiring bidirectional sequence HOT 1
- Testcase failure with optimization -O2 and -O1 in gcc and llvm
- Propose for inplace construct from Fusion Sequence
- List of non BOOST-prefixed macros
- clang-10 warning: definition of implicit copy constructor is deprecated HOT 1
- associability of single_view (and associability preservation of some algorithms)
- make_map<int>(make_vector()) cannot be compiled HOT 3
- What about "boost pfr" extension? HOT 8
- Is there a identity_view? HOT 8
- Potential non consistency in documentation HOT 2
- CI for Linux? HOT 2
- qvm not usable in spirit::x3
- Alternative way to adapt struct? HOT 3
- The result of `value_at` with `std::tuple` does not match result of `value_at` with `boost::fusion::vector` HOT 2
- Please sync main branch with develop HOT 12
- 'J': is not a valid type for non-type template parameter 'J' error in boost\fusion\container\vector\vector.hpp HOT 7
- BOOST_FUSION_ADAPT_ADT macro over 256 elements support
- Include guard inconsistency
- Error in include guard
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fusion.