EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: data access structures, strings
From: "Jeff Hill" <[email protected]>
To: "'Kay-Uwe Kasemir'" <[email protected]>, <[email protected]>
Date: Wed, 28 Sep 2005 09:06:22 -0600
I suppose that these operations *are* constant time given that there
execution time has a linear relation with the number of properties in the
container.

That same relation exists for other compound types like Rational (whose
assignment operator takes two times longer because there are two datums).

Jeff

> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:[email protected]]
> Sent: Tuesday, September 27, 2005 1:18 PM
> To: [email protected]
> Subject: Re: data access structures, strings
> 
> Hi:
> On Sep 27, 2005, at 14:47 , Jeff Hill wrote:
> > PropertyCatalog currently has "operator =" and "operator ==".
> >
> > O Do they meet the conventional wisdom test? That is, is their purpose
> > roughly equivalent to the purpose of these operators with primitive
> > types?
> 
> The '=' is supposed to be a simple assignment.
> Something that can usually be done in one machine-code instruction.
> Maybe a memcpy or double-to-int conversion.
> Not invocations of traverse(), looking for matching properties
> via find(), converting types, ...
> Such a rather complex mapping exceeds what I'd expect
> behind a simple '='.
> 
> I think "The C++ Programming language" has a discussion
> for iterators, operator ++.
> If it's a constant-speed iteration, like an in-memory linked list:
> OK.
> Not OK for remote database access where one '++' returns immediately,
> the next one takes a minute.
> 
> 
> -Kay


References:
Re: data access structures, strings Kay-Uwe Kasemir

Navigate by Date:
Prev: RE: data access structures, strings Jeff Hill
Next: Re: EPICS Meeting agenda Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: data access structures, strings Kay-Uwe Kasemir
Next: Re: data access structures, strings Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·