Re: [boost] Re: Re: class proposal

[Terje Slettebø]

From: Justin M. Lewis [EMAIL PROTECTED]

 As for a function returning a single param, I agree, normally you'd just
 return it, UNLESS it's some big structure you don't want being copied
 all over the place, then passing it by reference to a function makes
 more sense.

The compiler may elide such copy, even if the temporary being returned is a
named variable, and several compilers (such as g++ and the EDG based ones),
does this optimisation (RVO). For example:

class big_class { ... };

big_class f(...)
{
  big_class temp;

  ...

  return temp;
}

 // Only the constructor is called, here, no copy constructor

big_class value = f(...);

Also, if you want to return multiple values, std::pair or boost::tuple may
be used for that, as Noel Yap pointed out.

I understand the motivation is to transform a lot of existing code into
something that may be more easily understood. However, an alternative to
your method is to use techniques that has been proposed in this thread. For
example:

int return_value = f(type may_change, const type may_not_change); //
Current function

int return_value = fA(c_outtype may_change, const type may_not_change);
// Your method

boost::tupleint, type fB(const type may_not_change); // Alternative

Use:

type value;

int return_value = fA(out(value), const_value); // Your method

int return_value;

boost::tie(return_value, value) = fB(const_value);

Also, you may enforce that the parameters aren't changed, by using const:

const type const_value = ...;

fA(const_value, ...); // Error, can't bind to non-const reference

This may be a larger refactoring than adding out() and in_out(), though,
especially for a large code base, as you mention. I'm just concerned with
that out() and in_out() isn't a very common way to do it, so it may be best
to do it in an idiomatic way, to begin with.

Also, statements like:

boost::tie(return_value, value) = fB(const_value);

stands out in the code, rather than being more hidden with an out(). Thus,
they may have a better chance of being possibly further refactored. Say that
the return code says whether or not a valid object is returned. This may be
changed to:

boost::optionaltype result = fB(const_value);

Or maybe throwing an exception would be more appropriate:

type value = fB(const_value); // Throws on failure

The point really is the same as with your proposal - making it explicit in
the code what is happening.


Regards,

Terje

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Re: class proposal

[Terje Slettebø]

Just to add some to my previous posting.

Also, from a maintenance POV, having variables that doesn't change
throughout a function (or program), tends to make it easier to understand.
Having functions which change their arguments goes rather against that.

One exception is input stream operators, where it's really no other way of
doing it than first declaring a variable, then streaming into it.

For example:

const some_type valueA=...;

const some_type valueB = f(valueA);

// Possibly many lines of code here

// What is valueA and valueB here? Answer: The same as when they were
declared.

Yes, I know it may be a massive undertaking to start making a program, which
wasn't designed that way, const correct. However, it may be one of the
better refactorings to do. It also highlights all the points where something
may be changed, and where further refactorings (such as those in the
previous posting) may be appropriate.


Regards,

Terje

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Sorting list shared_ptr foo using std::list::sort()

[HEATH DAVIS]

I have experienced some difficulty with sorting lists of type:

list  shared_ptr  foo  

Here is the expected (sorted) program output:

424238335
596516649
719885386
846930886
1189641421
1649760492
1681692777
1714636915
1804289383
1957747793
Instead, I end up with:

1804289383
846930886
1681692777
1714636915
1957747793
424238335
719885386
1649760492
596516649
1189641421
Below is the code in question:



#include iostream
#include list
using namespace std;
#include boost/shared_ptr.hpp
using namespace boost;


class my_class
{
public:
int m_val;
public:
my_class();
bool operator(const my_class);
void Display();
};


my_class::my_class()
{
m_val = rand();
}
bool my_class::operator(const my_class arg)
{
return m_val  arg.m_val;
}
void my_class::Display()
{
cout  m_val  \n;
}


int main( int argc, char **argv )
{
// list  my_class  my_list;
// list  my_class ::iterator my_iter;
list  shared_ptr  my_class   my_list;
list  shared_ptr  my_class  ::iterator my_iter;
//populate my_list
for (int x=0; x10; x++)
{
// my_class tmp_obj;
shared_ptr  my_class  tmp_obj;
tmp_obj.reset(new my_class);
my_list.push_back(tmp_obj);
}
//sort the list
my_list.sort();
//display contents of my_list
my_iter = my_list.begin();
while (my_iter != my_list.end())
{
// (*my_iter).Display();
(*my_iter)-Display();

++my_iter;
}
return 0;
}


Thanks in advance for any help you may render...

