>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 eli
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, w
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
1681692
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<
i
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
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
1681692
"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 need
"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
Terje Slettebø wrote:
> 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:
>
>
Playing devil's advocate, I think RVO can easily be fooled with
not-so
>From: "Noel Yap" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> > 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:
>
> Playing devil's advocate,
Daniel Frey <[EMAIL PROTECTED]> writes:
> my_list.sort( shared_ptr_content_less< my_list >() );
That should be
my_list.sort( shared_ptr_content_less() );
or you can do it the easy way using the Boost.Lambda library:
my_list.sort(*_1 < *_2);
Regards,
--
Dave Abrahams
Boost Consul
> 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_
These news are very good, but what about the "thread library"?
They will not forget it, will they?
Daniel Spangenberg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello!
Recently we tried to compile the boost 1.29 with some of our older Win32
codes using the .NET 7.0
compiler. We got an compiler error due to ambiguities of these overloads
inside the CMap template
implementation header . Does anyone know, whether this is a
problem of the .NET 7.0 library or
Recently we tried to compile the boost 1.29 with some of our older Win32
codes using the .NET 7.0
compiler. We got an compiler error due to ambiguities of these overloads
inside the CMap template
implementation header .
In VC6 the std::min and std::max templates were not present, so they are
--- 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 N
Well, take erf using a single parameter for precision
template
double erf{};
Then in usage somewhere...
{
double x2 = erf<0.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 outpu
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 bo
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;
- 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 an
I diagree with this. The code I've written using this looks more like
void add_char( in_out 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
Hello Matthew Towler!
Matthew Towler schrieb:
> > Recently we tried to compile the boost 1.29 with some of our older Win32
> > codes using the .NET 7.0
> > compiler. We got an compiler error due to ambiguities of these overloads
> > inside the CMap template
> > implementation header .
>
> In VC6
"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 im
"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
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 go
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 befor
"Justin M. Lewis" wrote:
>
> I diagree with this. The code I've written using this looks more like
>
> void add_char( in_out 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
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 explici
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 functionali
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 th
30 matches
Mail list logo
