Re: [gtk-list] Re: Gtk--: G_List quirks

[Kevin Handy <kth srv net>]

At 07:17 PM 8/3/98 +0200, you wrote:
>Kevin Handy <kth@srv.net> writes:
>
>>Not "most", but a large part indeed. Which has nothing to do with
>resulting binary size anyway (we tried massive inlining in Gtk-- at
>some point, and went back because the lib size had almost doubled).

It really depends on the size of the functions being inlined, and
the optimizations that are available in the compiler. For simple
assign/read value functions, it can really decrease code size.
What I was trying to convey was the fact that the functions being
inline, it shouldn't generate code for functions that were never used.

>> One thing that the STL does give you, as opposed to the (void *)
>> pointers, is it doesn't have to store the pointer to the data,
>> wich saves you 4 bytes (or more) of storage for each node.
>
>I don't see what you mean. You still have to store something in a
>node, and if it's not a pointer to an object, it's the object itself
>(or a copy), which in 99% of the time is much less efficient.

I'd think that storing an object would take less room than
storing an object + storing a pointer to the object.

>What the STL gives you is efficient, type-safe, re-useable data
>containers, means to explore them, and algorithms to operate on
>them.

-------------------------------------------------------------
Kevin Handy  kth@srv.net         Accounting Software for
Software Solutions. Inc.         VAX/VMS Computer Systems
Idaho Falls, Idaho