[xsd-users] Default values for optional elements.

[Moss, David R (SELEX Comms) (UK Christchurch)]

Boris,

Yes, the class-static variable does sound the way forward despite the
initialisation overhead - seems like a reasonable trade-off against
making two object copies per call to default() and aligning that
behaviour with that of get().

Cheers,
Dave.

Dave Moss
SELEX Communications
Grange Road
Christchurch
Dorset  BH23 4JE
United Kingdom
Tel: + 44 (0) 1202 404841
Email: david.r.moss at selex-comm.com


-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com]
Sent: 17 February 2006 07:59
To: Moss, David R (SELEX Comms) (UK Christchurch)
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] Default values for optional elements.

Hi David,

[I've CC'ed xsd-users back in.]


Moss, David R (SELEX Comms) (UK Christchurch)
<david.r.moss at selex-comm.com> writes:

> I've had a play with the new version and noticed that the
> default_value() function creates and returns a copy each time it is
> called.
>
> This means that a function that does:
>
> return foo.bar ().present ? foo.bar ().get () : foo.bar::default_value
> ();
>
> has to return a copy. Whereas the following would not require any
copies
> to be made and the client also would not require its own copy:
>
>
> static const type& default_value();
>
> inline
> const foo::bar::type& foo::bar::
> default_value ()
> {
>    static foo::bar::type  instance =
>    ::xsd::cxx::tree::default_value_factory<
> 		foo::bar::type>::create("default_value", 0);
>
>    return instance;
> }
>
> Any thoughts?


Hm, this is an interesting idea. I agree that it would be nice to
have return types of get() and default_value() aligned. However,
adding a static variable in the default_value will effectively make
it uninlinable. I guess it is a good tradeoff for string-based types
(where, currently, we are looking at heap allocation every time
default_value is called) but could be not so good for fundamental
C++ types (e.g., bool, int). However, this case can be specialized
to return by value (along with get(), which is on my TODO).

Yet another approach would be to have a class-static variable with
default value. The drawback is that it will always be initialized
no matter whether it is used or not. The advantages of this approach
include inlinable default_value and, more importantly, this makes it
usable in MT environments. This approach can also benefit from
specialization for fundamental types.

It seems to me like the class-static variable is the winner. Thoughts?


thanks,
-boris

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************