Nope. The size and position of these widgets is automatically calculated.

Nope. For example, you can write

Row(center(textbox()), left(stack(button(),bitmap())))

Which is extremely readable.

Nope. In my example, the grid had 10000 rows by 10 columns. That's 100000 grid cell instances.

If you allocate them with a single array, then they take 2 mb. Nice way to increase the cache misses in the 1st level cache and dramatically reduce the performance of your game.

For smaller devices, 2 mb ram is significant.

If you do not allocate these entries as a single array, then you risk memory fragmentation. You may alleviate this by using a memory pool though, but then you have the risk of memory management.

The pointer to the widget base is also a raw pointer, not a shared pointer. If you make it a shared pointer as you should, then we are talking about 4 more bytes per grid cell.

Of course, we would not talk about automating positioning and sizing with layouts if that wasn't automatic.

Did you watch the video? I am asking you because I can explain it to you using concrete examples.

The entire 2mb won't be used at the same time. The L1 cache can more than hold the visible elements in a grid.

When will you be using a grid with 100,000 elements on a smaller device? Or even at all?

Not with your example of ten elements in a row. That would become an unreadable nightmare quickly unless you broke each element onto its own line. Does your Row use tuples? I'm only asking b/c it seems like it would have to.

Here is what I would have :

grid.setElement(row , 1 , textbox , HALIGN_CENTER);
grid.setElement(row , 2 , iconbutton , HALIGN_LEFT);

Very readable, and no extra layout objects are necessary.

What I don't see is how you achieve your nested layouts. Do all your widgets and layouts derive from a common base class?

It is not necessary to use shared pointers for widgets in my gui. When you add an element to a gui you tell it whether to destroy the widget when done with it (ie. when removed from the gui). I use a simple map<WidgetBase* , bool> to track which widgets need to be destroyed. And how would a shared_ptr work with a statically allocated widget?

I watched part of it, about the first half. I didn't see anything extraordinary in terms of layout really. What specifically did you want me to see? The second half didn't have much in the way of gui.

Sure you're not being premature in your quest to optimize?

This is the same as in my gui. The only difference is that I allow a layout to act as a panel and widget.

I haven't come across the situation where any widget needs to know about another widget that it isn't directly responsible for to begin with. You don't need a shared pointer to reference a widget. If something depends on a certain widget not being destroyed then don't destroy it until you're done using it. I understand shared_ptr can automate that, but I honestly haven't come across any situations where it would make my life substantially easier.

Also, how would an empty deleter work? Are shared_ptr's type compatible across different deleters? Ie, how could you use a shared pointer to a stack object with shared pointers that have been set up to delete their object when done?

Well it sounds good enough. I would like to see their code though. Is it open source?

Yes, but is a shared pointer with an empty deleter compatible with a shared pointer with a non empty deleter? Ie can they be used together? Can you use a shared pointer to a stack object in a list of shared pointers to heap objects?

If you have to specify the deleter, how is that different from me specifying whether or not to delete my widgets when done? I understand a shared pointer tracks the number of references to an object, but in my case only one class is responsible for destroying widgets and that is the layout. When you remove a widget from a layout it uses its stored bool value to determine whether to destroy it or not. Maybe there are better ways, but this is what I have right now.

I am not. If you don't design it properly from the get go, then you'll create a mess afterwards. Things like that optimization cannot be done properly if not done from the beginning.

So not the same at all.

Believe me, the need arises more often than you can imagine. Especially if you have a deep tree of widgets, due to the existence of layout widgets, you will need to keep pointers to the interesting widgets in your main window.

The deleter is part of the struct that is shared between pointers.

Nope.

You don't need one, an empty lambda function will do.

When using shared pointers, and assuming you don't have reference cycles, you don't care about when to set the widget for destruction.

In your case, you do. Your design is nothing more than deleting an object with a delay, which doesn't solve any reference problems.

Just for your reference, the code name was C++0x but the official name is C++11 and not C++11x

Good catch. I evidently wasn't paying too much attention.

Even if you do need a reference to a widget, leave the deletion of the widget to its owner. If you delete your widget before you're done with it, that's your own problem.

But my design also doesn't have any reference problems. When the layout with the widgets is on it is destroyed so are the widgets. It's simple to avoid problems, don't destroy your layouts until you're done with them.

I will admit though, I'm having kind of a design quandary. The lines between layout and widget handler are kind of blurred right now. Right now layouts do one thing, and that is position widgets. My widget handler takes care of drawing and input and event handling. The problem is sometimes it would be advantageous to have layouts draw their children but then they have to implement z order, dirty rectangles and / or buffering the gui image.

I just haven't come up with a nice way to keep everything separated out into a nice modular design. What I have works, but its a blurred line as to who should be responsible for drawing.

Most of the time there isn't a clear owner of a widget. This is especially true when using layout widgets: the layout widgets are never the actual managers of their children widgets in terms of functionality.

You simply transfer the lifetime management problem of the child widget to the parent layout widget.

In other words, with your design, the question 'when shall I delete this widget?' becomes 'when shall I delete this widget's parent?'.

That's not the only problem of your library, but it's nice to admit at least one flaw of it.

and want them to live beyond the life of their container widget.

Absolutely. It comes up very often.

I guess we'd need a memory-pool (hierarchical?) with reference counting to accomplish this. Then we can re-use it for shared objects (icons, text, etc.)

Depends how much hand-holding vs performance we want to trade.

I really like Enlightenment E18 and their Eo object model.
They even go so far as to hide object pointers from you completely.
All you get is an object id to interact with.

Haha