_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Sorting list shared_ptr foo usingstd::list::sort()

[Daniel Frey]

HEATH DAVIS wrote:
I have experienced some difficulty with sorting lists of type:

list  shared_ptr  foo  

 [snip]

bool my_class::operator(const my_class arg)
{
return m_val  arg.m_val;
}
 [snip]
//sort the list
my_list.sort();
Here, you basically sort by using

shared_ptr::operator

instead of

my_class::operator

You need something like

template T  struct shared_ptr_content_less
{
  bool operator()( const boost::shared_ptr T  lhs,
   const boost::shared_ptr T  rhs ) const
  {
return *lhs  *rhs;
  }
};
and call

my_list.sort( shared_ptr_content_less my_list () );

The code is untested, but I hope you get the idea. Also, there might be 
some easier way using other boost-libs to create the helper on-the-fly, 
but others definitely know better than me :)

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] C++ Standard Library proposal - MathfunctionsforStatistics

[Paul A. Bristow]

I absolutely agree that they are to serve *practical* purposes,

and

I would encourage any guide to accuracy that authors (and others) can provide.

Some functions are easy - within a few eps over the whole domain.
You say LIA has already set framework for those things,
but is it really suitable for 'more difficult' functions?

But I would caution that, for some functions, there are even more PhDs of study
of accuracy than in algorithms themselves. It would cost vendors more to provide
comprehensive accuracy information than writing the functions.

For a start, I have not found many really accurate reference values for some
functions (AS sometimes struggle to achieve float 32-bit).

Many published algorithms provide almost no accuracy data.

How do you specify accuracy (never mind speed and size)?
Stephen Moshier in his collection provides a mean and max from thousands of
random arguments, which is certainly useful, but may mislead - like sincos near
to multiples of pi.

So there is some danger of starting the equivalent of processor chip 'benchmark
wars'.

For many practical statistical purposes, 32-bit float accuracy will suffice.
Do you need to know that the probability of two means being different is
0.95475869798765823?  Often one just decides if it is  0.95. And the
probability  probably has a 95% confidence interval of 0.9 to 0.97 anyway!

So, for me, the most important thing is to have some implementation for people
to put to practical use, while others work on improvements and descriptions of
accuracy.

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
+44 1539 561830   Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]

Example of accuracy data from Cephes incomplete beta - good - but shows how
complicated it is!

* ACCURACY:
* Tested at uniformly distributed random points (a,b,x) with a and b
* in domain and x between 0 and 1.
*Relative error
* arithmetic   domain # trials  peak rms
*IEEE  0,5 1   6.9e-15 4.5e-16
*IEEE  0,85   25   2.2e-13 1.7e-14
*IEEE  0,1000  3   5.3e-12 6.3e-13
*IEEE  0,125   9.3e-11 7.1e-12
*IEEE  0,101   8.7e-10 4.8e-11
* Outputs smaller than the IEEE gradual underflow threshold
* were excluded from these statistics.


| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis
| Sent: Wednesday, April 23, 2003 9:15 PM
| To: Boost mailing list
| Subject: Re: [boost] C++ Standard Library proposal - Math
| functionsforStatistics
|
|
| Paul A. Bristow [EMAIL PROTECTED] writes:
|
| | Indeed, I doubt if long double is practically useful for many applications -
| | even 16 decimal place 64-bit double will be impracticable on MSVC
| where there
| | isn't really a long double (you may need to use 80-bit calculations to get a
| | 64-bit accuracy result).
| |
| | But I don't believe that this is a problem - exp, sin etc don't
| really work for
| | long double on MSVC either! And many implementations are not fully
| accurate -
| | nor would one necessarily want to wait while they calculate to full
| accuracy.
| |
| | The Standard does not, and should not, make any requirements about accuracy,
| | memory size or speed.
| |
| | So I feel they are panicing a bit.
|
| Being one of the persons who raised the accuracy issue, I think I have
| to say why.
|
| The proposed mathematical functions are not there just for selling
| compilers. They are there to serve *practical* purposes.  If there is
| no accuracy guarantee, they don't worth to have -- they are already so
| specialized.  LIA  has already set framework for those things.  Any
| serious proposal to include such specialized functions need to pay
| attention to those things.
|
| -- Gaby
| ___
| Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Sorting list shared_ptr foo usingstd::list::sort()

[Matthew Towler]

I have experienced some difficulty with sorting lists of type:

list  shared_ptr  foo  

Here is the expected (sorted) program output:

