basicpp17/basicpp17

A basic C++17 based base library

basicpp17's Issues

Add checked access to partial

See title.

This is by intention. get<N> is like a cast. You have to know that the type is there, otherwise ghosts will hunt you at night. If we throw exceptions here, the resulting program would suffer a huge performance hit.

Originally posted by @arBmind in #7

Test failure when activating optimization with Clang

When using -O2 to run the tests (e.g. in the release build) some tests fail that do not fail with -O0 (in the debug build).
The exact issue seems to be optimization pass no. 7532 on Partial.test.cpp which is described as follows:

BISECT: running pass (7532) Dead Store Elimination on function (_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_)

auto partial17::Partial<char, int, float>::Partial(partial17::Partial<char, int, float> const&)::{lambda(auto:1)#1}::operator()<unsigned long>(unsigned long) const

Disassembling and comparing the resulting binary files when using 7531 vs 7532 optimization passes yielded the following result:

$ objdump --prefix-addresses -M intel -d /tmp/build-BasiC++17-Desktop-Release/qtc_Desktop_Release/partial17.tests.c7ff2201/partial17.tests > objdump7531.asm
$ objdump --prefix-addresses -M intel -d /tmp/build-BasiC++17-Desktop-Release/qtc_Desktop_Release/partial17.tests.c7ff2201/partial17.tests > objdump7532.asm
$ diff objdump7531.asm objdump7532.asm                                                                                                                      
16336,16343c16336,16341
< 000000000001a9c3 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x3> mov    rax,QWORD PTR [rdi]
< 000000000001a9c6 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x6> mov    rax,QWORD PTR [rax]
< 000000000001a9c9 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x9> mov    QWORD PTR [rsp-0x8],rax
< 000000000001a9ce <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0xe> mov    edx,0x1
< 000000000001a9d3 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x13> shl    rdx,cl
< 000000000001a9d6 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x16> lea    rax,[rsp-0x8]
< 000000000001a9db <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x1b> ret    
< 000000000001a9dc <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x1c> nop    DWORD PTR [rax+0x0]
---
> 000000000001a9c3 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x3> mov    edx,0x1
> 000000000001a9c8 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x8> shl    rdx,cl
> 000000000001a9cb <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0xb> lea    rax,[rsp-0x8]
> 000000000001a9d0 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x10> ret    
> 000000000001a9d1 <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x11> nop    WORD PTR cs:[rax+rax*1+0x0]
> 000000000001a9db <_ZZN9partial177PartialIJcifEEC1ERKS1_ENKUlT_E_clImEEDaS4_+0x1b> nop    DWORD PTR [rax+rax*1+0x0]

This can be seen in commit f7b910a when setting a breakpoint at Partial.h:108. Seems to me as if the optimizer expects the correct value to be already stored in [rsp-0x8].

Named Strongs can be nested

Not sure if this is intended, but the following code compiles (on clang 8.0.0) even though I would expect it to throw an error at line 12.

#include <meta17/Type.h>
#include <strong17/Strong.opaque.h>
#include <strong17/Strong.trait.h>

#include <utility>

using strong17::Strong;

STRONG_OPAQUE_TYPE(MyOpaqueStrong, Strong<int>);

void testFunction() {
    using ThisShouldNotWork = Strong<MyOpaqueStrong>;
    ThisShouldNotWork tmp;
}

Tuple ostream operator using indices instead of types to iterate over tuple.

See title.

Originally posted by @arBmind in #7

Valgrind analysis shows: Partial copy constructor is accessing uninitialized memory

Apparently the hasValue lambda returns a value that is tracked as invalid:

All invocations of the copy constructor basically are reported like this in valgrind:

==2299== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2299== Command: ./coreModel.tests
==2299== 
==2299== Conditional jump or move depends on uninitialised value(s)
==2299==    at 0x7938CB: _ZZN9partial177PartialIJN9variant177VariantIJNSt3__16vectorIN7tuple175TupleIJN6schema7DriveIdENS6_IJNS7_14DriveCentralIdENS7_9NameValueENS7_25MeterMinimumPositionValueENS7_25MeterMaximumPositionValueENS7_25MeterMaximumVelocityValueENS7_25MeterMinimumVelocityValueENS7_29MeterMaximumAccelerationValueENS7_29MeterMaximumDecelerationValueENS7_33MeterMaximumAccelerationJerkValueENS7_33MeterMaximumDecelerationJerkValueEEEEEEENS3_9allocatorISK_EEEENS6_IJS8_NS0_IJS9_SA_SB_SC_SD_SE_SF_SG_SH_SI_EEEEEES8_EEEN8strong176StrongINS2_IJN5event22PerformanceNodeCreatedENST_22PerformanceNodeUpdatedENST_9TreeMovedENST_11TreeDeletedEEEEJNS7_18PerformanceTreeTagEEEEEE11fromFactoryIRZNS11_C1ERKS11_EUlTyT_E_RZNS11_C1ES14_EUlTyS15_E0_EEDaOS15_OT0_ENKUlTyTyS15_S1B_E_clIN6meta175ConstILm0EEENS1F_4TypeISQ_EEEEDaS15_S1B_ (Partial.h:168)
==2299==    by 0x7937E4: _ZN9partial177PartialIJN9variant177VariantIJNSt3__16vectorIN7tuple175TupleIJN6schema7DriveIdENS6_IJNS7_14DriveCentralIdENS7_9NameValueENS7_25MeterMinimumPositionValueENS7_25MeterMaximumPositionValueENS7_25MeterMaximumVelocityValueENS7_25MeterMinimumVelocityValueENS7_29MeterMaximumAccelerationValueENS7_29MeterMaximumDecelerationValueENS7_33MeterMaximumAccelerationJerkValueENS7_33MeterMaximumDecelerationJerkValueEEEEEEENS3_9allocatorISK_EEEENS6_IJS8_NS0_IJS9_SA_SB_SC_SD_SE_SF_SG_SH_SI_EEEEEES8_EEEN8strong176StrongINS2_IJN5event22PerformanceNodeCreatedENST_22PerformanceNodeUpdatedENST_9TreeMovedENST_11TreeDeletedEEEEJNS7_18PerformanceTreeTagEEEEEE15visitIndexTypesIZNS11_11fromFactoryIRZNS11_C1ERKS11_EUlTyT_E_RZNS11_C1ES15_EUlTyS16_E0_EEDaOS16_OT0_EUlTyTyS16_S1C_E_JLm0ELm1EEEEDaS1B_N6meta179ConstPackIJXspT0_EEEE (Partial.h:304)
==2299==    by 0x793627: _ZN9partial177PartialIJN9variant177VariantIJNSt3__16vectorIN7tuple175TupleIJN6schema7DriveIdENS6_IJNS7_14DriveCentralIdENS7_9NameValueENS7_25MeterMinimumPositionValueENS7_25MeterMaximumPositionValueENS7_25MeterMaximumVelocityValueENS7_25MeterMinimumVelocityValueENS7_29MeterMaximumAccelerationValueENS7_29MeterMaximumDecelerationValueENS7_33MeterMaximumAccelerationJerkValueENS7_33MeterMaximumDecelerationJerkValueEEEEEEENS3_9allocatorISK_EEEENS6_IJS8_NS0_IJS9_SA_SB_SC_SD_SE_SF_SG_SH_SI_EEEEEES8_EEEN8strong176StrongINS2_IJN5event22PerformanceNodeCreatedENST_22PerformanceNodeUpdatedENST_9TreeMovedENST_11TreeDeletedEEEEJNS7_18PerformanceTreeTagEEEEEE11fromFactoryIRZNS11_C1ERKS11_EUlTyT_E_RZNS11_C1ES14_EUlTyS15_E0_EEDaOS15_OT0_ (Partial.h:164)
==2299==    by 0x5E0974: partial17::Partial<variant17::Variant<std::__1::vector<tuple17::Tuple<schema::DriveId, tuple17::Tuple<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> >, std::__1::allocator<tuple17::Tuple<schema::DriveId, tuple17::Tuple<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> > > >, tuple17::Tuple<schema::DriveId, partial17::Partial<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> >, schema::DriveId>, strong17::Strong<variant17::Variant<event::PerformanceNodeCreated, event::PerformanceNodeUpdated, event::TreeMoved, event::TreeDeleted>, schema::PerformanceTreeTag> >::Partial(partial17::Partial<variant17::Variant<std::__1::vector<tuple17::Tuple<schema::DriveId, tuple17::Tuple<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> >, std::__1::allocator<tuple17::Tuple<schema::DriveId, tuple17::Tuple<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> > > >, tuple17::Tuple<schema::DriveId, partial17::Partial<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> >, schema::DriveId>, strong17::Strong<variant17::Variant<event::PerformanceNodeCreated, event::PerformanceNodeUpdated, event::TreeMoved, event::TreeDeleted>, schema::PerformanceTreeTag> > const&) (Partial.h:109)
==2299==    by 0x5E03D4: core_model::CoreModel::processEvent(partial17::Partial<variant17::Variant<std::__1::vector<tuple17::Tuple<schema::DriveId, tuple17::Tuple<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> >, std::__1::allocator<tuple17::Tuple<schema::DriveId, tuple17::Tuple<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> > > >, tuple17::Tuple<schema::DriveId, partial17::Partial<schema::DriveCentralId, schema::NameValue, schema::MeterMinimumPositionValue, schema::MeterMaximumPositionValue, schema::MeterMaximumVelocityValue, schema::MeterMinimumVelocityValue, schema::MeterMaximumAccelerationValue, schema::MeterMaximumDecelerationValue, schema::MeterMaximumAccelerationJerkValue, schema::MeterMaximumDecelerationJerkValue> >, schema::DriveId>, strong17::Strong<variant17::Variant<event::PerformanceNodeCreated, event::PerformanceNodeUpdated, event::TreeMoved, event::TreeDeleted>, schema::PerformanceTreeTag> > const&) (CoreModel.cpp:59)
==2299==    by 0x4ACF73: _ZN10core_model10TestSystem10createNodeIN6schema12ComplexAllOfIJN9variant177VariantIJNS2_7DefaultENS2_9NameValueEEEENS2_12ComplexOneOfIJN6meta174NoneENS3_IJNS2_7RayAxisEEEEEEENS2_22StartPositionParameterENS2_20EndPositionParameterENS2_24NominalVelocityParameterENS5_IJS6_NS2_21AccelerationTimeValueEEEENS5_IJS6_NS2_21DecelerationTimeValueEEEENS2_18TotalTimeParameterENS2_24MinimumPositionParameterENS2_24MaximumPositionParameterEEEEEENS2_6NodeIdENS2_8ParentIdENS2_8BeforeIdEDTcl9toStoragetlN7storage4WrapIT_EEEEE (TestSystem.h:39)
==2299==    by 0x4A4BAA: NodeTreeTest_createEmptyGroup_Test::TestBody() (NodeTree.test.cpp:69)
==2299==    by 0x5B03F3: void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2418)
==2299==    by 0x596ABA: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2454)
==2299==    by 0x57C3F5: testing::Test::Run() (gtest.cc:2492)
==2299==    by 0x57CF24: testing::TestInfo::Run() (gtest.cc:2668)
==2299==    by 0x57D553: testing::TestCase::Run() (gtest.cc:2786)

