Re: Re: "any" suggestions

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-07-17 02:20:40

Corwin Joy writes
>Sure.  We have a variant class in the Database Template Library that I
>co-authored (http://www.geocities.com/corwinjoy/dtl/index.htm).  What
>happens is that at construction time, the program analyzes the table being
>bound to and determines the types of the columns such as date, string,
>integer, wide-string etc.  Once these types have been determined a variant
>is constructed to hold each database column.  After initial construction,
>any writes into this variant class are not allowed to change the variant's
>type (otherwise the database binding would become invalid).  So, writes into
>the variant are cast into whatever type is currently held by the object.  If
>the cast cannot be performed, a runtime exception is thrown.
>I think other examples of this "type" prototype are out there.  Examples
>might be initial parsing of a file to determine the types of fields held and
>then holding this types fixed after construction or other applications where
>the metadata is analyzed seperately from the value and needs to remain fixed
>after construction.

I'm already aware of the DTL, and there's some good stuff in there, but
I must confess this is not how I would solve or have solved the sticky-
variant type (ie projects changes through its current type): separate
the concept of value and type descriptor, and ensure that from the point
of construction the type remains unchanged. It would be inconsistent if
any (or anyx) supported sticky input but not sticky assignment. Again,
although the usage is legit, this would fundamentally change the
semantics of any if it were introduced properly.

>> Have you considered not using strings in your program as well? I hear
>> they use dynamic memory ;-)
>
>strings are a different problem. They require variable sized allocations,
>any potentially does not.  By using a fixed size allocater for the holder
>I'm pretty certain you can get significant performance gains.

Strings are not that different. What would the fixed size for any be?

>> This is a reasonable consideration and has been mentioned before on this
>> list, but if I were to introduce it I would need to be convinced that it
>> is both effective and genuinely desirable, given the tradeoffs it
>> introduces -- it is not, by definition, an "upgrade".
>
>And what exactly is the "downside" of providing a template parameter to take
>an allocator.  It seems relatively easy to add & I don't see how it would
>degrade the existing functionality or performance of any.

There are a number of downsides. For one thing, the design of allocators
:-> Then we also get into the semantics of swapping, initialisation,
etc. In other words, a lot of the baggage that the standard containers
have to put up with, and for little benefit: any is not like vector, it
holds only a single element at a time, does not have to resize, copy
multiple values, etc.

>I'm quite leery of making lots of calls to new to alloc small blocks after
>having gotten bitten by a hard to track memory bug with small reallocs in
>VC5 vis http://support.microsoft.com/support/kb/articles/Q225/0/99.ASP

In this case I can understand your caution, but that is a fault of a
platform implementation rather than a general property of small
allocations -- it could equally well have been a bug that afflicted
medium or large allocations, or allocations whose byte sizes fell on the
days of the year when there is a full Moon.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________