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
pl
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.
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.
And, again, the re
Hi,
I know we shouldn't assume the order of signals execution, but can
we assume it will be the same on all platforms, whatever that order is?
It would be a big plus for unit testing.
Thanks
Nicolas
___
Unsubscribe & other changes: http://lists.
> "Justin M. Lewis" wrote:
> My idea was, if you make a simple template class, originally I called
> it CRetVal, you could force people to specify at the time the function
> is called what's going on. I made a helper template function retval
> that would create and return a CRetVal object of the
"Justin M. Lewis" wrote:
>
> Yes, it is better.
>
> The first example has the problem of, you still have to go look up the
> function to see if it's actually changing anything, or if it's taking the
> param in, reading teh value, then modifying based on what was read.
Then how about:
boost::t
Yes, it is better.
The first example has the problem of, you still have to go look up the
function to see if it's actually changing anything, or if it's taking the
param in, reading teh value, then modifying based on what was read.
The second example has the problem of copying a potentially large
At 02:25 PM 4/23/2003, Edward Diener wrote:
>I am happy to hear about that, the work you and others are doing to bring
>wide character filenames to C++, and the work you are doing to bring it
to
>the filesystem library. When I argued about this on comp.std.c++ I got
the
>distinct impression, fro
At 02:51 PM 4/23/2003, David Abrahams wrote:
>"Edward Diener" <[EMAIL PROTECTED]> writes:
>
>> I still feel that a fixed width Unicode encoding has to be an advance
>over
>> variable width encodings like MBCS for any character set.
>
>I guess that depends on how important random access over the
>ch
Gregory Colvin wrote:
> Is this really that much better than
>
> chk = GetSomething(&p1, &p2, p3, p4, p5);
>
> or
>
> GotSomething ret = GetSomething(p3,p4,p5);
Or even:
boost::tuple< int, int, bool > result = GetSomething( p1, p4, p5 );
Noel
--
NOTICE: If received in error, please
On Wednesday 23 April 2003 01:39 pm, David Abrahams wrote:
> 1. Why can't I find a regular html version of the any docs in my CVS
> checkout somewhere? Is this the effect of the new doc system? Not
> too happy about that!
We don't yet have an adequate solution for this (obviously). Putting the H
On Wednesday, Apr 23, 2003, at 16:07 America/Denver, Justin M. Lewis
wrote:
Sorry if the explanation is a bit confusing. The whole idea here is to
make it explicit at the function invocation that a parameter being
passed will be used to return a value.
A good example of where this would be useful
David Abrahams wrote:
> "Edward Diener" <[EMAIL PROTECTED]> writes:
>
>> I still feel that a fixed width Unicode encoding has to be an
>> advance over variable width encodings like MBCS for any character
>> set.
>
> I guess that depends on how important random access over the
> characters of a stri
Sorry if the explanation is a bit confusing. The whole idea here is to
make it explicit at the function invocation that a parameter being
passed will be used to return a value.
A good example of where this would be useful is with a function call
that takes some params, and returns several differe
It's not always that easy to give a function a name that will tell you
at invocation time which of it's parameters it's planning on changing,
and, it would be hard to tell people through just a function name that a
parameter is an in/out parameter.
As for a function returning a single param, I agr
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 i
Gabriel Dos Reis wrote:
>
> 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 wor
> > >
> > > The output of the above (in case the assertion fails) can look like:
> > >
> > > Assertion failed:
> > > '(v_(i) < v_(j)) || (i < 0) || (v_(k) == -1)'
> > > i= '3'
> > > j= '2'
> > > k= '1'
> > >
> > This feature looks handy. Short macro like "v_" is IMHO acceptable, it
> won't
> > clas
>
> I wounder if it could be somehow merged with
> http://www.cuj.com/experts/2104/alexandr.htm?topic=experts ?
I've read the article. Great piece. I think we could do it.
In case it's needed.
Best,
John
___
Unsubscribe & other changes: http://list
"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 accur
"Pavel Vozenilek" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "John Torjo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > assert( (i < j) || (i == 0) || (j == 1) ); would change into
> > SMART_ASSERT( (v_(i) < v_(j)) || (i == 0) || (j == 1) );
> >
> > The
Thanks for this, which I have just got round to trying out.Sadly, MSVC 7.0 now
gags on it as below. Is there something I need to #define? (I assume that the
previous config.h is replaced by the boost config).
Is the warning C4253 a worry? Is remains at warning level 3 (and I like things
to be wa
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 proble
"Edward Diener" <[EMAIL PROTECTED]> writes:
> I still feel that a fixed width Unicode encoding has to be an advance over
> variable width encodings like MBCS for any character set.
I guess that depends on how important random access over the
characters of a string is to you. To me, it seems like
"John Torjo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> assert( (i < j) || (i == 0) || (j == 1) ); would change into
> SMART_ASSERT( (v_(i) < v_(j)) || (i == 0) || (j == 1) );
>
> The output of the above (in case the assertion fails) can look like:
>
> Assertion failed:
> '(v_
"Justin M. Lewis" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]
> Not entirely, passing a pointer doesn't tell you that the parameter will
> change, it just tells you that it might, it still leaves you in the
position
> of having to track down the function and check it. But outsi
Beman Dawes wrote:
> At 09:03 PM 4/21/2003, Edward Diener wrote:
>
> >Beman Dawes wrote:
> >> ...
> >> Once the portable case is handled, then I'm willing to see if
> native >> format paths with wild-cards can be accommodated. But
> solving the >> portable case seems to me to be most important
Beman Dawes wrote:
> At 09:03 PM 4/21/2003, Edward Diener wrote:
>
> >Beman Dawes wrote:
> > I do
> >not believe that C++ should attempt to legislate what wide
> characters go >into a wide character file name as different locales
> will have their own >idea of what constitutes a valid wide cha
On Wednesday, Apr 23, 2003, at 12:04 America/Denver, Terje Slettebø
wrote:
From: "Justin M. Lewis" <[EMAIL PROTECTED]>
Well, I guess, based on all the code I've been reading at work it
didn't
seem so small, chasing down all kinds of functions across 100's of
files
to see why exactly values are
Doesn't Microsoft VC++ compilers starting from version 7 support member
template friends?
#if _MSC_VER <= 1310
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
#endif
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>From: "Terje Slettebø" <[EMAIL PROTECTED]>
> >From: "Justin M. Lewis" <[EMAIL PROTECTED]>
>
> > Well, I guess, based on all the code I've been reading at work it didn't
> > seem so small, chasing down all kinds of functions across 100's of files
> > to see why exactly values are changing mid func
>From: "Justin M. Lewis" <[EMAIL PROTECTED]>
> Well, I guess, based on all the code I've been reading at work it didn't
> seem so small, chasing down all kinds of functions across 100's of files
> to see why exactly values are changing mid function I'm looking at
> without warning.
>
> Anyway, thi
Beman Dawes wrote:
> At 09:35 PM 4/22/2003, David Abrahams wrote:
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> Remember that the C++ committee includes active long-time members
> from >> Japan, and that as one of the ten or twelve voting
> delegations to the >> WG21 ISO portion of the c
Well, I guess, based on all the code I've been reading at work it didn't
seem so small, chasing down all kinds of functions across 100's of files
to see why exactly values are changing mid function I'm looking at
without warning.
Anyway, this would allow for stronger enforcement of the rule that
c
1. Why can't I find a regular html version of the any docs in my CVS
checkout somewhere? Is this the effect of the new doc system? Not
too happy about that!
2. Consider:
template ValueType any_cast(const any & operand);
template const ValueType * any_cast(const any * operand);
tem
That depends. At one point the out and in_out classes had assert checks
in them. c_out would check to make sure that it was assigned some value
inside the called function, for example. The other thing is, the idea
here is to force people CALLING your function (func) to show the world
what's goin
Justin M. Lewis wrote:
Not entirely, passing a pointer doesn't tell you that the parameter will
change, it just tells you that it might, it still leaves you in the position
of having to track down the function and check it. But outside of that, if
you're like me, at this point you prefer reference
Not entirely, passing a pointer doesn't tell you that the parameter will
change, it just tells you that it might, it still leaves you in the position
of having to track down the function and check it. But outside of that, if
you're like me, at this point you prefer references to pointers, whenever
37 matches
Mail list logo
