Could this container I made have any use?

[karolak kolo]

I wrote a C++ container which I call "bucket", and basically it is a prototype of an array that can hold multiple types at the same time.

It is used like this:

bucket<N, types> example; //Declaring a bucket that can hold N items, and can support types listed after commas. For example bucket<55,int,float> could hold 55 elements of types float or int.

example[i] = value; //Assigns a value to a cell of the bucket. Value of any type that was listed in the <> brackets is supported.

value = (type)example[i] // assigns a value of a cell in the bucket to some variable. The type of the item retrieved has to be put in parentheses like that. (This will be improved in the future).

The implementation can be found here: http://pastebin.com/fVMhqph8

Could this have any use?

[Mr Flibble]

What's wrong with an array or vector of boost::variant?

/Flibble

[karolak kolo]

I didn't know that exists, but still what would be the use of this?

[Öö Tiib]

On Thursday, 2 February 2017 03:31:01 UTC+2, karolak kolo wrote:
> I didn't know that exists, but still what would be the use of this?

Please quote to what you are answering, otherwise it is
unclear what you mean by "that" or "this" above. I assume you
mean 'std::variant', but if I'm wrong then discard the rest
of this letter.

The 'std::variant' will be added to C++ standard library this
year and it is basically type safe union (never empty and no
type punning possible):
http://en.cppreference.com/w/cpp/utility/variant

Requirements of it are widely based on implementation of
'boost::variant' (that has been around for more than decade):
http://www.boost.org/doc/libs/1_63_0/doc/html/variant.html

If custom class does not offer something special then most
good programmers prefer standard library classes. It is so
because standard library classes are generally more efficient,
flexible, available for more platforms, better tested and/or
faster fixed than custom classes.

So the question was what is special in 'bucket<55,int,float>'
that lacks in 'std::array<55, std::variant<int,float>>'?

Of course if you are not aware of existence of 'boost::variant'
like you say then it is likely that you can't answer why your
'bucket' is special compared to such alternatives.

[bitrex]

I remember boost::variant being a pain in the butt to use, and
boost::any is really slow!

[woodb...@gmail.com]

On Thursday, February 2, 2017 at 7:43:46 AM UTC-6, Öö Tiib wrote:
> On Thursday, 2 February 2017 03:31:01 UTC+2, karolak kolo wrote:
> > I didn't know that exists, but still what would be the use of this?
>
> Please quote to what you are answering, otherwise it is
> unclear what you mean by "that" or "this" above. I assume you
> mean 'std::variant', but if I'm wrong then discard the rest
> of this letter.
>
> The 'std::variant' will be added to C++ standard library this
> year

Howard Hinnant predicted on an episode of Cppchat

http://www.slashslash.info/cppchat/

that the latest version of the standard would be passed on
December 31, 2017 at 10pm (if I remember correctly).

Better late than never ...

>and it is basically type safe union (never empty and no
> type punning possible):
> http://en.cppreference.com/w/cpp/utility/variant
>
> Requirements of it are widely based on implementation of
> 'boost::variant' (that has been around for more than decade):
> http://www.boost.org/doc/libs/1_63_0/doc/html/variant.html
>
> If custom class does not offer something special then most
> good programmers prefer standard library classes. It is so
> because standard library classes are generally more efficient,
> flexible, available for more platforms, better tested and/or
> faster fixed than custom classes.
>

I think implementation-wise Clang shuns standard containers.
I try to avoid them also, but I'm not successful yet in avoiding std::queue/std::deque.


Brian
Ebenezer Enterprises - "Hope is worth any money." Thomas Fuller
http://webEbenezer.net

[Öö Tiib]

May be you conflate two things that are very far from one
another.
My impression of 'boost::variant' is that it is fast and easy to
use. More convenient than union.
My impression of 'boost::any' however is negative from
every side: slow, inconvenient, fragments memory and
produces cryptic diagnostics.

[Öö Tiib]

On Sunday, 5 February 2017 21:30:15 UTC+2, woodb...@gmail.com wrote:
> On Thursday, February 2, 2017 at 7:43:46 AM UTC-6, Öö Tiib wrote:
> > On Thursday, 2 February 2017 03:31:01 UTC+2, karolak kolo wrote:
> > > I didn't know that exists, but still what would be the use of this?
> >
> > Please quote to what you are answering, otherwise it is
> > unclear what you mean by "that" or "this" above. I assume you
> > mean 'std::variant', but if I'm wrong then discard the rest
> > of this letter.
> >
> > The 'std::variant' will be added to C++ standard library this
> > year
>
> Howard Hinnant predicted on an episode of Cppchat
>
> http://www.slashslash.info/cppchat/
>
> that the latest version of the standard would be passed on
> December 31, 2017 at 10pm (if I remember correctly).
>
> Better late than never ...

Even if the standard will be signed 2018 the implementations
of std::variant were already useful 2016.

>
>
> >and it is basically type safe union (never empty and no
> > type punning possible):
> > http://en.cppreference.com/w/cpp/utility/variant
> >
> > Requirements of it are widely based on implementation of
> > 'boost::variant' (that has been around for more than decade):
> > http://www.boost.org/doc/libs/1_63_0/doc/html/variant.html
> >
> > If custom class does not offer something special then most
> > good programmers prefer standard library classes. It is so
> > because standard library classes are generally more efficient,
> > flexible, available for more platforms, better tested and/or
> > faster fixed than custom classes.
> >
>
> I think implementation-wise Clang shuns standard containers.

Few years ago when I tried to compile LLVM on microsoft
compiler then it contained lot of C that did not compile on
microsoft compiler. Source of LLVM smelled like another
tool of negotiations between apple and ms. That is most
awful code smell.

> I try to avoid them also, but I'm not successful yet in avoiding std::queue/std::deque.

We discussed those queues. I suggested to check performance
of boost::circular_buffer_space_optimized. You answered
that it is not portable enough for you. :D If you can't improve
such (quite portable, well-tested, open-source) container then
you can't likely make better one either. So you should use
standard containers (as maximally portable).

[bitrex]

IIRC boost::variant classes need to be equality comparable and hashable,
so I had to write some functions to implement that, and also some
"visitor" classes.

Maybe I was doing it wrong?

[Öö Tiib]

The requirement to variant element in boost:
http://www.boost.org/doc/libs/1_62_0/doc/html/variant/reference.html#variant.concepts.bounded-type
It clearly says that comparable and hashable are optional and you need
those when you want emerging variant itself to be comparable or
hashable.

That visitor is for convenience. I always had visitors when I had
dynamic polymorphism between potentially unrelated or fundamental
types (like on case of union or void* that may be actually point at
very different things). I can't imagine other idiom that fits into
those situations better.

>
> Maybe I was doing it wrong?

I do not know. For me variant has worked everywhere where union
was needed. It is simply "better union" for me.

[woodb...@gmail.com]

We want to be rewarded for time spent reading some code: "any"
doesn't go very far in terms of conveying useful information
to readers. I wish it weren't being added to the standard.


Brian
Ebenezer Enterprises - "The robb'd that smiles steals something
from the thief." William Shakespeare

http://webEbenezer.net