Re: [boost] Re: resource manager naming

[Joel de Guzman]

Terje Slettebø wrote:
>> From: "Joel de Guzman" <[EMAIL PROTECTED]>
>
>> Dave Gomboc wrote:
> So then reverse resource_manager and get managed_resource<>, or
> just managed<>.

 Why not just resource<>? Management is implied anyway; that's the
 reason for the existence of the class.
>>>
>>> *laugh*  I was thinking exactly the opposite.  To me, the resource
>>> itself
>>> is clear from the template parameter -- it's the management that
>>> needs to
>>> be indicated.
>>>
>>> +1 for managed<>.
>>
>> What template parameter? That's not a part of the name.
>> Template parameters, just like function arguments are never
>> a part of the name. You do not need to read the header file
>> to get the essence. The name itself should indicate the function
>> of the class without looking elsewhere.
>>
>> managed<>? What is managed? ... answer: take a look at
>> the template parameter and you'll see what I mean. I'm
>> sorry, that doesn't make sense.
>
> managed
> managed // Smart pointer
>
> resource
> resource // Smart pointer
>
> When the template is in use (unless it uses a default template
> argument),
> the template argument will be part of the signature, and therefore
> show what is managed. Therefore, I think managed<> makes sense, too.
>
> IIUC, your argument can be used for e.g. std::pair, too. std::pair<>
> of
> what? Answer: That depends on the template arguments.

No, a pair is always a pair regardless of what the composed types are:

pair // a pair comprised of T1 and T2

You don't need to know the template parameters to know that it
is a *pair*. That's the big difference. The template parameter is an abstract
concept. Detached from the parameters, it is still a pair. The same does not
hold for managed. What is "managed"? It is not even a noun without the
qualifiers.

managed // does this *manage* the actual rendering into the window?

Gotcha! No it doesn't! OTOH:

resource // ah yes, widget is a resource. we want to manage the resource

--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net




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

Re: [boost] Re: resource manager naming

[Terje Slettebø]

>From: "Joel de Guzman" <[EMAIL PROTECTED]>

> Dave Gomboc wrote:
> >>> So then reverse resource_manager and get managed_resource<>, or just
> >>> managed<>.
> >>
> >> Why not just resource<>? Management is implied anyway; that's the
> >> reason for the existence of the class.
> >
> > *laugh*  I was thinking exactly the opposite.  To me, the resource
> > itself
> > is clear from the template parameter -- it's the management that
> > needs to
> > be indicated.
> >
> > +1 for managed<>.
>
> What template parameter? That's not a part of the name.
> Template parameters, just like function arguments are never
> a part of the name. You do not need to read the header file
> to get the essence. The name itself should indicate the function
> of the class without looking elsewhere.
>
> managed<>? What is managed? ... answer: take a look at
> the template parameter and you'll see what I mean. I'm
> sorry, that doesn't make sense.

managed
managed // Smart pointer

resource
resource // Smart pointer

When the template is in use (unless it uses a default template argument),
the template argument will be part of the signature, and therefore show what
is managed. Therefore, I think managed<> makes sense, too.

IIUC, your argument can be used for e.g. std::pair, too. std::pair<> of
what? Answer: That depends on the template arguments.


Regards,

Terje

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

Re: [boost] Re: resource manager naming

[Joel de Guzman]

Dave Gomboc wrote:
>>> So then reverse resource_manager and get managed_resource<>, or just
>>> managed<>.
>> 
>> Why not just resource<>? Management is implied anyway; that's the
>> reason for the existence of the class.
> 
> *laugh*  I was thinking exactly the opposite.  To me, the resource
> itself 
> is clear from the template parameter -- it's the management that
> needs to 
> be indicated.
> 
> +1 for managed<>.

What template parameter? That's not a part of the name. 
Template parameters, just like function arguments are never
a part of the name. You do not need to read the header file
to get the essence. The name itself should indicate the function
of the class without looking elsewhere.

managed<>? What is managed? ... answer: take a look at
the template parameter and you'll see what I mean. I'm
sorry, that doesn't make sense.

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net

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

[boost] Re: resource manager naming

[Dave Gomboc]

> > So then reverse resource_manager and get managed_resource<>, or just
> > managed<>.
> 
> Why not just resource<>? Management is implied anyway; that's the
> reason for the existence of the class.

*laugh*  I was thinking exactly the opposite.  To me, the resource itself
is clear from the template parameter -- it's the management that needs to
be indicated.

+1 for managed<>.

Dave

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

Re: [boost] Re: Is there any Interest in a Fixed Point Library?

[Kevin Atkinson]

On Thu, 27 Feb 2003, Jason House wrote:

