Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70243 > unrolled thread

issues with std::variant

Back to article view | Back to comp.lang.c++

Contents

  issues with std::variant wtholliday@gmail.com - 2019-12-04 08:37 -0800
    Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-04 10:26 -0800
      Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-04 11:07 -0800
        Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-04 12:31 -0800
          Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-04 13:09 -0800
            Re: issues with std::variant "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-04 22:39 +0100
              Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-04 16:18 -0800
                Re: issues with std::variant "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-05 05:13 +0100
                  Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-05 09:59 -0800
                    Re: issues with std::variant Christian Gollwitzer <auriocus@gmx.de> - 2019-12-06 09:39 +0100
                      Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-06 09:12 -0800
            Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-04 14:46 -0800
              Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-04 16:28 -0800
                Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-05 00:00 -0800
                  Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-05 00:48 -0800
                    Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-05 08:17 -0800
                      Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-05 09:44 -0800
                        Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-05 11:14 -0800
                          Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-05 12:37 -0800
                            Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-05 13:20 -0800
                              Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-05 13:42 -0800
                                Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-05 15:41 -0800
                                  Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-06 09:44 -0800
                                    Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-07 04:43 -0800
                                      Re: issues with std::variant Manfred <noname@add.invalid> - 2019-12-07 18:17 +0100
                                        Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-07 11:45 -0800
                        Re: issues with std::variant Christian Gollwitzer <auriocus@gmx.de> - 2019-12-06 09:58 +0100
                          Re: issues with std::variant Öö Tiib <ootiib@hot.ee> - 2019-12-06 06:06 -0800
    Re: issues with std::variant David Brown <david.brown@hesbynett.no> - 2019-12-04 22:34 +0100
      Re: issues with std::variant Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-05 15:07 +0000
        Re: issues with std::variant Taylor <wtholliday@gmail.com> - 2019-12-05 10:01 -0800
        Re: issues with std::variant David Brown <david.brown@hesbynett.no> - 2019-12-05 22:15 +0100

Page 2 of 2 — ← Prev page 1 [2]

#70296