Might be related to #14?

Alternative naming schema

We need a more consistent naming schema.

Suggestion:

• Variant current OneOf
• Partial current SomeOf
• Tuple stays - may have been AllOf

count_of<TypePack<int>> returns 0

I was using meta17::count_of<TypePack<int>> which returns 0 because the type TypePack<int> is not in the empty typepack.
However I was expecting to get the amount of types present in TypePack<int> which is 1.

Not getting a compiler error led me to believe that this is the correct function for that.
Maybe we should introduce a compiler error for such cases?

ExtractTypePack does not return a TypePack

I would expect these lines to compile:

static_assert(type_pack_index_of<int, decltype(extract_type_pack<TypePack<IndexType<23, int>>>)> == 0ul);
static_assert(type_pack_index_of<int, ExtractTypePack<TypePack<IndexType<23, int>>>> == 0ul);

But they don't. Because the results of extract_type_pack and ExtractTypePack are marked const and thus are not matched to the correct declaration of indexed_type_pack_index_of.

To check constness, compile this and see the warnings:

template<class... Ts>
struct [[deprecated]] print_types;

using A = print_types<ExtractTypePack<TypePack<IndexType<23, int>>>>;
using B = print_types<decltype(extract_type_pack<TypePack<IndexType<23, int>>>)>;