> Kevin Atkinson wrote:
> > 
> > On Thu, 27 Feb 2003, Jason House wrote:
> > > One thought... It looks like the template parameter should be an integer
> > > type (of course, right?)...   I think that there is some way to cause a
> > > non integer type to generate a compiler error.  Of course, considering
> > > other types might have some value (ie. complex numbers, a double that
> > > overflows due to adding of large numbers?, and probably others that
> > > don't come to mind at the moment)
> > 
> > Be careful that you are not overly restrictive.  For example what about a
> > class that supports very large integers.  What about a class that is a
> > wrapper around an integers, such as one that is designed  to guarantee
> > atomic operations, etc...
> 
>   I unfortunately am not familiar enough with all the aspects of boost
> (yet ).  I believe there is a type traits library, which in general
> is used for determining fundamental characteristics of template
> parameters that are passed in.  If such an animal as "integer
> compatible" is there, I suspect that new class implementations such as
> large integers are somewhat obligated to ensure that their type traits
> come out correct...
>   One thing is for sure, if someone tried to get clever and extend the
> large number support of their float/double (at the sacrifice of small
> number support), the code, as is, won't even come close to working
> properly.
>   All I was going for was that there is only a subset of types that
> would work, and I believe that boost has some resources for dealing with
> that.  I personally am not familiar enough with them i order to give a
> clearer prescription...  A couple of my comments earlier were in the
> hope that somebody else would pick up the thought and run with it
> further...

OK well I think guaranteeing a true integer like behavior would be tricky.

> > Yes a check would be useful.  I think an assert to check the the shift
> > size is not equal to or larger than the integer it is shifting in bits
> > would work.  But what about an variable length integer class where the
> > sizeof() operator won't work?
> 
> Well, sizeof() definitely won't work for anything other than the most
> basic types.  A integer complex number class won't support sizeof()*8
> won't work either.  Something like the following:
> 
> template < T >
> shift_bounds_check{int x}{};
> 
> template< int >
> shift_bounds_check(int x){
>   x = x<0?-x:x;
>   assert (x }
> 
> /* more specializaions here */
> 
> Would allow at least some support for a check.  
> There's probably a better way than what I wrote though...

Yes that would work.

Also you keep talking about an integer complex class.  However 
FixedPoint > doesn't really make sense.  
Complex > does however.  It would be even more useful to 
allow the real and imaginary parts to be of a different EXP.

> > Also, please not that It IS possible to have a fixed point number with the
> > radix larger or smaller than the size of the integer in bits.  You just
> > have to be careful.  Some of my methods (like the frac one) also need to
> > be written more carefully.
> 
> I agree that when the radix goes to either extreme, caution is
> necessary.  It is good to avoid problems due to internal implementation
> and NOT even alert the user...  A lot of the problems can probably be
> caught at compile time (and the rest at run time).  The worst is when
> something compiles without error/warning and runs without
> error/warning... and everything looks good except for the output...

I defiantly agree with you here.

> > > (Although, the conversion to double and back probably allows for the
> > > fixed point number to be used as a floating point number, and just cause
> > > higher math operations to operate on doubles, and then convert back.
> > > I believe that the code fragment "x = sqrt(x)" would compile fine.)
> > 
> > Yes, that would work.  But if your goal is to avoid floating point math
> > for speed (for a processor that doesn't have a FPU) than fixed point math
> > functions would be useful.  Of course the software emulation for the
> > floating point version of the math function may be just as fast.  I really
> > don't know.
> 
>   Well, I agree that in some environments, such functionality might not
> exist, but on those where it does exist, a fixed point library can still
> be useful.  It would be a shame to not use fixed point simply because
> there's no way to perform a  square root or a sine... even if they are
> called OUTSIDE a double nested loop or something...  It would also be a
> shame to have to code in a special work around to force use of
> float/double for the one specific call, and then convert the rest to
> fixed point...  

I wasn't trying to imply that it shouldn't be done.  Just that my class as 
is, is of limited usefulness for serious fixed point work when the goal 
is to avoid floating point for performance reasons.

> > > I think op

[boost] Re: [optional] Polymorphism

[David B. Held]

"Fernando Cacciola" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...]
> You would like to be dealing with:
>
> optional* and optional*

Yes, exactly.

> but you can do this as well, so I figure that what you really
> need is a 'dynamic-type preserving' conversion between these
> optionals. Something that would allow the following:
>
> D dval ;
> optional dopt(dval);
> optional bopt ( optional_cast(dopt) ) ;
> optional dopt2 ( optional_cast(bopt) ) ;
>
> assert ( dval == *dopt2);
>
> Is this what you need?

No, not at all.  What I really need is this:

intrusive_ptr > p(new optional);

I'd like to be able to store a map or vector of ptr>
and have it work polymorphically for B or D.

> If it is, I'm afraid it's not possible:
>
> The problem is that even though the conversion will succeed
> (it would probably work with the current optional as it is now),
> it will inevitably _slice_.

Yes, I realize that.  I don't expect optional to do anything magical.
But it would be nice if there were a way for wrappers to preserve
(or "inherit" ;) polymorphic attributes.  I imagine there are other
places where this is desirable, so it's too bad that there isn't a
mechanism in the language.  I wouldn't even know what kind of
thing to propose, however.  The problem is that optional (and
other similar wrappers) don't use value semantics to aggregate
the polymorphic type, or else it could just inherit from it.  So how
to specify that a wrapper type should mirror a polymorphic
hierarchy is something of a trick, but I hope it's obvious that it
is useful, and perhaps should be possible.

> [...]
> I think that a solution which uses the PolyOptional technique
> is the only way to go.
> [...]

That looks to be the case.  Thanks for the comments, though.

Dave



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

[boost] Re: [optional] Polymorphism

[Fernando Cacciola]

"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
>
> "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> [...]
>
> > int main()
> > {
> > optional b;
> > optional c;
> >
> > foo(b);
> > //foo(c);
> > }
>
> BTW implicit cast to reference types are not implicit under GCC, they have
> to be called explicitly.

Yes, this is the conformant behaviour AFAIK

>Template casts do not seem to be defined in the
> standard...:
>
> template 
> struct optional
> {
> template 
> operator optional const & () const
> {
> return * reinterpret_cast const
*>(static_cast const *>(reinterpret_cast(storage_)));
> }
>
> ...
>  };
>
This is seriously wrong:

(a) reinrepret_cast<> has implementation-defined behaviour,
which means that is totally useless in portable code.

(b) you don't need reinterpret_cast<> to obtain a 'T const*'
from the aligned_storage whithin the optional: look at the optional code.

(c) EXTREMELY WRONG: you're converting a pointer to aligned_storage<>
into a pointer to optional<>, !!! but aligned_storage is a _data_member_
of optional!!!


> inline void foo(optional const &)
> {
> }
>
> int main()
> {
> optional b;
>
> //foo(b);
> foo(b.template operator optional const &  ());
> }
>
>
> Also, the advantage of casts to reference types is that they do not create
> any temporary objects implicitly.
>
But does not create a new objet either!
A conversion is REQUIRED to give a NEW OBJECT,
otherwise there's no conversion at all: since the object remains exactly
the same, you just BROKE the type system by binding a reference of a
completely unrelated type to the same object.
The only case when you can do something _similar_, that is, when
you can't do a _convertion_ but you can do a _cast_, is when the
reference type (or pointer type, for that matter) is of the type of a
non-ambiguous accesible base-class subobject
(because the object dynamic type is covariant with the
reference/pointer static-type).

>
> I do not see in what it can be dangerous.
>
I do :-)
And I see the danger in reinterpret_cast<>; stay away from it.

>
> What do you think?
>
Please, read my original response to David Held and look carefully at
the optional implementation.
As I said, you could only get half away with such a _conversion_ if you
purposedly _slice_ the U subobject out of a T object
(if U is in fact a subobject of T), and wrap it into a NEW optional.
But you can't go back to a T, so this is not polymorphism, is straight up
conversion, just like converting a long double to a short loosing
along the way all the bits that don't fit.

Fernando Cacciola




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

RE: [boost] Is there any Interest in a Fixed Point Library?

[Kevin Atkinson]

On Thu, 27 Feb 2003, Paul A. Bristow wrote:

> Yes - this looks potentially rather useful for some tasks, especially embedded
> systems.
> Why on earth didn't the language include fixed point and/or fractional types?

Well in order for fractions to be really useful, that is to support exact
values for basic arithmetic, you would also need a arbitrary size integer
class as the numerator and denominator can get very large very fast unless
the fraction is automatically reduces after each operation and even than
the numbers can get big.

> As you observe, the increased accuracy compared to float (just a little too
> small for some measurements like weights) but with half the memory of double,
> and of course the integer/binary nature are sometimes useful.

I am curious why you say a float is "just a little tool small for some 
measurements like weights".  I have always used doubles, but I never put 
much thought into it.

> Do you have any test programs?
> 
> Have you made any comparison with float and double speeds?

No.  However in general fixed point math is comparable to speed to 
floating point math on systems with a good FPU.  However, you might gain 
some speed when most operations or integer based and a floating point 
number is only used occasionally (say for taking an average) as you would 
save cycles on the conversion from an int to a floating point number.

Of course, fixed point is extremely useful on FPU less systems and the 
speed up will be substantial.  However, my library lacks fixed point 
versions of the basic math functions (sqrt, exp, sin, etc...), making it 
of limited usefulness speed wise on a FPU less system.  If someone knows 
of a C library that provided these routines I might consider porting it.

Also, When using fixed point math you might lose some precision (if going
from a double to a 32 bit fixed point number as a 64 bit would be too
slow).

> 
> HTH to encourage you.
> 
> Paul
> 

--- 
http://kevin.atkinson.dhs.org

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

Re: [boost] Re: resource manager naming

[Joel de Guzman]

Brian Gray wrote:
> On Thursday, February 27, 2003, at 09:15 AM, David Abrahams wrote:
>> "Sam Partington" <[EMAIL PROTECTED]> writes:
>> 
>>> Could it not just be called shared.  After all it is merely a more
>>> general
>>> term of shared_ptr.  And the type of the resource kind of makes it
>>> implicit.
>> 
>> std::auto_ptr is a non-shared resource manager.
> 
> So then reverse resource_manager and get managed_resource<>, or just
> managed<>.

Why not just resource<>? Management is implied anyway; that's the reason
for the existence of the class.

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net

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

Re: [boost] Re: Borland C++ Builder patch 4 released

[Samuel Krempp]

On Thu, 2003-02-27 at 13:58, Alisdair Meredith wrote:
> [Could make config testing interesting if 0x0563 has fixes not present
> in the Kylix release, 0x0570]

indeed.
I guess it's the first time, thanks to Borland's 2 branches (kylix /
Borland C++ Builder) using intertwined version numbers, that one
compiler's version number does not simply follow chronological order
(thus, presumably, increasing standard conformance)
The compiler-specific non-conformance workarounds with version tracking
nightmare is getting an extra bit of insanity..


BTW, I think kylix, alias __BORLANDC__ = 0x570, was already behind BCB
0x562 on some issues,  was it not ?


-- 
Samuel

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

[boost] boost::any_cast<>

[Noel Yap]

I'm using boost::any until boost::variant is out.

My question is about the syntax of boost::any_cast.  Why does the follow
not work:
  return *boost::any_cast< double* >(
&_attributeMap[ "securitized-balance" ] ) ;

while the following does:
  return *boost::any_cast< double >(
&_attributeMap[ "securitized-balance" ] ) ;

IMHO, it would be more consistent with the existing casting operators
for the user to have to explicitly say the full type (eg double* )
rather than the casting operator implicitly knowing the type.

Thanks,
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: Glitch with mpl::placeholder(s)?

[Andreas Huber]

"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Andreas,
>
> Aleksey just did a big round of renaming before the first official
> release of MPL (including changes like int_c -> int_, and placeholder
> -> placeholders); I believe that placeholder.hpp is obsolete and
> should have been removed from CVS.  In this case we could keep it for
> backwards-compatibility reasons, but in general that was deemed a bad
> idea for most names.

Ok, then I believe it's better to completely remove placeholder.hpp from
CVS.

Thanks,

Andreas


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

[boost] Stats - smallish points

[Matt Hurd]

I see in the Wiki a couple of comments about variance/std dev with n and n-1
being referred to at the denominator.  Just to clear it up:

when it is a complete population the denominator should be n.
when it is a random sample it is n-1.

sample variance = sum(Xi - mean(X))^2/(n-1)

or more usefully = (n*sum(Xi^2))-sum(Xi)^2
__
 n(n-1)

For those of you with MS Excel you will see both supported.


I note the idea of using accumulators for the various sums to determine
stats in the Wiki.

I would like to see this idea extended...

I think a noble goal would be to accumulate sums over populations in
collection or sliding windows of sequences but only those sums you need.
Like AOP this would be best if done generatively.  That is, don't generate
sum(X^2) if you only need a mean.  Have state to generate max and min if
needed.


Another noble goal would be to harness the power of incremental
calculations:

The simple case is a mean:
- This is generated from sum(X)
- add X to the old sum(X) for a collection
- for a window on a sequence, take the old X off and put the new X on

This seems trivial but adds much more power for calcs, especially windows.

Say you have a one variable linear regression over a window, typically you
would use a library function to calc the stats and it would be O(n).  If the
state were accumulated incrementally, then the first window is O(n) and
moving the window a point is O(1).

Say over 10 years of typical data you have 2500 points you are doing a
year's window, 250 points.  Using the usual way, calling a library function,
you get, if you pardon my abuse of the notation, O(250 * 2500) or of order
625,000.  If you do it incrementally, you get of order of 250 + 2500*1 =
2750 calcs which is a 227 times speed up or 4.4% of the calc.

Interestingly, this can also apply to things like min and max over a window
where you see if the point rolling off is the min or max, if not then you
only have to compare the current min, max to the new point, otherwise you
have to scan...

This is just finite differencing...  just like Bresenham's line algorithm.

You sometimes see such incremental approaches in some FORTRAN stats
libraries, but not as often as you should.  Also, users often ignore them
anyway as they are typically conditioned to call the regression or whatever.

Below is some code I wrote to do this with an MS compiler before templates
was supported to illustrate the incremental case.  This code is oriented to
timeseries of numbers being treated as "streams" for a market trading
application.  Please excuse the old historic ugliness...

Now, the idea is to translate such concepts into vogue C++ with policies
etal ;-)


