FLTK logo

Re: [fltk.general] Re: [Fl_Flow] A new layout manager for FLTK

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Re: [Fl_Flow] A new layout manager for FLTK Bill Spitzak Oct 29, 2021  
 
I don't think there is a problem with modern systems with using std::vector (and also std::unique_ptr which will help with making arrays of pointers).

Schemes to hide them from the header files I think add unnecessary overhead, if an object uses a std::vector it will have to be declared in the header file.

Certainly the implementations are using exceptions as a way to encode "unlikely" branches of if statements. I think this is much more common with shared_ptr and with multithreading stuff, not sure how helpful it is for std::vector. Just because so many system libraries use them I'm not sure if disabling exceptions works now or does anything to the compile. IMHO we should be supporting exceptions, in particular a callback should be able to throw one and it causes the Fl::run() or similar function to throw it, rather than crashing. This was done in fltk2.0, not thoroughly tested but a button that threw an exception worked.


On Fri, Oct 29, 2021 at 11:38 AM Albrecht Schlosser <AlbrechtS.fltk@online.de> wrote:
On 10/29/21 7:33 PM Bill Spitzak wrote:
> I don't have any problem with using std::vector, it was not used back
> in the day because it used much more memory and was slower than naive
> C implementations, but this is not true any more.

Bill, would you recommend to use std::vector inside the FLTK library? I
mean: inside, not in the public API.

Doing so could simplify code development for some new features where we
often need to maintain dynamic arrays. I know we discussed this several
times and there were some concerns (doubts) regarding compiler
compatibility and such.

As Ian mentioned in this thread, some implementations of containers
might pull in exceptions which we don't want. Do you have any insights
on this?

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/ef599b5c-d09d-35af-379f-9e60b874f6a8%40online.de.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAL-8oAhXKJp_rGLBB-v3nRcSYLJt-56ns11RzyjW85yuzERsTg%40mail.gmail.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.