424238335
596516649
719885386
846930886
1189641421
1649760492
1681692777
1714636915
1804289383
1957747793
Instead, I end up with:

1804289383
846930886
1681692777
1714636915
1957747793
424238335
719885386
1649760492
596516649
1189641421


list  shared_ptr  my_class   my_list;
list  shared_ptr  my_class  ::iterator my_iter;
The problem is here, as your list contains shared_ptr  my_class , the 
list is ordered by shared_ptr  my_class ::operator which will usually 
amount to an address comparison of the pointers contained in the shared_ptr.

To fix this you need to pass in my_class::operator as the predicate to 
use for the sort().

Matt

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: class proposal

[Noel Yap]

Justin M. Lewis wrote:
 
 I agree.  I probably wouldn't have cared for this myself, had I never seen
 the code I'm working on now.  I mean, normally I work pretty independently.
 But, now I'm stuck with the job of maintaining code that's been around
 forever, has been ported several times to a couple different projects.  In
 places you can see how the code evolved over time.  But, the point is, it's
 becoming a mess.  And, we're at a point where we're almost starting
 everything again, but this time from scratch.  Knowing that the code will
 probably live for years, and be ported several times, and be maintained by
 many different people over its life, it seems best to me to start a project
 like that off with clarity being the #1 priority.  And, at least in my
 experience, people seem to think that functions that pass by reference
 changing the values of params is a problem, it's hard to track.  But, most
 C++ people I know prefer to avoid pointer use.  So, that really only leaves
 the one option that makes the intent explicit and clear, every time.
 
 So, I really can't give a long term analysis of how well this method works,
 if it becomes a hassle to maintain it, or not.  But, as it is, it seems more
 clear to me than anything else.  At the cost of 3 or 6 letters at the
 invocation point, you can make the operation of the function clear.
 
 func(out(x));
 
 It seems pretty simple and straight forward to me.

I believe all that will be accomplished is that these objects will
become ubiquitous in the system just as references are.  For example,
code like the following will start to pop up:

  void f( in_out int  is_not_changed_ )
  {
// use is_not_changed_, but don't change it
  }

IMHO, why not just state from the start to ban in/out parameters?  In
its place, use parameters for in and return for out.  An in/out can
done via a smart pointer.

Noel
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Sorting list shared_ptr foo usingstd::list::sort()

[David Abrahams]

Daniel Frey [EMAIL PROTECTED] writes:

 my_list.sort( shared_ptr_content_less my_list () );

That should be

 my_list.sort( shared_ptr_content_lessfoo() );




or you can do it the easy way using the Boost.Lambda library:

my_list.sort(*_1  *_2);


Regards,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: class proposal

[John Torjo]

   void f( in_out int  is_not_changed_ )
   {
 // use is_not_changed_, but don't change it
   }

I think there would be a much bigger problem (code inside the function would
change).

Just consider

void add_char( std::string  str, char ch)
{ str += ch; }

Now, if we change it so be in_out, we'll have to use a .ref()-like function.


void add_char( in_outstd::string str, char ch)
{ str.ref() += ch; }

Of course, this is a simple example, but it illustrates the point.
The code would become obfuscated.

Frankly, I donot like it.

Best,
John


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Boost proposals accepted by C++ committee

[Ralf W. Grosse-Kunstleve]

--- Daniel Spangenberg [EMAIL PROTECTED] wrote:
 
 These news are very good, but what about the thread library?

I cannot find the beginning of this thread. Where could I read the very good
news?

Thanks,
Ralf


__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: C++ Standard Library proposal -MathfunctionsforStatistics

[Jason House]

Well, take erf using a single parameter for precision

template precision = 0.1
double erf{};

Then in usage somewhere...

{
  double x2 = erf0.01(0);
  double x5 = erf(0);
  cout  round(x2*100)/100.0  round(x2*1E5)*1E-5  endl;
  cout  round(x5*100)/100.0  round(x5*1E5)*1E-5  endl;
}

Possible output:
1.00 0.99583
1.00 1.0

The idea is that erf0.01 only gives a result accurate to 2 decimal
places, while erf or erf0.1 gives a result accurate to 5 decimal
places.

That's the basic idea I tried to convey.

Getting multiple performance parameters in would be tougher... and I'm
unsure as to which would be most useful to people... I could imagine
something like trying to specify a time bound and a minimum precision...
possibly causing a compile-time error if there is no available
implementation that can achieve it.  Of course, the defining of a time
bound is tricky...  As far as precision, an integer number of decimal
places would probably be easier from the implementation standpoint.