Regards,

matt.


___

Using a NR call
Non-incremental
___

void FunctorLineFit::evaluate(Offset day) {
  Offset order = Offset(parameter(0));

  float *x = floatVectorGet(day,order,0);
  float *y = floatVectorGet(day,order,1);
  float a,b,siga,sigb,chi2,q;

  fit(x-1,y-1, (int) order, NULL, 0, &a,&b,&siga,&sigb,&chi2,&q);
  setResult(day,0,PriceType(a));
  setResult(day,1,(PriceType)b);
  setResult(day,2,(PriceType)siga);
  setResult(day,3,(PriceType)sigb);
  setResult(day,4,(PriceType)chi2);

  floatVectorRelease(x,0);
  floatVectorRelease(y,1);
} // FunctorLineFit

__

Using incremental calc
__

class FunctorLineFitSeriesIncremental : public FunctorStored {


  RWDECLARE_COLLECTABLE(FunctorLineFitSeriesIncremental)

  public:
virtual Offset waste() const { return Offset(parameter(0)); };
virtual void evaluate(Offset j);

  private:
virtual void setPrivate();
PriceType
n,n2,n3,sumX,sumXX,a1,a2,b1,b2,np1,syx1,syx2,syx3,syx4,seny1,r21,ar21,pb1,pb
2,pb3;
Offset intN;

};