Usability of Tuple constructors

Assume a Tuple of different type

using Aggregate = Tuple<A, B, C>;

The generated Tuple offers 2 relevant kind of constructors:

 b) Aggregate(C{}, B{}, A{}) // Same number of arguments, but in arbitrary order

 a) Aggregate(Tuple{B{}, A{}}) // construct from lesser Tuple, also arbitrary order

a) makes it very difficult to read from the compiler errors, because it has a complicated SFINAEd signature that doesn't allow the compiler to display a simple type conversion error.
MSVC doesn't even bother to list the failed candidates, and just gives the dreaded "Can't convert initializer list..." error.
The current resolution to this case would be Aggregate{Tuple{A, B}}, leaning on Tuple's type deduction guide, to first construct an appropriate "lesser tuple".

I also argue that reordering argument reordering, and argument omission are convenience features intended for test case construction, and belong together.

Also, only one of these conveniences (the re-ordering) is duplicated in both implementations,
and in both cases obstruct proper constructor argument related error messages.

Related to #9 and #12

Create more intuitive behaviour when creating Tuples with duplicate types from smaller tuples

See title.

Yes this is weird but I don't want to spend time on thinking about these corner cases, until we have a use case.
Tuple should be fast and correct for a "custom" definition of input spaces. Strange behavior in unused corner cases, should not bother us.

Originally posted by @arBmind in https://github.com/basicpp17/basicpp17/diffs

meta17::contains_of<A, B> returns False

meta17::contains_of<A, B> checks wether B contains A, when B is a typepack. However when B is not a typepack, it just checks, wether B is the same type as A. This makes it easier to make mistakes when using this construct and harder to find the errors that result from those mistakes.

Non-template function definition in header file - causes "multiple definition" error

Here:
src/string17.lib/string17/StringView.ostream.h:8

Should tuple only accept sorted argument lists in constructor?

See title.

Originally posted by @arBmind in #7

Revise naming schema

Some functionality has different names for each container, e.g.:

Originally posted by @arBmind in #7