Gabriel Dos Reis wrote:
 
 Jason House [EMAIL PROTECTED] writes:
 
 [...]
 
 | Well, *practical* can mean a number of things to different people.
 | Maybe performance constraints should be template parameters with default
 | values?
 
 Once, you have defined meaning for perfomance and workable proposal
 I'd be glad to consider it.
 
 |  One possibility being precision?
 
 Could you elaborate on this please?
 
 -- Gaby
 ___
 Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Sorting list shared_ptr foo usingstd::list::sort()

[Christian Engström]

HEATH DAVIS wrote:
I have experienced some difficulty with sorting lists of type:

list  shared_ptr  foo  

For a while I have been toying with the idea of a smart pointer called 
sortable_ptr, which would behave in the way that [I believe that] the 
original poster erroneously presumed that boost::shared_ptr already did. 
 I was originally planning to do some more practical testing of the 
concept before possibly submitting it as a proposal to Boost, but since 
the topic has now been raised, I will take the opportunity to get some 
feedback as to whether the idea is sound, or if I have missed something 
crucial.

The following is an extract from the draft documentation I have been 
writing.

- - - -

The class sortable_ptr is publicly derived from boost::shared_ptr, but 
defines the comparison operator  (and its siblings , =, and = ) to 
make a comparison of the actual objects.  This means that if the class 
myclass has operator defined, we can write

sortable_ptrmyclass aptr(new myclass(/* Something */));
sortable_ptrmyclass bptr(new myclass(/* Something else*/));
assert((aptr  bptr) == (*aptr  *bptr));
This is different from boost::shared_ptr, which does only define the  
operator to do a direct comparison of the pointers themselves (or 
something to that effect).

The == and != operators retain the semantics that they inherited from 
boost::shared_ptr, which is to test the pointers themselves for 
identity.  This means that even if neither aptr  bptr nor aptr  bptr 
is true for two sortable_ptr pointers, the expression aptr == bptr may 
or may not be true.  If it is true this will mean that both aptr and 
bptr refer to the same myclass object, which of course is neither less 
than or greater than itself.  If the expression aptr == bptr is false, 
it will mean that aptr and bptr point at different objects that are 
equivalent as to their sort order.

What is the advantage of this?

Before answering that question, we note that we have at leas not done 
anything illegal by introducing these definitions.  Neither 
boost::shared_ptr nor sortable_ptr support the notion of pointer 
arithmetic, so we do not need the  operator to be defined in any 
particular way for that purpose.

We can still store sortable_ptr pointers in any of the sequence 
containers in the Standard Template Library, since these only demand 
that the == operator tests for proper identity between the objects that 
are being stored in the list or deque or vector, which it does.
The sort algorithms in STL use the  operator of the objects in the 
container by default, so if we sort a container of sortable_ptr 
pointers, they will appear in the same order as the objects themselves 
would have been sorted.  For vectors and deques it can be considerably 
faster to sort pointers rather than the objects themselves, since the 
generic sort algorithms work by swapping the items in the container, and 
it can be much faster to swap two small pointers than to swap two big 
and complex objects.

For the associative containers set, multiset, map, and multimap, the 
default is to use the  operator of the objects that are stored in the 
container to define equivalence and sort order, which is exactly what we 
want.  When we store sortable_ptr pointers in an associative container, 
the pointers will be sorted in the same order as the actual objects 
would have been if we had stored them directly in a corresponding 
associative container for objects.  The definition of operator ensures 
that any two sortable_ptr pointers are equivalent if, and only if, the 
two underlying objects are equivalent, so for sets and maps, which 
cannot hold more than one object with equivalent keys, it will be the 
same objects that are represented in the container whether the objects 
are stored directly or via sortable_ptr pointers.

- - - -

The draft implementation looks like this at the moment:

//==
//  'sortable_ptr'
//--
template class T, class Compare = std::lessT 
class sortable_ptr : public boost::shared_ptrT
{
private:
  typedef sortable_ptr self;
  typedef boost::shared_ptrT base;
public:
  // From 'boost::shared_ptr'
  //   typedef T element_type;
  //   typedef T value_type;
  //   typedef T * pointer;
  //   typedef typename detail::shared_ptr_traitsT::reference reference;
  //
  typedef Compare element_compare;
  element_compare element_comp() const {return element_compare();}