void FunctorLineFitSeriesIncremental::evaluate(Offset day) {
  assert(invariant());

  Offset counter;

  PriceType sumY, sumYY, sumXY;
  PriceType a,b,yx,syx,seny,r2,ar2,pb,yxLow, yxHigh;
  PriceType oldY, newY, oldXY, newXY;
  PriceType sumY2, syxTemp, r2Temp, t, t2;
  PriceType temp;

  // This code relies on the left to right conditional evaluation of &&
  if (day>0 && cached(day-1)) {
// Use tomorrow's data to calculate today.
oldY = datum(day-1,0);
newY = datum(day+intN-1,0);

sumY = value(day-1,10) - oldY + newY;
sumYY = value(day-1,11) - oldY*oldY + newY*newY;

oldXY = n*oldY;
newXY = sumY;
sumXY = value(day-1,12) - oldXY + newXY;


  } else if (day0 && cached(day-1)) {
// Use tomorrow's data to calculate today.
oldX = datum(day-1,0);
newX = datum(day+n-1,0);

oldXbottom = oldX;
newXbottom = datum(day+lag-1,0);

oldXtop = datum(day-1+n-lag,0);
newXtop = newX;

oldXXlag = oldX*datum(day-1+lag,0);
newXXlag = datum(day+n-lag-1,0)*newX;

sumX = value(day-1

[boost] Re: resource manager naming

[Jason House]

managed_copy?

How about an abbreviated name?  
Like rsrc_mgr?  Although, I don't like that abbreviation for resource...

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

Re: [boost] Glitch with mpl::placeholder(s)?

[David Abrahams]

Hi Andreas,

Aleksey just did a big round of renaming before the first official
release of MPL (including changes like int_c -> int_, and placeholder
-> placeholders); I believe that placeholder.hpp is obsolete and
should have been removed from CVS.  In this case we could keep it for
backwards-compatibility reasons, but in general that was deemed a bad
idea for most names.

"Andreas Huber" <[EMAIL PROTECTED]> writes:

> Hi Aleksey
>
> I have got mpl out of CVS 5 minutes ago.
> Code that previously compiled fine now shows the following error:
>
> d:\Data\boostCvsRoot\boost\boost\mpl\aux_\include_preprocessed.hpp(27) :
> fatal error C1083: Cannot open include file:
> 'boost/mpl/aux_/preprocessed/msvc70/placeholder.hpp': No such file or
> directory
>
> MPL can be fixed as follows:
>
> diff -r1.5 placeholder.hpp
> 33c33
> < #   define BOOST_MPL_PREPROCESSED_HEADER placeholder.hpp
> ---
>> #   define BOOST_MPL_PREPROCESSED_HEADER placeholders.hpp
>
>
> OR users can fix their code by replacing
>
> #include 
>
> with
>
> #include 
>
> and
>
> mpl::placeholder;
>
> with
>
> mpl::placeholders;
>
> Regards,
>
> Andreas
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

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

[boost] Re: Is there any Interest in a Fixed Point Library?

[Jason House]

Kevin Atkinson wrote:
> 
> On Thu, 27 Feb 2003, Jason House wrote:
> > One thought... It looks like the template parameter should be an integer
> > type (of course, right?)...   I think that there is some way to cause a
> > non integer type to generate a compiler error.  Of course, considering
> > other types might have some value (ie. complex numbers, a double that
> > overflows due to adding of large numbers?, and probably others that
> > don't come to mind at the moment)
> 
> Be careful that you are not overly restrictive.  For example what about a
> class that supports very large integers.  What about a class that is a
> wrapper around an integers, such as one that is designed  to guarantee
> atomic operations, etc...

  I unfortunately am not familiar enough with all the aspects of boost
(yet ).  I believe there is a type traits library, which in general
is used for determining fundamental characteristics of template
parameters that are passed in.  If such an animal as "integer
compatible" is there, I suspect that new class implementations such as
large integers are somewhat obligated to ensure that their type traits
come out correct...
  One thing is for sure, if someone tried to get clever and extend the
large number support of their float/double (at the sacrifice of small
number support), the code, as is, won't even come close to working
properly.
  All I was going for was that there is only a subset of types that
would work, and I believe that boost has some resources for dealing with
that.  I personally am not familiar enough with them i order to give a
clearer prescription...  A couple of my comments earlier were in the
hope that somebody else would pick up the thought and run with it
further...


> > The problem I had was that a case of shifting by
> > 32 bits logically come up in my code... instead of clearing the number,
> > it gave me the original number back!
> >
> > I would have to assume that there is some kind of type trait that would
> > help with enabling some kind of error check.  Even if it is just some
> > kind of assert.  The fixed point to fixed point conversion is the most
> > likely candidate for hitting this kind of a bug.  A base of 20 converted
> > to a base of -15 would have a shift by 35...  (in effect, on my
> > compiler/processor, that would only shift by 3)
> 
> Yes a check would be useful.  I think an assert to check the the shift
> size is not equal to or larger than the integer it is shifting in bits
> would work.  But what about an variable length integer class where the
> sizeof() operator won't work?


Well, sizeof() definitely won't work for anything other than the most
basic types.  A integer complex number class won't support sizeof()*8
won't work either.  Something like the following:

template < T >
shift_bounds_check{int x}{};

template< int >
shift_bounds_check(int x){
  x = x<0?-x:x;
  assert (x Also, please not that It IS possible to have a fixed point number with the
> radix larger or smaller than the size of the integer in bits.  You just
> have to be careful.  Some of my methods (like the frac one) also need to
> be written more carefully.


I agree that when the radix goes to either extreme, caution is
necessary.  It is good to avoid problems due to internal implementation
and NOT even alert the user...  A lot of the problems can probably be
caught at compile time (and the rest at run time).  The worst is when
something compiles without error/warning and runs without
error/warning... and everything looks good except for the output...

> > (Although, the conversion to double and back probably allows for the
> > fixed point number to be used as a floating point number, and just cause
> > higher math operations to operate on doubles, and then convert back.
> > I believe that the code fragment "x = sqrt(x)" would compile fine.)
> 
> Yes, that would work.  But if your goal is to avoid floating point math
> for speed (for a processor that doesn't have a FPU) than fixed point math
> functions would be useful.  Of course the software emulation for the
> floating point version of the math function may be just as fast.  I really
> don't know.


  Well, I agree that in some environments, such functionality might not
exist, but on those where it does exist, a fixed point library can still
be useful.  It would be a shame to not use fixed point simply because
there's no way to perform a  square root or a sine... even if they are
called OUTSIDE a double nested loop or something...  It would also be a
shame to have to code in a special work around to force use of
float/double for the one specific call, and then convert the rest to
fixed point...  
  It's just nice that the back door is there.  How much it gets used is
another story.


> > I think operators like += -= etc... would also be nice... they could
> > actually be written to accept all bases, and possible be specialized for
> > the same base...
> 
> Yes, I agree.  I just haven't written them.  Also currently

[boost] Glitch with mpl::placeholder(s)?

[Andreas Huber]

Hi Aleksey

I have got mpl out of CVS 5 minutes ago.
Code that previously compiled fine now shows the following error:

d:\Data\boostCvsRoot\boost\boost\mpl\aux_\include_preprocessed.hpp(27) :
fatal error C1083: Cannot open include file:
'boost/mpl/aux_/preprocessed/msvc70/placeholder.hpp': No such file or
directory

MPL can be fixed as follows:

diff -r1.5 placeholder.hpp
33c33
< #   define BOOST_MPL_PREPROCESSED_HEADER placeholder.hpp
---
> #   define BOOST_MPL_PREPROCESSED_HEADER placeholders.hpp


OR users can fix their code by replacing

#include 

with

#include 

and

mpl::placeholder;

with

mpl::placeholders;

Regards,

Andreas


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

RE: [boost] Re: resource manager naming

[Matt Hurd]

> -Original Message-
> Behalf Of Alisdair Meredith
> Subject: [boost] Re: resource manager naming
> 
> Larry Evans wrote:
> 
> > Would the GOF name, proxy, be too non-specific?  Policy names 
> might provide
> > the specifics (whether it's a pointer or a resource).
> 
> Proxy, if anything, sends the wrong message to me.  The name suggests
> 'reference', rather then 'owner'
> 
> 'bookkeeper' is the best I can come up with so far, but that is a very
> odd word to type  and still too long.

bookkeeper makes me think:

keep  - it's mine
  - the inner sanctum of the castle
- short and unconfusing to me

$0.02

matt.


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

[boost] Formal Review I/O Library Extended

[Thomas Witt]

Hi, 

To make up for the schedule problems the formal review for I/O is extended 
until March 11th. So there is no need to hurry for those willing finish their 
variant review first.

As said before the variant review is still open until March 2nd.

Thomas
Boost Review Wizard

-- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de

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

RE: [boost] Is there any Interest in a Fixed Point Library?

[Paul A. Bristow]

Yes - this looks potentially rather useful for some tasks, especially embedded
systems.
Why on earth didn't the language include fixed point and/or fractional types?

As you observe, the increased accuracy compared to float (just a little too
small for some measurements like weights) but with half the memory of double,
and of course the integer/binary nature are sometimes useful.

Do you have any test programs?

Have you made any comparison with float and double speeds?

HTH to encourage you.

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]


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Kevin Atkinson
> Sent: Thursday, February 27, 2003 2:29 AM
> To: Boost mailing list
> Subject: [boost] Is there any Interest in a Fixed Point Library?
>
>
>
> Is there any interest in a fixed point math library.  Using templates the
> compiler can keep track of the radix point for you making using fixed
> point math a lot less tedious and error prone.
>
> Attached is a rudimentary implementation which would work acceptably when
> the exponent is not too large or too small.  If the exponent is smaller or
> larger than the size of the underlying integer in bits this code will
> likely behave badly.
>
> I plan to use the attached code to avoid having to deal with serializing
> floating point numbers.  A exponent of -30 (-31 if using an unsigned 32
> bit integer) is especially useful for representing numbers between 0 and
> 1.  The precision will actually be a bit better than a 32 bit float since
> the exponent does not have to be stored.
>
> Comments on the code welcome.  I am not a numerical analysis specialist so
> don't expect me to write a fixed point library for anything beyond simple
> arithmetic.
>
> --
> http://kevin.atkinson.dhs.org
>

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

Re: [boost] newsgroup

[Blue, Reginald V]

"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Noel Yap <[EMAIL PROTECTED]> writes:
> 
> > The news group advertised on the site,
> > news.gmane.org/gmane.comp.lib.boost.devel, gives no response.  Has it
> > moved?
> 
> Works for me.  Your post appears there.
> 
> news://news.gmane.org/gmane.comp.lib.boost.devel

It doesn't for me, but that's because I'm behind a firewall that blocks it.
Perhaps that's the OP's problem as well?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: resource manager naming

[Brian Gray]

On Thursday, February 27, 2003, at 09:15 AM, David Abrahams wrote:
"Sam Partington" <[EMAIL PROTECTED]> writes:

Could it not just be called shared.  After all it is merely a more 
general
term of shared_ptr.  And the type of the resource kind of makes it 
implicit.
std::auto_ptr is a non-shared resource manager.
So then reverse resource_manager and get managed_resource<>, or just 
managed<>.

 -- Brian

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

Re: [boost] Re: resource manager naming

[David Abrahams]

"Sam Partington" <[EMAIL PROTECTED]> writes:

> Could it not just be called shared.  After all it is merely a more general
> term of shared_ptr.  And the type of the resource kind of makes it implicit.

std::auto_ptr is a non-shared resource manager.

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

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

Re: [boost] Re: resource manager naming

[Sam Partington]

Could it not just be called shared.  After all it is merely a more general
term of shared_ptr.  And the type of the resource kind of makes it implicit.

e.g.

shared  is a shared file. crystal.

Though this doesn't fit at all with non sharing policies.

Sam

Alisdair Meredith wrote:
> Larry Evans wrote:
>
>> Would the GOF name, proxy, be too non-specific?  Policy names might
>> provide the specifics (whether it's a pointer or a resource).
>
> Proxy, if anything, sends the wrong message to me.  The name suggests
> 'reference', rather then 'owner'
>
> 'bookkeeper' is the best I can come up with so far, but that is a very
> odd word to type  and still too long.

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

Re: [boost] newsgroup

[David Abrahams]

Noel Yap <[EMAIL PROTECTED]> writes:

> The news group advertised on the site,
> news.gmane.org/gmane.comp.lib.boost.devel, gives no response.  Has it
> moved?

Works for me.  Your post appears there.

news://news.gmane.org/gmane.comp.lib.boost.devel

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

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

[boost] Re: newsgroup

[Alisdair Meredith]

Noel Yap wrote:

> The news group advertised on the site,
> news.gmane.org/gmane.comp.lib.boost.devel, gives no response.  Has it
> moved?

Not if you get this reply, I do all my boosting through Gmane 

-- 
AlisdairM

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

Re: [boost] Re: resource manager naming

[David Abrahams]

Larry Evans <[EMAIL PROTECTED]> writes:

> Alisdair Meredith wrote:
>> Phil Nash wrote:
>> 
> [snip]
>> Final disorganised point   When you think 'pointer' without a
>> context, what concept do you associate first?  Resource-manager?  Or
>> dereferencable?  The very name suggests the latter to me!  [Which could
>> be why I have such a hard time with pointers-that-don't-point]
>> 
> Would the GOF name, proxy, be too non-specific?  

Yeah, it means something else in idiomatic C++.  For example,
std::vector::reference is a proxy, but it does no resource
management.

-Dave

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

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

[boost] Re: Broken links report

[Hubert Holin]

Somewhere in the E.U., le 27/02/2003

Bonjour


In article <[EMAIL PROTECTED]>,
 "Gennadiy Rozental" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I played today with some links validation software and set it upon
> www.boost.org
> 
> Here the results for those who is interested.
> 
> http://groups.yahoo.com/group/boost/files/BrokenLinksReport.htm
> 
> I took care about Boost.Test issues.
> 
> Gennadiy.


http://homepage.mac.com/hubert_holin 

Fixed (also fixed photos' new location).

http://www.boost.org/libs/math/octonion/octonion.html#octonion specializations not 
found
http://www.boost.org/libs/math/octonion/octonion.html##octonion not found
http://www.boost.org/libs/math/octonion/octonion.html##octonion not found
http://www.boost.org/libs/math/octonion/octonion.html##octonion not found

Fixed.

Will commit tomorrow, along with a few other changes.

Merci

HH

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

Re: [boost] Re: Is there any Interest in a Fixed Point Library?

[Kevin Atkinson]

On Thu, 27 Feb 2003, Jason House wrote:

> Kevin Atkinson wrote:
> > 
> > Is there any interest in a fixed point math library.  
> 
> Well, I'm interested in a fixed point library :)  
> Especially if it can be used as a template argument in place of a
> floating point type.

Thanks.

> > Using templates the
> > compiler can keep track of the radix point for you making using fixed
> > point math a lot less tedious and error prone.
> 
> One thought... It looks like the template parameter should be an integer
> type (of course, right?)...   I think that there is some way to cause a
> non integer type to generate a compiler error.  Of course, considering
> other types might have some value (ie. complex numbers, a double that
> overflows due to adding of large numbers?, and probably others that
> don't come to mind at the moment)

Be careful that you are not overly restrictive.  For example what about a 
class that supports very large integers.  What about a class that is a 
wrapper around an integers, such as one that is designed  to guarantee 
atomic operations, etc...

> > Attached is a rudimentary implementation which would work acceptably when
> > the exponent is not too large or too small.  If the exponent is smaller or
> > larger than the size of the underlying integer in bits this code will
> > likely behave badly.
> 
> I once had a bug that I ended up tracking down to assembly that relates
> to that...  Effectively shifting 32 bit numbers would cause a modulo 32
> on the shift amount.  The problem I had was that a case of shifting by
> 32 bits logically come up in my code... instead of clearing the number,
> it gave me the original number back!
> 
> I would have to assume that there is some kind of type trait that would
> help with enabling some kind of error check.  Even if it is just some
> kind of assert.  The fixed point to fixed point conversion is the most
> likely candidate for hitting this kind of a bug.  A base of 20 converted
> to a base of -15 would have a shift by 35...  (in effect, on my
> compiler/processor, that would only shift by 3)

Yes a check would be useful.  I think an assert to check the the shift 
size is not equal to or larger than the integer it is shifting in bits 
would work.  But what about an variable length integer class where the 
sizeof() operator won't work?

Also, please not that It IS possible to have a fixed point number with the
radix larger or smaller than the size of the integer in bits.  You just
have to be careful.  Some of my methods (like the frac one) also need to 
be written more carefully.

> > Comments on the code welcome.  I am not a numerical analysis specialist so
> > don't expect me to write a fixed point library for anything beyond simple
> > arithmetic.
> 
> 
> My comments are above...  Nothing on higher math functions :)
> 
> (Although, the conversion to double and back probably allows for the
> fixed point number to be used as a floating point number, and just cause
> higher math operations to operate on doubles, and then convert back.
> I believe that the code fragment "x = sqrt(x)" would compile fine.)

Yes, that would work.  But if your goal is to avoid floating point math
for speed (for a processor that doesn't have a FPU) than fixed point math
functions would be useful.  Of course the software emulation for the
floating point version of the math function may be just as fast.  I really
don't know.

> I think operators like += -= etc... would also be nice... they could
> actually be written to accept all bases, and possible be specialized for
> the same base...

Yes, I agree.  I just haven't written them.  Also currently 
  FixedPoint  integer will not work since the compiler has no
clue what FixedPoint to convert the integers into.  Thus overloaded
operators where one operand is an integer (or for that matter double)
should also be written.

I did say it was rudimentary ;)

--- 
http://kevin.atkinson.dhs.org

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

[boost] newsgroup

[Noel Yap]

The news group advertised on the site,
news.gmane.org/gmane.comp.lib.boost.devel, gives no response.  Has it
moved?

Thanks,
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: resource manager naming

[Alisdair Meredith]

Larry Evans wrote:

> Would the GOF name, proxy, be too non-specific?  Policy names might provide
> the specifics (whether it's a pointer or a resource).

Proxy, if anything, sends the wrong message to me.  The name suggests
'reference', rather then 'owner'

'bookkeeper' is the best I can come up with so far, but that is a very
odd word to type  and still too long.

-- 
AlisdairM

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

Re: [boost] Re: resource manager naming

[Larry Evans]

Alisdair Meredith wrote:
Phil Nash wrote:

[snip]
Final disorganised point   When you think 'pointer' without a
context, what concept do you associate first?  Resource-manager?  Or
dereferencable?  The very name suggests the latter to me!  [Which could
be why I have such a hard time with pointers-that-don't-point]
Would the GOF name, proxy, be too non-specific?  Policy names might provide
the specifics (whether it's a pointer or a resource).


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

[boost] Re: Is there any Interest in a Fixed Point Library?

[Jason House]

Kevin Atkinson wrote:
> 
> Is there any interest in a fixed point math library.  

Well, I'm interested in a fixed point library :)  
Especially if it can be used as a template argument in place of a
floating point type.

> Using templates the
> compiler can keep track of the radix point for you making using fixed
> point math a lot less tedious and error prone.


One thought... It looks like the template parameter should be an integer
type (of course, right?)...   I think that there is some way to cause a
non integer type to generate a compiler error.  Of course, considering
other types might have some value (ie. complex numbers, a double that
overflows due to adding of large numbers?, and probably others that
don't come to mind at the moment)

Is there an integer-based complex number class in existence in boost? 
If it supports >> and <<, then it could be used in the fixed point class
just as naturally as an integer type.  Of course the conversion to/from
double really doesn't make much sense...  So maybe there would be some
trouble...  I could imagine using some special coding tricks to make the
conversion normally be to double, but be a double precision complex
number class when an integer based complex number class is passed in... 
It's starting to sound more complicated to support complex numbers :( 
But all the requirements might already exist in boost :)

> Attached is a rudimentary implementation which would work acceptably when
> the exponent is not too large or too small.  If the exponent is smaller or
> larger than the size of the underlying integer in bits this code will
> likely behave badly.


I once had a bug that I ended up tracking down to assembly that relates
to that...  Effectively shifting 32 bit numbers would cause a modulo 32
on the shift amount.  The problem I had was that a case of shifting by
32 bits logically come up in my code... instead of clearing the number,
it gave me the original number back!

I would have to assume that there is some kind of type trait that would
help with enabling some kind of error check.  Even if it is just some
kind of assert.  The fixed point to fixed point conversion is the most
likely candidate for hitting this kind of a bug.  A base of 20 converted
to a base of -15 would have a shift by 35...  (in effect, on my
compiler/processor, that would only shift by 3)


> Comments on the code welcome.  I am not a numerical analysis specialist so
> don't expect me to write a fixed point library for anything beyond simple
> arithmetic.


My comments are above...  Nothing on higher math functions :)

(Although, the conversion to double and back probably allows for the
fixed point number to be used as a floating point number, and just cause
higher math operations to operate on doubles, and then convert back.
I believe that the code fragment "x = sqrt(x)" would compile fine.)

I think operators like += -= etc... would also be nice... they could
actually be written to accept all bases, and possible be specialized for
the same base...



> 
> --
> http://kevin.atkinson.dhs.org
> 
>   
> Name: fixed.hpp
>fixed.hppType: Plain Text (TEXT/PLAIN)
> Encoding: 7BIT
> 
>   
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[boost] Re: [optional] Polymorphism

[Philippe A. Bouchard]

"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]

[...]

> int main()
> {
> optional b;
> optional c;
>
> foo(b);
> //foo(c);
> }

BTW implicit cast to reference types are not implicit under GCC, they have
to be called explicitly.  Template casts do not seem to be defined in the
standard...:

template 
struct optional
{
template 
operator optional const & () const
{
return * reinterpret_cast const *>(static_cast(reinterpret_cast(storage_)));
}

...
 };

inline void foo(optional const &)
{
}

int main()
{
optional b;

//foo(b);
foo(b.template operator optional const &  ());
}


Also, the advantage of casts to reference types is that they do not create
any temporary objects implicitly.  I do not see in what it can be dangerous.

What do you think?



Philippe A. Bouchard




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

[boost] Re: resource manager naming

[Alisdair Meredith]

Phil Nash wrote:

> The fact is that most (I would hope) of those that are subscribed to the
> list know what a smart pointer is. Many would also make the extra connection
> between smart POINTERs and general RESOURCE management.

Not sure even here we agree 100%.  What is the precise scope of the term
smart pointer?  Does it encompass iterators, for instance, which model
another aspect of pointers totally unrelated to resource management?

AFAICT the link between pointers and resource management is simple an
old implementation detail, the pointer was the easiest tool in the box
for allocating variable resources at run-time, but there is nothing
forcing this link, or even strong support for it in the language (or the
whole smart pointer topic would never arise and there would be no issue
with delete[])  It concerns me to name and model the behaviour of a
future library on the implementation detail with shortcomings that needs
replaced.

Final disorganised point   When you think 'pointer' without a
context, what concept do you associate first?  Resource-manager?  Or
dereferencable?  The very name suggests the latter to me!  [Which could
be why I have such a hard time with pointers-that-don't-point]

-- 
AlisdairM

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

[boost] Re: resource manager naming

[Alisdair Meredith]

Dave Gomboc wrote:

> But those that don't would look for "resource_manager" or "resource_mgr"
> (and might even find "res_mgr").  The smart_ prefix is quite useless in
> this context, there isn't an old resource manager that is being replaced.

The whole resource management idea is quite fraught.  Smart pointers
often need this behaviour, so we talk about supplying a resource manager
policy, or set of policies.  I wonder if a general resource-management
framework is entirely separate to smart pointers (side-stepping some of
the convergence issues) but sharing the same policies.

As for a name of the resource manager framework, I think we need
something instantly catchy, but also eg short/quick-to-type.  vector is
a lot friendler in code than dynamic_array would have been.  I am at a
loss to supply a good name myself though, still pondering...

-- 
AlisdairM

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

Re: [boost] [Boost.python] Help. string heap error!

[David Abrahams]

Kim Chang Han <[EMAIL PROTECTED]> writes:

> Here is my simple test code modified from embedding.cpp test code(by
> Dirk Gerrits).
>
> I successfully compiled, but my excutable raise heap error assertion
> when the time freeing the string result of the function py.hello().
>
> Can I prevent this error?

I don't know; I can't reproduce your problem here with any compiler
including gcc-2.95.3 or gcc-3.2.x.  This appears to me to be a bug in
your compiler, standard library implementation, or installation.

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

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

[boost] Re: Borland C++ Builder patch 4 released

[Alisdair Meredith]

Beman Dawes wrote:

> But I really don't want to change compilers in the midst of a release
> runup. So I've stuck a note on my calendar for March 12th to install the
> patch.

> If anyone thinks this is a problem, let me know.

Assuming a new version number for __BORLANDC__ it might throw out some
of the configs.  Especially when idiots like me propose patches within
libraries that check compiler versions, rather than defect macros set up
in boost config!

I hope to find time to upgrade/run test suite over the weekend but we're
ridiculously busy right now so I may run late (again)

I'll post back if anything turns up.

[Could make config testing interesting if 0x0563 has fixes not present
in the Kylix release, 0x0570]

-- 
AlisdairM

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

[boost] Stats class

[Michael Meyer]

Statistics functionality would be extremely
interesting.
The idea would be to duplicate the basic notions of
the mathematical theory as C++ classes.

The conceptual hyrarchy (bottom to top) is as follows:

1. Probability distribution (implementation: random
number generator).

2. Random Object (Random variable, random vector)
implementation: this is your "stats class"

3. Stochastic process.

This thread places to much importance on the "stats
class" as a container of data. Obviously this view
results from the fact that most users work from
preexisting data sets which are read into a container.

This is what is called an empirical distribution and
could be handled as special case of a random variable
-- an empirical random variable.

The case of the preexisting data set is a fairly
trivial case. More generally the data are generated by
some procedure (special case: reading from the
preexisting data set).

The procedure could be more interesting than this.
For example in Monte Carlo simulation one often
computes the path of some stochastic process and then
generates a data point as a functional (deterministic
function) of this path. 

The notion of a random variable should capture all
this. I have already implemented some useful
abstractions in Java. See

http://martingale.berlios.de/Martingale.html

I am working on C++ now and will gladly contribute
code to Boost.






__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Borland C++ Builder patch 4 released

[Russell Hind]

FYI I've submitted it as QC#3629

Russell

Paul Mensonides wrote:
Russell Hind wrote:


Sorry to say that the output is now incorrect.  A2 instead of A 2.
Checking the preprocessor output for this gives
/* Unit1.cpp 9: */int main() {
/* Unit1.cpp 10: */std::cout << "A 2" << &std::endl;
/* Unit1.cpp 11: */return 0;
which is again correct.  This is strange since I thought that bcc32
was
just supposed to call cpp32 for the pre-processing.  I can submit this
as a bug to Borlands QualityCentral if you like (but don't hold your
breath).


:(

I'm not surprised, but I was hoping  If they fixed this bug, Borland would
be able to use the "strict" configuration of the pp-lib.  I'd still need the
same hacked configuration for Sun and IBM (they have similar bugs), but at least
Borland's wouldn't need it.
Please do submit a bug report.  I think they've already gotten this one before
though, so I'm not holding my breath. ;)
Thanks again for the help,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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

Re: [boost] possible addition to operators library

[Sam Partington]

Daniel Frey wrote:
>>
>> Daniel Frey wrote:
> No problem. IIRC it was Peter Dimov who came up with the safe-bool
> idiom first. At least I saw it first from him. Another way which
> works but results in worse error messages is this:
>
> template 
> struct bool_testable : B
> {
> private:
>   operator int() const;
>
> public:
>   operator bool() const
>   {
> return !!static_cast< T& >( *this );
>   }
> };
>
> It should be a more efficient implementation for most of the points
> Dave mentioned and it should also work in all cases (allowing the use
> as a bool, int is private, thus not accessible and other conversions,
> e.g. to 'long' are ambiguous. The drawback is, that the error
> messages are not as clear and obvious as for Peter's idiom.

Well we'll stick with Peter's model then.  I had figured it was Peter,
someone let me know if it wasn't.

Sam Partington (me!) wrote:
> Is there another alternative to this?  How about this:
>
>   typedef void (bool_testable::*unspecified_bool_type)() const;
>   operator unspecified_bool_type() const
>   {
>return !static_cast(*this) ? 0 :
> reinterpret_cast(&bool_testable::operator
> unspecified_bool_type);
>   }
>
>
> Does this have any issues that I can't see?   Ideally we could avoid
> the reinterpret_cast, but how do you express the type of a
> user-defined conversion operator for the type you're trying to
> express? Beats me!

I was hoping for a response to this, but I know we're all busy, so I'll take
the silence to mean that noone has any serious objections.  I know lots of
you will see the reinterpret_cast and start shouting "non-portable" but in
this case all its doing is casting the return type of the function pointer.
Also we're not going to use the pointer other than a compare to zero, so
providing there are no compilers that would reinterpret_cast to a zero, I
don't see a problem.

This is my preferred solution for now, as it avoids a lot of the overhead
problems that have worried some of you.

I've attached the patches, including docs and test.

Sam



operators_test.cpp.patch
Description: Binary data


operators.htm.patch
Description: Binary data


operators.hpp.patch
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Borland C++ Builder patch 4 released

[Paul Mensonides]

Russell Hind wrote:

> Sorry to say that the output is now incorrect.  A2 instead of A 2.
> Checking the preprocessor output for this gives
>
> /* Unit1.cpp 9: */int main() {
> /* Unit1.cpp 10: */std::cout << "A 2" << &std::endl;
> /* Unit1.cpp 11: */return 0;
>
> which is again correct.  This is strange since I thought that bcc32
> was
> just supposed to call cpp32 for the pre-processing.  I can submit this
> as a bug to Borlands QualityCentral if you like (but don't hold your
> breath).

:(

I'm not surprised, but I was hoping  If they fixed this bug, Borland would
be able to use the "strict" configuration of the pp-lib.  I'd still need the
same hacked configuration for Sun and IBM (they have similar bugs), but at least
Borland's wouldn't need it.

Please do submit a bug report.  I think they've already gotten this one before
though, so I'm not holding my breath. ;)

Thanks again for the help,
Paul Mensonides

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

[boost] Re: Borland C++ Builder patch 4 released

[Russell Hind]

Sorry to say that the output is now incorrect.  A2 instead of A 2. 
Checking the preprocessor output for this gives

/* Unit1.cpp 9: */int main() {
/* Unit1.cpp 10: */std::cout << "A 2" << &std::endl;
/* Unit1.cpp 11: */return 0;
which is again correct.  This is strange since I thought that bcc32 was 
just supposed to call cpp32 for the pre-processing.  I can submit this 
as a bug to Borlands QualityCentral if you like (but don't hold your 
breath).

Cheers

Russell

Paul Mensonides wrote:
Russell Hind wrote:


#define A() 1
#define B(m) m 2
B(A)

I've run the above through the preprocessor and heres the output

/* Unit1.cpp 1: */
/* Unit1.cpp 2: */
/* Unit1.cpp 3: */
/* Unit1.cpp 4: */A 2
Tested using the preprocess option with BCB6Pro Update 4.  This looks
like what you were hoping for.  If you'd like me to test anything else
then just let me know.


Thanks Russell.

What happens if you compile it all the way, i.e. with a compileable example:

#include 

#define A() 1
#define B(m) m 2
#define STR(x) STR_D(x)
#define STR_D(x) #x
int main() {
std::cout << STR(B(A)) << &std::endl;
return 0;
}
When this program is executed, it should output "A 2", not "A2".

The reason that I ask is that the only thing I have is the free command line
tools.  The included preprocessor, cpp32.exe, produces the correct output.  The
compiler proper, bcc32.exe, does not.  In other words, the behavior is/was
different with the separate preprocessor vs. the "integrated" preprocessor.
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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

[boost] Re: Thread-Local Storage (TLS)andtemplates

[Alexander Terekhov]

Edward Diener wrote:
[...]
> DllMain's DLL_THREAD_DETACH is a better design, I think you must realize
> that you are dealing with a company with millions and millions of developers

Yeah. "zillions of innocent programmers". 

regards,
alexander. < former MSDN-"universal subscription" MS customer >

--
http://www.terekhov.de/pthread_refcount_t/draft-edits.txt

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

Re: [boost] Re: Borland C++ Builder patch 4 released

[Paul Mensonides]

Russell Hind wrote:

>> #define A() 1
>> #define B(m) m 2
>>
>> B(A)
>>
>
> I've run the above through the preprocessor and heres the output
>
> /* Unit1.cpp 1: */
> /* Unit1.cpp 2: */
> /* Unit1.cpp 3: */
> /* Unit1.cpp 4: */A 2
>
> Tested using the preprocess option with BCB6Pro Update 4.  This looks
> like what you were hoping for.  If you'd like me to test anything else
> then just let me know.

Thanks Russell.

What happens if you compile it all the way, i.e. with a compileable example:

#include 

#define A() 1
#define B(m) m 2

#define STR(x) STR_D(x)
#define STR_D(x) #x

int main() {
std::cout << STR(B(A)) << &std::endl;
return 0;
}

When this program is executed, it should output "A 2", not "A2".

The reason that I ask is that the only thing I have is the free command line
tools.  The included preprocessor, cpp32.exe, produces the correct output.  The
compiler proper, bcc32.exe, does not.  In other words, the behavior is/was
different with the separate preprocessor vs. the "integrated" preprocessor.

Regards,
Paul Mensonides

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

[boost] Re: Borland C++ Builder patch 4 released

[Russell Hind]

Paul Mensonides wrote:
Beman Dawes wrote:

#define A() 1
#define B(m) m 2
B(A)

I've run the above through the preprocessor and heres the output

/* Unit1.cpp 1: */
/* Unit1.cpp 2: */
/* Unit1.cpp 3: */
/* Unit1.cpp 4: */A 2
Tested using the preprocess option with BCB6Pro Update 4.  This looks 
like what you were hoping for.  If you'd like me to test anything else 
then just let me know.

HTH

Russell

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

Re: [boost] Re: Formal Review for Boost I/O Library

[Thomas Witt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,

I am responsible for the overlap. This is due to an email getting lost.
The I/O review may be extended to make up for the overlap. I will make a
posting as soon as a solution is found.
In the meantime we will have two reviews running in parallel. Though
this is in fact undesirable, I don't think it's a real problem in this case.
Gennadiy Rozental wrote:
| Wait a minute!
| Variant is up to review till the Sunday 2nd. And I am planning to
supply my
| comments.
|
The variant review is still open and will be open until March 2nd.

Thomas
Boost Review Wizard
- --
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet
Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+Xd6A0ds/gS3XsBoRAlXoAJ4j7dZJOfdt6CxIVtod/Oc0hs9duACghTne
Kc7FWW6lXR+hP4I2oVL6EUA=
=vYhE
-END PGP SIGNATURE-
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Borland C++ Builder patch 4 released

[Paul Mensonides]

Beman Dawes wrote:
> Pavel,
>
>  >Official patch 4 was released just now:
>  >
>  >http://bdn.borland.com/article/0,1410,29793,00.html
>  >
>  >
>  >Among bugs fixed is:
>  >- The bcc compiler now compiles code containing a const member
> function.
>
> Hum... Interesting... Thanks for letting me know.

Could some one that has this compiler please test something for me?  I'm hoping
that a preprocessor bug got fixed (though it isn't listed).

#define A() 1
#define B(m) m 2

B(A)

It should expand to "A 2", but will probably expand to "A2".

Thanks in advance,
Paul Mensonides

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