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
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
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:
templatetypename ValueType ValueType any_cast(const any operand);
templatetypename ValueType const ValueType *
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 committee, their
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, this would
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 character
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.
I can
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 outside of
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_(i) v_(j))
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
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
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.
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
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
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 string is to you.
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
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::tuple
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
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
19 matches
Mail list logo