On Thursday, December 5, 2019 at 1:20:11 PM UTC-8, Öö Tiib wrote:
> On Thursday, 5 December 2019 22:37:20 UTC+2, Taylor  wrote:
> > On Thursday, December 5, 2019 at 11:14:39 AM UTC-8, Öö Tiib wrote:
> > > 
> > > Sounds again like some kind of straw-man argument ... who would serialize
> > > whole document to store erasure or change of one image? Only the state and
> > > location of image before change needs to be serialized for to be capable
> > > of restoring it.
> > 
> > Sure, I could serialize diffs, but with significant additional complexity (it's a bit close to the memento pattern).
> 
> What diffs? Chain of reversible operations. 
> First operation: Erase: that picture from there. 
> Next operation Undo: put that picture back there. 
> Next operation Redo: erase that picture again from there. 
> What have diffs to do with Memento pattern? Utter nonsense.
> Read at least Wikipedia article about it.

The chain of reversible operations (changes) you describe is error prone and requires additional complexity.

As an example, in Photoshop, Adobe has abandoned the chain reversible operations in favor of value oriented design.

I'd recommend watching Sean Parent's talks such as this one: https://www.youtube.com/watch?v=QGcVXgEVMJg.

> 
>  If you know of a way that flatbuffers makes that easier, that would be good to know. I couldn't find anything searching around.
> 
> Flatbuffers? Huh? But it generates all code for you? All for
> needed for storing your data into buffer or reading it back from
> it. Bit verbose interface for my taste but clear enough. Have you
> at least tried the tutorials of it or something?
> Very confusing.

I've used flatbuffers extensively at this point.

[toc] | [prev] | [next] | [standalone]

#70298

On Thursday, 5 December 2019 23:42:30 UTC+2, Taylor  wrote:
> On Thursday, December 5, 2019 at 1:20:11 PM UTC-8, Öö Tiib wrote:
> > On Thursday, 5 December 2019 22:37:20 UTC+2, Taylor  wrote:
> > > On Thursday, December 5, 2019 at 11:14:39 AM UTC-8, Öö Tiib wrote:
> > > > 
> > > > Sounds again like some kind of straw-man argument ... who would serialize
> > > > whole document to store erasure or change of one image? Only the state and
> > > > location of image before change needs to be serialized for to be capable
> > > > of restoring it.
> > > 
> > > Sure, I could serialize diffs, but with significant additional complexity (it's a bit close to the memento pattern).
> > 
> > What diffs? Chain of reversible operations. 
> > First operation: Erase: that picture from there. 
> > Next operation Undo: put that picture back there. 
> > Next operation Redo: erase that picture again from there. 
> > What have diffs to do with Memento pattern? Utter nonsense.
> > Read at least Wikipedia article about it.
> 
> The chain of reversible operations (changes) you describe is error prone and requires additional complexity.

So go ahead and store state of your whole document after each click.
Or maybe even commit it to repo ... how should I care?

> As an example, in Photoshop, Adobe has abandoned the chain reversible operations in favor of value oriented design.

Who is there in Adobe? I know no one from it. Perhaps all the decent
engineers who made it what it is have been eaten out. If whatever
is left of it decides to rewrite their Acrobat in F# then should
we follow?

> I'd recommend watching Sean Parent's talks such as this one: https://www.youtube.com/watch?v=QGcVXgEVMJg.

Scrolled a bit into that video. First he pushed
rawly newed pointer to document then said that it is wrong and used
the most dork tool std::make_shared! I stopped right there. Had it
been std::make_unique I would had guessed that poor kid hasn't tried
polycollections like you. But snake oil salesmen start from such
clear idiocies for to ensure that by minute 7 everybody with at least
half a brain are left away and only total morons remain. 

Do not post anymore YouTube crap. Watching such TV and movies is
perhaps good entertainment for retarded and illiterate. 

> >  If you know of a way that flatbuffers makes that easier, that would be good to know. I couldn't find anything searching around.
> > 
> > Flatbuffers? Huh? But it generates all code for you? All for
> > needed for storing your data into buffer or reading it back from
> > it. Bit verbose interface for my taste but clear enough. Have you
> > at least tried the tutorials of it or something?
> > Very confusing.
> 
> I've used flatbuffers extensively at this point.

Sorry, it does not make any sense what is supposed to be the
issue with it. Decent serialization library with bit more
verbose interface than I would use.

[toc] | [prev] | [next] | [standalone]

#70315

On Thursday, December 5, 2019 at 3:41:38 PM UTC-8, Öö Tiib wrote:
> 
> Scrolled a bit into that video. First he pushed
> rawly newed pointer to document then said that it is wrong and used
> the most dork tool std::make_shared! I stopped right there. 

You should continue watching. He's just using shared_ptr in his example. A production implementation would use a small-object optimization. In fact, central to his type erasure scheme is reducing the amount of dynamic allocation.

[toc] | [prev] | [next] | [standalone]

#70332

On Friday, 6 December 2019 19:44:14 UTC+2, Taylor  wrote:
> On Thursday, December 5, 2019 at 3:41:38 PM UTC-8, Öö Tiib wrote:
> > 
> > Scrolled a bit into that video. First he pushed
> > rawly newed pointer to document then said that it is wrong and used
> > the most dork tool std::make_shared! I stopped right there. 
> 
> You should continue watching. He's just using shared_ptr in his example.

Huh? Each shared_ptr usage is dynamic allocation of sole object plus
complicating your data from tree to directed acyclic or may be even
introducing directed cycles into your data. Additionally it is rather
expensive (in both performance and storage usage) smart pointer. It
has usages but rare or else you turn your program into as error prone
and inefficient mess as typical Java or C# programs are.
So video where you are casting it into code without apparently no 
thought applied is not worth watching. It proves that you are either
snake oil salesman or noob.

> A production implementation would use a small-object optimization. In fact, central to his type erasure scheme is reducing the amount of dynamic allocation.

Blah blah blah blah? If something can't be written as document then
it is *never* worth watching as video either. I have already posted link
to document and open source implementation of one way how to reduce
dynamic allocations:
<https://www.boost.org/doc/libs/1_71_0/doc/html/poly_collection.html>
C++ is powerful so there are several other ways and each can be
used and discussed in separation or in combination.

[toc] | [prev] | [next] | [standalone]

#70338

On 12/7/2019 1:43 PM, Öö Tiib wrote:
> On Friday, 6 December 2019 19:44:14 UTC+2, Taylor  wrote:
>> On Thursday, December 5, 2019 at 3:41:38 PM UTC-8, Öö Tiib wrote:
>>>
>>> Scrolled a bit into that video. First he pushed
>>> rawly newed pointer to document then said that it is wrong and used
>>> the most dork tool std::make_shared! I stopped right there.
>>
>> You should continue watching. He's just using shared_ptr in his example.
> 
> Huh? Each shared_ptr usage is dynamic allocation of sole object plus
> complicating your data from tree to directed acyclic or may be even
> introducing directed cycles into your data. Additionally it is rather
> expensive (in both performance and storage usage) smart pointer.
The point about shared_ptr in the video is that the speaker starts 
presenting a use of shared_ptr, then he shows how bad it is and replaces 
it for a while with unique_ptr. However, in the end he resumes the use 
of shared_ptr, but only as pointer to const, as a mean to reduce copies. 
So it is less stupid than you posed it.

That said, I don't like shared_ptr either.

  It
> has usages but rare or else you turn your program into as error prone
> and inefficient mess as typical Java or C# programs are.
Totally agree on this.

> So video where you are casting it into code without apparently no
> thought applied is not worth watching. It proves that you are either
> snake oil salesman or noob.
> 
>> A production implementation would use a small-object optimization. In fact, central to his type erasure scheme is reducing the amount of dynamic allocation.
> 
> Blah blah blah blah? If something can't be written as document then
> it is *never* worth watching as video either. I have already posted link
> to document and open source implementation of one way how to reduce
> dynamic allocations:
> <https://www.boost.org/doc/libs/1_71_0/doc/html/poly_collection.html>
> C++ is powerful so there are several other ways and each can be
> used and discussed in separation or in combination.
> 

[toc] | [prev] | [next] | [standalone]

#70341

On Saturday, 7 December 2019 19:17:57 UTC+2, Manfred  wrote:
> On 12/7/2019 1:43 PM, Öö Tiib wrote:
> > On Friday, 6 December 2019 19:44:14 UTC+2, Taylor  wrote:
> >> On Thursday, December 5, 2019 at 3:41:38 PM UTC-8, Öö Tiib wrote:
> >>>
> >>> Scrolled a bit into that video. First he pushed
> >>> rawly newed pointer to document then said that it is wrong and used
> >>> the most dork tool std::make_shared! I stopped right there.
> >>
> >> You should continue watching. He's just using shared_ptr in his example.
> > 
> > Huh? Each shared_ptr usage is dynamic allocation of sole object plus
> > complicating your data from tree to directed acyclic or may be even
> > introducing directed cycles into your data. Additionally it is rather
> > expensive (in both performance and storage usage) smart pointer.
> The point about shared_ptr in the video is that the speaker starts 
> presenting a use of shared_ptr, then he shows how bad it is and replaces 
> it for a while with unique_ptr. 

Does not matter. Usage of shared_ptr is often outright defect.
Usage of lot of single object allocations/deallocations is 
not defect (but usually weak design).

> However, in the end he resumes the use 
> of shared_ptr, but only as pointer to const, as a mean to reduce copies. 
> So it is less stupid than you posed it.

Ok, I agree, not so utterly stupid. Making the shared objects immutable
makes it at least valid to process our now directed acyclic data in
embarrassingly parallel manner. So we at least can burden all the
cores (or even GPUs in our typical target architecture) next to
effortlessly when needed.

But the prices of dynamic memory management per object, overhead
from expensive pointer, incapability to realize that equivalent
immutable object that we are creating now is already shared
elsewhere and additional trouble during serialization still remain.
I by default resolve those proactively by having special (smart)
factory and special (smart) pointers but shared_ptr can also be
good enough when used like that.

However when data logically really has directed cycles in it (that
happens ultra rarely) then I use likes of Parallel BGL.
<https://www.boost.org/doc/libs/1_71_0/libs/graph_parallel/doc/html/index.html>
At least some hope that someone else is testing it too.

> That said, I don't like shared_ptr either.
> 
>   It
> > has usages but rare or else you turn your program into as error prone
> > and inefficient mess as typical Java or C# programs are.
> Totally agree on this.

So I'm just bit allergic to it. The unreliable stuff that has
resulted from misuse of shared_ptr IMHO keeps damaging reputation
of C++. Unsure what book taught to put it everywhere ... it should
be burnt.

[toc] | [prev] | [next] | [standalone]

#70301

Am 05.12.19 um 18:44 schrieb Taylor:
> On Thursday, December 5, 2019 at 8:17:37 AM UTC-8, Öö Tiib wrote:
>> Why not to use serialization capabilities for most of such purposes?
>> Everything worth undoing or rolling back wants soon to become
>> something that is worth storing persistently and even worth
>> transferring to far-away sites.  There are literal piles of serialization
>> libraries available (like Protobufs, Flatbuffers, Cereal, Cap'n Proto,
>> Bond, Apache Avro, Thrift, MessagePack and just name it). The
>> popular ones are done by good programmers, tested by lot of
>> people and so tend to be adequate and far from naive. Pick one
>> that is language- and platform-neutral ... that provides also wider
>> opportunities of automatic black-box testing of your modules. ;)
> 
> I use Flatbuffers for serialization. It's pretty good. But it doesn't easily provide the structural sharing that I need to make undo/redo memory-efficient. For example, if my document contains large data (images, audio, etc.) I don't want to have to save that out after every user interaction. 

We used such a scheme for undo/redo in a project (written in another 
language, not C++).  The document there consists of 3D meshes composed 
into a 3D scene and attached properties like material, transformation, 
... So the actual data was quite small (few kb for a realistic document, 
even if stored in text format) compared to multi-MB of 3D mesh data. 
Even before we introduced undo/redo, the serialization format did not 
include the 3D meshes. There is a global storage of the big objects, a 
hash map indexed by the MD5 of the binary mesh data, and the document 
simply references these. On I/O, only the transformation data is 
serialized into a compact format and a second pass reads/writes the 
binary object table. The on-disc format in the end was a ZIP file, this 
is similar to modern text writer formats. Just rename a docx-file to 
.zip and open it up, then you'll see it uses the same scheme.

Undo/redo with this scheme was instant, almost no memory consumption, so 
we could provide unlimited undo.

Christian

[toc] | [prev] | [next] | [standalone]

#70306

On Friday, 6 December 2019 10:58:47 UTC+2, Christian Gollwitzer  wrote:
> The on-disc format in the end was a ZIP file, this 
> is similar to modern text writer formats. Just rename a docx-file to 
> .zip and open it up, then you'll see it uses the same scheme.

Yes, lot of projects use that format: folders of utf8 text and
portable binary files zipped, just that json instead of xml is
more usual.

[toc] | [prev] | [next] | [standalone]

#70257

On 04/12/2019 17:37, wtholliday@gmail.com wrote:
> I'm using std::variant in my code for one very important type
> (`Node`). This variant has 68 different types in it. There are two
> issues:
> 
> 1. Compile times are extremely slow (~30s per file), due to variant
> visitation. I'm an indie developer and I don't want to have to buy a
> new computer (might only be a factor of two faster anyway).
> 

There are many possibilities for speeding up compilation.  But we'd need 
a lot more information to be able to tell.  I can only give some vague 
suggestions (in no particular order), without knowing which might apply.

1. If your computer is very slow, get a better one - or upgrade the one 
you have (more memory is often helpful).

2. Consider changing compilers if the compiler is slow.

3. If you are working with lots of files in the project, make sure you 
are using a good build system with parallel builds.

4. If you have everything in a few huge files, split them up (and use a 
parallel build system).

5. If you are using Windows and have parallel builds and lots of files, 
especially with gcc or clang, try Linux.  If you are stuck with Windows, 
try with an SSD instead of a hard disk.

6. Look at pre-compiled header support.

7. Check the compiler flags.  You'll want some optimisation, but be 
careful about using some of the more powerful ones (especially ones that 
are not part of any -O option), as they can involve a great deal of 
compiler effort.  But if you have no optimisation, the compiler will 
have to generate huge amounts of code, which can be slower than optimising.

8. Consider something other than variant.  A variant needs quite a bit 
of compile-time effort to get its static type safety and convenience, 
and a 68 type variant is going to involve a very large amount of 
compile-time effort.

[toc] | [prev] | [next] | [standalone]

#70282

On 04/12/2019 21:34, David Brown wrote:
> 5. If you are using Windows and have parallel builds and lots of files, 
> especially with gcc or clang, try Linux.  If you are stuck with Windows, 
> try with an SSD instead of a hard disk.

I'd try the SSD before I went to the pain of switching OS.

(I still haven't found a Linux IDE as good as visual studio)

Andy

[toc] | [prev] | [next] | [standalone]

#70290

On Thursday, December 5, 2019 at 7:07:06 AM UTC-8, Vir Campestris wrote:
> On 04/12/2019 21:34, David Brown wrote:
> > 5. If you are using Windows and have parallel builds and lots of files, 
> > especially with gcc or clang, try Linux.  If you are stuck with Windows, 
> > try with an SSD instead of a hard disk.
> 
> I'd try the SSD before I went to the pain of switching OS.
> 
> (I still haven't found a Linux IDE as good as visual studio)
> 
> Andy

FWIW, my 2013 laptop already has a SSD.

Thing is, this computer is fast enough for almost everything I do. So it would be good to save the money.

[toc] | [prev] | [next] | [standalone]

#70294

On 05/12/2019 16:07, Vir Campestris wrote:
> On 04/12/2019 21:34, David Brown wrote:
>> 5. If you are using Windows and have parallel builds and lots of 
>> files, especially with gcc or clang, try Linux.  If you are stuck with 
>> Windows, try with an SSD instead of a hard disk.
> 
> I'd try the SSD before I went to the pain of switching OS.
> 

People vary as to what they consider a "pain" regarding an OS.  Much has 
to do with familiarity, both of the OS and the tools you have on it.  I 
use both Windows and Linux, and have no doubts to which I find most 
efficient for development work.  But I fully appreciate that others have 
different preferences, experiences and requirements.

As for switching to an SSD, that will require less change in habits or 
tools, but it is not always an easy job with an existing system.  If you 
are using Linux, I wouldn't bother with the SSD if your machine has 
plenty of ram (and upgrading ram is usually easy), but it makes a bigger 
difference on Windows.

> (I still haven't found a Linux IDE as good as visual studio)
> 

I've never been an MSVS fan - again, it's subjective.  But I believe MS 
Visual Studio Code has a good reputation on Linux.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web