  bool operator  (const self other) const {return 
element_compare()(**this, *other);}
  bool operator  (const self other) const {return other  *this;}
  bool operator= (const self other) const {return !(other  *this);}
  bool operator= (const self other) const {return !(other  *this);}

// Constructors
  sortable_ptr() {}
  templateclass Y
  sortable_ptr(const sortable_ptrY other) : base(other) {}
  templateclass Y
  explicit sortable_ptr(const boost::shared_ptrY other) : base(other) {}
  templateclass Y
  explicit 

[boost] Little bug in unit_test_result.cpp

[Guillaume Melquiond]

Hi,

I'm not really interested in this file, but since gcc complained about an
unitialized variable, I did fix it. And it is the first patch. So please
apply it (and change the name of the enum item before, if necessary).

However, by looking at the code, I found a good example of data
duplication; and the purpose of the second patch is to clean it a bit.

Regards,

Guillaume
Index: boost/test/detail/unit_test_parameters.hpp
===
RCS file: /cvsroot/boost/boost/boost/test/detail/unit_test_parameters.hpp,v
retrieving revision 1.7
diff -u -r1.7 unit_test_parameters.hpp
--- boost/test/detail/unit_test_parameters.hpp  13 Feb 2003 08:07:20 -  1.7
+++ boost/test/detail/unit_test_parameters.hpp  24 Apr 2003 14:44:14 -
@@ -37,7 +37,7 @@
 c_string_literal const LOG_FORMAT= BOOST_TEST_LOG_FORMAT; // 
--log_format
 c_string_literal const OUTPUT_FORMAT = BOOST_TEST_OUTPUT_FORMAT;  // 
--output_format
 
-enum report_level { CONFIRMATION_REPORT, SHORT_REPORT, 
DETAILED_REPORT, NO_REPORT };
+enum report_level { CONFIRMATION_REPORT, SHORT_REPORT, 
DETAILED_REPORT, NO_REPORT, BAD_REPORT };
 c_string_literal const report_level_names[] = { confirm  , short , 
detailed , no  };
 
 enum output_format { HRF /* human readable format */, XML /* XML */ };
Index: libs/test/src/unit_test_result.cpp
===
RCS file: /cvsroot/boost/boost/libs/test/src/unit_test_result.cpp,v
retrieving revision 1.15
diff -u -r1.15 unit_test_result.cpp
--- libs/test/src/unit_test_result.cpp  15 Feb 2003 21:55:32 -  1.15
+++ libs/test/src/unit_test_result.cpp  24 Apr 2003 14:44:14 -
@@ -490,7 +490,7 @@
 
 static int const map_size = sizeof(name_value_map)/sizeof(my_pair);
 
-report_level rl;
+report_level rl = BAD_REPORT;
 if( reportlevel.empty() )
 rl = CONFIRMATION_REPORT;
 else {
--- libs/test/src/unit_test_result.cpp.old  2003-04-24 16:45:52.0 +0200
+++ libs/test/src/unit_test_result.cpp  2003-04-24 16:50:33.0 +0200
@@ -476,27 +476,15 @@
 void
 unit_test_result::report( std::string const reportlevel, std::ostream where_to_ )
 {
-struct my_pair {
-c_string_literallevel_name;
-report_levellevel_value;
-};
-
-static const my_pair name_value_map[] = {
-{ confirm , CONFIRMATION_REPORT },
-{ short   , SHORT_REPORT },
-{ detailed, DETAILED_REPORT },
-{ no  , NO_REPORT },
-};
-
-static int const map_size = sizeof(name_value_map)/sizeof(my_pair);
+static int const map_size = sizeof(report_level_names)/sizeof(c_string_literal);
 
 report_level rl = BAD_REPORT;
 if( reportlevel.empty() )
 rl = CONFIRMATION_REPORT;
 else {
-for( int i =0; i  map_size; i++ ) {
-if( reportlevel == name_value_map[i].level_name ) {
-rl = name_value_map[i].level_value;
+for( int i = 0; i  map_size; i++ ) {
+if( reportlevel == report_level_names[i] ) {
+rl = (report_level)i;
 break;
 }
 }
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: class proposal

[Justin M. Lewis]

- Original Message -
From: Noel Yap [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Thursday, April 24, 2003 4:13 AM
Subject: Re: [boost] Re: class proposal


 Justin M. Lewis wrote:
 
  in/out seems to be used fairly commonly in COM.  I'm not sure I have any
  great examples off the top of my head, but I know they're commonly used.

 I'm not a COM person, but I believe it's written in C.  If so, then you
 are correct that in/out parameters are more needed since noone would
 want to create a struct for each multiple return type.

 OTOH, C++ has templates to deal with this situation (ie boost::tuple)
 so, qualifying my previous statement, in C++ I still see no need for
 in/out parameters.



I think most COM objects are written in C++.  I should have been more
specific here, if you're looking at ActiveX objects, in/out params are used
all over the place.  Each function returns an HRESULT, iirc, any data you
want returned has to be returned in a param.


  And using pointers is part of what we're trying to avoid here.  Like I
said,
  I avoid using pointers whenever possible at this point.

 I'm a little confused.  Either you pass in the entire object or you pass
 in a pointer (even if it's wrapped in another class).  How is this new
 class supposed to be implemented?


And, it's not either pass in a whole object or pass in a pointer, you're
forgetting references.  This new class takes in a reference, and stores
that.  It doesn't do anything with pointers.

  And, again, the real intent here is to insure clarity at the point of
  invocation.  In my case I'm looking at 100's of thousands of lines of
code,
  written over the past 8 years.  It's tiresome trying to chase down where
  values COULD have changed.  In this setup you KNOW exactly what calls
are
  changing parameter values, and it's enforced.  As long as the library
calls
  use the c_out and c_in_out classes people using the library are forced
to
  conform to the format.  So, 8 years, and a few million lines of code
later,
  no one will wonder what might cause a variable they're tracking to
change
  values.

 I think if parameters are used for in parameters only and return values
 are used for out parameters only, the same thing is achieved.  For
 example,

   inOutValue = square( inOutValue );

 vs (using an extension for generality):

   square( c_in_out typeof( inOutValue ) ( inOutValue ) );

 Noel


And, again, returning an object isn't always desirable, you could be copying
large objects for no reason.  You may not call a copy constructor, but an =
operator is being used.

___
 Unsubscribe  other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: class proposal

[Justin M. Lewis]

I diagree with this.  The code I've written using this looks more like

void add_char( in_outstd::string str, char ch)
{
  std::string s = str;
  s += ch;
}

- Original Message -
From: John Torjo [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Thursday, April 24, 2003 5:20 AM
Subject: Re: [boost] Re: class proposal



void f( in_out int  is_not_changed_ )
{
  // use is_not_changed_, but don't change it
}

 I think there would be a much bigger problem (code inside the function
would
 change).

 Just consider

 void add_char( std::string  str, char ch)
 { str += ch; }

 Now, if we change it so be in_out, we'll have to use a .ref()-like
function.


 void add_char( in_outstd::string str, char ch)
 { str.ref() += ch; }

 Of course, this is a simple example, but it illustrates the point.
 The code would become obfuscated.

 Frankly, I donot like it.

 Best,
 John


 ___
 Unsubscribe  other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: class proposal

[Noel Yap]

Justin M. Lewis wrote:
 And, it's not either pass in a whole object or pass in a pointer, you're
 forgetting references.  This new class takes in a reference, and stores
 that.  It doesn't do anything with pointers.

I didn't really forget references.  IMHO, references are pointers that
are implicitly dereferenced.  At the machine level, they are typically
treated the same (eg address is passed by value).

 And, again, returning an object isn't always desirable, you could be copying
 large objects for no reason.  You may not call a copy constructor, but an =
 operator is being used.

My reply to this was to use smart pointers.  But as Terje Slettebø
pointed out (but I got distracted by work before sending out my reply),
smart pointers don't resolve the problem that the object may still
change from underneath.

I still think there's no need for the proposed wrapper class since:

  void f( T value_may_change_, T const value_may_not_change_ );

is still an acceptible alternative.  IOW, if users stick to using T
only to indicate values that may change, and T const to indicate values
that may not change, the wrapper class has no added value (forgive the
unintended pun).

Noel
-- 
NOTICE: If received in error, please destroy and notify sender.  Sender
does not waive confidentiality or privilege, and use is prohibited.
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Boost proposals accepted by C++ committee

[Daniel Spangenberg]

Ralf W. Grosse-Kunstleve schrieb:

 --- Daniel Spangenberg [EMAIL PROTECTED] wrote:
 
  These news are very good, but what about the thread library?

 I cannot find the beginning of this thread. Where could I read the very good
 news?

 Thanks,
 Ralf


Hello Ralf!

Bad habit of mine, because I use a message browser linking the previous
messages together.
My reply relates to Beman Dawes posting Boost proposals accepted by C++
committee:

The following formal motions were accepted today by the C++ Standards
Committee. Of the ten proposals, eight were based on Boost libraries or
fragments of Boost libraries.

Congratulations to all the Boost developers who worked so long and hard on
these proposals. Also thanks to the Boost participants who helped by
discussing real world uses of the libraries, and provided feedback to the
developers.

--Beman
[snip]


Greetings,

Daniel




___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Re: class proposal

[Noel Yap]

Terje Slettebø wrote:
 The part about RVO was really concerned with the out() scenario, not
 in_out(). I'm not sure if passing a smart pointer buys you very much. In
 this case, the smart pointer is const but the pointee is not, so the const
 in the signature is really just masking what is going on.

You're right.  I see your point.

At first I thought that if there were an easy way to convert smart_ptr
T  to smart_ptr T const  there'd be no problem.  But then I realized
this would bring about the expensive copy again.

IMHO, the solution to this dilemna is to use the de facto standard way
of using references like you said earlier:

  void f( T value_may_change_, T const value_may_not_change_ );

Noel
-- 
NOTICE: If received in error, please destroy and notify sender.  Sender
does not waive confidentiality or privilege, and use is prohibited.
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: class proposal

[Noel Yap]

Justin M. Lewis wrote:
 
 I diagree with this.  The code I've written using this looks more like
 
 void add_char( in_outstd::string str, char ch)
 {
   std::string s = str;
   s += ch;
 }

I think you're assuming everyone will code the way you want.  If you're
going to force everyone to code this way, why not just have them code
like:

  void add_char( std::string str_, char ch_ )
  {
str += ch;
  }

  int len( std::string const str )
  {
return str.length();
  }

What is the added value of the proposed class?  It's not that it forces
people to change the value if it's used:

  int len( in_out std::string  str )
  {
return static_cast std::string ( str ).length();
  }

Noel
-- 
NOTICE: If received in error, please destroy and notify sender.  Sender
does not waive confidentiality or privilege, and use is prohibited.
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: class proposal

[Justin M. Lewis]

Everyone is ignoring the possibility of objects that can't be copied in
this, too.  Some objects intentionally hide their operator =, making
returning it from a function impossible.

And, I think a lot of people are missing a big part of the point here.  You
can enforce the use of making it explicit at the point of invocation that
the param is changing.  The compiler will give an error if a c_out or
c_in_out object isn't passed.  You can't enforce a naming convention or
commenting at the point of invocation, at least not everywhere, like where I
work.  So, by writing a function using these objects, it's a guarantee that
anyone who uses my functions has to make it explicit what the effect of
calling my functions is.



- Original Message -
From: Noel Yap [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Thursday, April 24, 2003 4:13 AM
Subject: Re: [boost] Re: class proposal


 Justin M. Lewis wrote:
 
  in/out seems to be used fairly commonly in COM.  I'm not sure I have any
  great examples off the top of my head, but I know they're commonly used.

 I'm not a COM person, but I believe it's written in C.  If so, then you
 are correct that in/out parameters are more needed since noone would
 want to create a struct for each multiple return type.

 OTOH, C++ has templates to deal with this situation (ie boost::tuple)
 so, qualifying my previous statement, in C++ I still see no need for
 in/out parameters.

  And using pointers is part of what we're trying to avoid here.  Like I
said,
  I avoid using pointers whenever possible at this point.

 I'm a little confused.  Either you pass in the entire object or you pass
 in a pointer (even if it's wrapped in another class).  How is this new
 class supposed to be implemented?

  And, again, the real intent here is to insure clarity at the point of
  invocation.  In my case I'm looking at 100's of thousands of lines of
code,
  written over the past 8 years.  It's tiresome trying to chase down where
  values COULD have changed.  In this setup you KNOW exactly what calls
are
  changing parameter values, and it's enforced.  As long as the library
calls
  use the c_out and c_in_out classes people using the library are forced
to
  conform to the format.  So, 8 years, and a few million lines of code
later,
  no one will wonder what might cause a variable they're tracking to
change
  values.

 I think if parameters are used for in parameters only and return values
 are used for out parameters only, the same thing is achieved.  For
 example,

   inOutValue = square( inOutValue );

 vs (using an extension for generality):

   square( c_in_out typeof( inOutValue ) ( inOutValue ) );

 Noel
 ___
 Unsubscribe  other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Sorting list shared_ptr foo usingstd::list::sort()

[Heath Davis]

Bravo!!! This is a truly novel approach!  I agree that the 
shared_ptr::operator is meaningless.  If boost wishes to claim STL 
compatibility, container functions should be allowed to operate directly 
on the base level objects, rendering smart pointers completely 
transparent.  Proper functionality would then be defined as:

The order of any given STL container will be predictable and definite 
following any given STL container operation. The resulting order of an 
operation against any std::some_container  object  would then be 
identical to the resulting order of the same operation against 
std::some_container  boost::some_smart_pointer  object  .  No 
special preparation will be required on behalf of object beyond that of 
being directly containable by STL.  Otherwise stated, if object works 
correctly in STL containers, nothing intrusive must be done to object to 
make it compatible with boost, nor will any exteral helper functions 
be required to make boost::some_smart_pointer transparent.

If your sortable_ptr class brings boost in that direction, then I thank 
you for addressing this issue.

I have experienced some difficulty with sorting lists of type:

list  shared_ptr  foo  

For a while I have been toying with the idea of a smart pointer called 
sortable_ptr, which would behave in the way that [I believe that] the 
original poster erroneously presumed that boost::shared_ptr already did. 
 I was originally planning to do some more practical testing of the 
concept before possibly submitting it as a proposal to Boost, but since 
the topic has now been raised, I will take the opportunity to get some 
feedback as to whether the idea is sound, or if I have missed something 
crucial.

The following is an extract from the draft documentation I have been 
writing.

- - - -

The class sortable_ptr is publicly derived from boost::shared_ptr, but 
defines the comparison operator  (and its siblings , =, and = ) to 
make a comparison of the actual objects.  This means that if the class 
myclass has operator defined, we can write

sortable_ptrmyclass aptr(new myclass(/* Something */));
sortable_ptrmyclass bptr(new myclass(/* Something else*/));
assert((aptr  bptr) == (*aptr  *bptr));
This is different from boost::shared_ptr, which does only define the  
operator to do a direct comparison of the pointers themselves (or 
something to that effect).

The == and != operators retain the semantics that they inherited from 
boost::shared_ptr, which is to test the pointers themselves for 
identity.  This means that even if neither aptr  bptr nor aptr  bptr 
is true for two sortable_ptr pointers, the expression aptr == bptr may 
or may not be true.  If it is true this will mean that both aptr and 
bptr refer to the same myclass object, which of course is neither less 
than or greater than itself.  If the expression aptr == bptr is false, 
it will mean that aptr and bptr point at different objects that are 
equivalent as to their sort order.

What is the advantage of this?

Before answering that question, we note that we have at leas not done 
anything illegal by introducing these definitions.  Neither 
boost::shared_ptr nor sortable_ptr support the notion of pointer 
arithmetic, so we do not need the  operator to be defined in any 
particular way for that purpose.

We can still store sortable_ptr pointers in any of the sequence 
containers in the Standard Template Library, since these only demand 
that the == operator tests for proper identity between the objects that 
are being stored in the list or deque or vector, which it does.
The sort algorithms in STL use the  operator of the objects in the 
container by default, so if we sort a container of sortable_ptr 
pointers, they will appear in the same order as the objects themselves 
would have been sorted.  For vectors and deques it can be considerably 
faster to sort pointers rather than the objects themselves, since the 
generic sort algorithms work by swapping the items in the container, and 
it can be much faster to swap two small pointers than to swap two big 
and complex objects.

For the associative containers set, multiset, map, and multimap, the 
default is to use the  operator of the objects that are stored in the 
container to define equivalence and sort order, which is exactly what we 
want.  When we store sortable_ptr pointers in an associative container, 
the pointers will be sorted in the same order as the actual objects 
would have been if we had stored them directly in a corresponding 
associative container for objects.  The definition of operator ensures 
that any two sortable_ptr pointers are equivalent if, and only if, the 
two underlying objects are equivalent, so for sets and maps, which 
cannot hold more than one object with equivalent keys, it will be the 
same objects that are represented in the container whether the objects 
are stored directly or via sortable_ptr pointers.

- - - -

The draft implementation looks like this at the moment:

[boost] bugs in boost progress_timer?

[Robin.Hu]

hi boosters:

   I just found that boost::progress_timer behaviors different from
win32 to posix. This is because the clock function's return is not same
on these two platformes. Do you all think this is a bug, or a intented
featuer?

man 3 clock

DESCRIPTION
 The clock() function determines the amount of processor time used since
   ~~
 the invocation of the calling process, measured in CLOCKS_PER_SECs of a
 second.

MSDN April 2003

 Calculates the wall-clock time used by the calling process.
   ~~~
 clock_t clock( void );

-- 
 [EMAIL PROTECTED]

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost