Digital Mars - c++ - Evaluation order for function parameters

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

Mark,

I think it is basically as Walter wrote.
When you use __cdecl in your function prototype you define the function to be C
prototype which basically means that the last function argument is put on the
stack first. This has to be this way
as after all the arguments have been put on the stack the return address will
be put on the stack. (Of course 'call' does that for you). So when digging the
stack in the *called* function you
know that the first argument appears closest to the return address. This way it
is possible to have functions wth a variable number of arguments as long as
there is some way to tell the function
how meny arguments there are. This way a printf can exist and quite a few more
like that.

I actually recently implemented a vsscanf as it seems to be missing in the
standard libraries.

Don't worry, be Kneppie!
Jan



Mark Evans wrote:

 It may be best, but is not always desirable to do that.  In some applications
the whole idea is to avoid using intermediate variables such as a,b,c in your
example.  Instead I have a pseudo-
 class to perform intermediary functions.  It has standard interface calls and
these are what I wish to employ.  The pseudo-class serves the purpose of
simplifying calls made to a DLL.  The
 last thing I want to do is rewrite 186 DLL calls using intermediate variables
for each parameter.  That was why I wrote the pseudo-class.  I got tired of
using intermediate dummy variables.
 The class takes user parameters from an input text stream and turns them into
DLL calls.  I want the pseudo-class interface calls embedded in the DLL
function call code.  A working
 example:

 WRAP( spmCalSync )
 {
         static TypeCode types_in[]  =
{kTYPE_SPMHANDLE,kTYPE_I32,kTYPE_BOOLCHAR,kTYPE_TERMINATION};
         static TypeCode types_out[] =
{kTYPE_SPMERR,kTYPE_SPMHANDLE,kTYPE_TERMINATION};

         DEFAULT_PARSE;

         *Next_SPMERR(outpb,PUT) =
         spmCalSynch(
                 *Pop_SPMHANDLE(inpb),
                 Next_SPMHANDLE(outpb,PUT),
                 *Pop_I32(inpb),
                 BLCTruth(*Pop_BLC(inpb)));

         DEFAULT_FORMAT;
 }

 where WRAP, DEFAULT_PARSE, DEFAULT_FORMAT are preprocessor macros for various
mundane housekeeping tasks.  The DLL call is "spmCalSynch".  This type of code
is very
 easy to read and to write.  All it takes is a little care with the compiler
evaluation ordering.  The code implements a form of run-time type information
in procedural C.

 Some simple testing has revealed what I needed to know.  In procedural C the
evaluation order is right-to-left, same as the stack order.  I haven't tested
C++ but would assume it's the same.

 It would be nice if the documentation covered this topic since in principle,
the evaluation order need not correspond to the stack order, although it does
in this case.

 Mark

 On Mon, 14 May 2001 22:54:23 -0700, "Walter" <walter digitalmars.com> wrote:
 It depends on whether it is a C function, a C++ function, and whether it has
 cdecl, pascal, fortran, stdcall, linkage.

 In other words, it's best to not depend on any particular order, and rewrite
 as:

     a = barOne(1.0);
     b = barTwo(2.0);
     c = barThree(3.0);
     test = foo(a, b, c);

 Now the order of evaluation is guaranteed.


 Mark Evans wrote in message <1103_989852553 evans>...
My question pertains to the order of evaluation of function parameters


 test = foo(barOne(1.0),barTwo(2.0),barThree(3.0));

I know that C has a convention about the ultimate ordering of parameters on


What I need to know is the order of evaluation for barOne(), barTwo(), and


Thanks,

Mark

May 15 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

Although the DMC compiler does not do this, it would be standard conforming
if the optimizer decided to rearrange the order of evaluation of function
parameters. So, when you depend on order-of-evaluation, there's a risk that
the code may subtly break with different compilers, a different release of
the same one *or even* it may change depending on what expressions you use
for the parameters and how they interact with the optimizer.

-Walter

Mark Evans wrote in message <1103_989929526 evans>...
It may be best, but is not always desirable to do that.  In some


a,b,c in your example.  Instead I have a pseudo-
class to perform intermediary functions.  It has standard interface calls


simplifying calls made to a DLL.  The
last thing I want to do is rewrite 186 DLL calls using intermediate


tired of using intermediate dummy variables.
The class takes user parameters from an input text stream and turns them


function call code.  A working
example:

WRAP( spmCalSync )
{
 static TypeCode types_in[]  =


 static TypeCode types_out[] =


 DEFAULT_PARSE;

 *Next_SPMERR(outpb,PUT) =
 spmCalSynch(
 *Pop_SPMHANDLE(inpb),
 Next_SPMHANDLE(outpb,PUT),
 *Pop_I32(inpb),
 BLCTruth(*Pop_BLC(inpb)));

 DEFAULT_FORMAT;
}

where WRAP, DEFAULT_PARSE, DEFAULT_FORMAT are preprocessor macros for


type of code is very
easy to read and to write.  All it takes is a little care with the compiler


information in procedural C.
Some simple testing has revealed what I needed to know.  In procedural C


tested C++ but would assume it's the same.
It would be nice if the documentation covered this topic since in


although it does in this case.
Mark


On Mon, 14 May 2001 22:54:23 -0700, "Walter" <walter digitalmars.com>


 It depends on whether it is a C function, a C++ function, and whether it




 cdecl, pascal, fortran, stdcall, linkage.

 In other words, it's best to not depend on any particular order, and




 as:

     a = barOne(1.0);
     b = barTwo(2.0);
     c = barThree(3.0);
     test = foo(a, b, c);

 Now the order of evaluation is guaranteed.


 Mark Evans wrote in message <1103_989852553 evans>...
My question pertains to the order of evaluation of function parameters


 test = foo(barOne(1.0),barTwo(2.0),barThree(3.0));

I know that C has a convention about the ultimate ordering of parameters






 the stack.  That's not what concerns me.
What I need to know is the order of evaluation for barOne(), barTwo(),






 barThree().  Is it left-to-right, right-to-left, or something




Thanks,

Mark

May 15 2001

↑ ↓ ← → Mark Evans <mevans zyvex.com> writes:

Walter,

Yes that is what I said, the order of evaluation need not conform to parameter
stack order.  That is the reason I asked in the first place.

Agreed it is risky, but as always, no risk, no reward.

Might I suggest the idea of a #pragma to enforce the order of evaluation, thus
avoiding the risks?  Perhaps compiler writers could offer programmers a 
little more control in this area.

Mark


On Tue, 15 May 2001 08:53:40 -0700, "Walter" <walter digitalmars.com> wrote:
 Although the DMC compiler does not do this, it would be standard conforming
 if the optimizer decided to rearrange the order of evaluation of function
 parameters. So, when you depend on order-of-evaluation, there's a risk that
 the code may subtly break with different compilers, a different release of
 the same one *or even* it may change depending on what expressions you use
 for the parameters and how they interact with the optimizer.
 
 -Walter
 
 Mark Evans wrote in message <1103_989929526 evans>...
It may be best, but is not always desirable to do that.  In some


 a,b,c in your example.  Instead I have a pseudo-
class to perform intermediary functions.  It has standard interface calls


 simplifying calls made to a DLL.  The
last thing I want to do is rewrite 186 DLL calls using intermediate


 tired of using intermediate dummy variables.
The class takes user parameters from an input text stream and turns them


 function call code.  A working
example:

WRAP( spmCalSync )
{
 static TypeCode types_in[]  =


 static TypeCode types_out[] =


 DEFAULT_PARSE;

 *Next_SPMERR(outpb,PUT) =
 spmCalSynch(
 *Pop_SPMHANDLE(inpb),
 Next_SPMHANDLE(outpb,PUT),
 *Pop_I32(inpb),
 BLCTruth(*Pop_BLC(inpb)));

 DEFAULT_FORMAT;
}

where WRAP, DEFAULT_PARSE, DEFAULT_FORMAT are preprocessor macros for


 type of code is very
easy to read and to write.  All it takes is a little care with the compiler


 information in procedural C.
Some simple testing has revealed what I needed to know.  In procedural C


 tested C++ but would assume it's the same.
It would be nice if the documentation covered this topic since in


 although it does in this case.
Mark


On Mon, 14 May 2001 22:54:23 -0700, "Walter" <walter digitalmars.com>


 It depends on whether it is a C function, a C++ function, and whether it




 cdecl, pascal, fortran, stdcall, linkage.

 In other words, it's best to not depend on any particular order, and




 as:

     a = barOne(1.0);
     b = barTwo(2.0);
     c = barThree(3.0);
     test = foo(a, b, c);

 Now the order of evaluation is guaranteed.


 Mark Evans wrote in message <1103_989852553 evans>...
My question pertains to the order of evaluation of function parameters


 test = foo(barOne(1.0),barTwo(2.0),barThree(3.0));

I know that C has a convention about the ultimate ordering of parameters






 the stack.  That's not what concerns me.
What I need to know is the order of evaluation for barOne(), barTwo(),






 barThree().  Is it left-to-right, right-to-left, or something




Thanks,

Mark

May 15 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

The pragma is a good idea, but the problem I have is that already there are
too many options for code generation such that it is a mathematical
impossibility to test every combination of options. This makes it a tough
sell to add more <g>.

-Walter


Mark Evans wrote in message <1103_989939560 evans>...
Walter,

Yes that is what I said, the order of evaluation need not conform to


Agreed it is risky, but as always, no risk, no reward.

Might I suggest the idea of a #pragma to enforce the order of evaluation,


little more control in this area.

Mark


On Tue, 15 May 2001 08:53:40 -0700, "Walter" <walter digitalmars.com>


 Although the DMC compiler does not do this, it would be standard




 if the optimizer decided to rearrange the order of evaluation of function
 parameters. So, when you depend on order-of-evaluation, there's a risk




 the code may subtly break with different compilers, a different release




 the same one *or even* it may change depending on what expressions you




 for the parameters and how they interact with the optimizer.

 -Walter

 Mark Evans wrote in message <1103_989929526 evans>...
It may be best, but is not always desirable to do that.  In some






 a,b,c in your example.  Instead I have a pseudo-
class to perform intermediary functions.  It has standard interface






 and these are what I wish to employ.  The pseudo-class serves the purpose




 simplifying calls made to a DLL.  The
last thing I want to do is rewrite 186 DLL calls using intermediate






 tired of using intermediate dummy variables.
The class takes user parameters from an input text stream and turns them






 function call code.  A working
example:

WRAP( spmCalSync )
{
 static TypeCode types_in[]  =


 static TypeCode types_out[] =


 DEFAULT_PARSE;

 *Next_SPMERR(outpb,PUT) =
 spmCalSynch(
 *Pop_SPMHANDLE(inpb),
 Next_SPMHANDLE(outpb,PUT),
 *Pop_I32(inpb),
 BLCTruth(*Pop_BLC(inpb)));

 DEFAULT_FORMAT;
}

where WRAP, DEFAULT_PARSE, DEFAULT_FORMAT are preprocessor macros for


 type of code is very
easy to read and to write.  All it takes is a little care with the






 evaluation ordering.  The code implements a form of run-time type
 information in procedural C.
Some simple testing has revealed what I needed to know.  In procedural C






 tested C++ but would assume it's the same.
It would be nice if the documentation covered this topic since in


 although it does in this case.
Mark


On Mon, 14 May 2001 22:54:23 -0700, "Walter" <walter digitalmars.com>


 It depends on whether it is a C function, a C++ function, and whether








 has
 cdecl, pascal, fortran, stdcall, linkage.

 In other words, it's best to not depend on any particular order, and




 as:

     a = barOne(1.0);
     b = barTwo(2.0);
     c = barThree(3.0);
     test = foo(a, b, c);

 Now the order of evaluation is guaranteed.


 Mark Evans wrote in message <1103_989852553 evans>...
My question pertains to the order of evaluation of function










 expressed, in turn, as function calls.
 test = foo(barOne(1.0),barTwo(2.0),barThree(3.0));

I know that C has a convention about the ultimate ordering of










 on
 the stack.  That's not what concerns me.
What I need to know is the order of evaluation for barOne(),










 and
 barThree().  Is it left-to-right, right-to-left, or something




Thanks,

Mark

May 16 2001

↑ ↓ ← → Mark Evans <mevans zyvex.com> writes:

If not a #pragma then how about a hardwired preprocessor #define (similar to
__FILE__ or __cplusplus) which specifies the ordering.  Then I could do

#ifndef __RTL_ARG_EVAL__
#abort "This code requires a particular evaluation order for arguments."
#endif

or something similar to that.  Maybe the C standards folks would be interested
in adding it to their list of hardwired #defines, if they have any.

Mark


On Wed, 16 May 2001 00:50:55 -0700, "Walter" <walter digitalmars.com> wrote:
 The pragma is a good idea, but the problem I have is that already there are
 too many options for code generation such that it is a mathematical
 impossibility to test every combination of options. This makes it a tough
 sell to add more <g>.
 
 -Walter
 
 
 Mark Evans wrote in message <1103_989939560 evans>...
Walter,

Yes that is what I said, the order of evaluation need not conform to


Agreed it is risky, but as always, no risk, no reward.

Might I suggest the idea of a #pragma to enforce the order of evaluation,


little more control in this area.

Mark


On Tue, 15 May 2001 08:53:40 -0700, "Walter" <walter digitalmars.com>


 Although the DMC compiler does not do this, it would be standard




 if the optimizer decided to rearrange the order of evaluation of function
 parameters. So, when you depend on order-of-evaluation, there's a risk




 the code may subtly break with different compilers, a different release




 the same one *or even* it may change depending on what expressions you




 for the parameters and how they interact with the optimizer.

 -Walter

 Mark Evans wrote in message <1103_989929526 evans>...
It may be best, but is not always desirable to do that.  In some






 a,b,c in your example.  Instead I have a pseudo-
class to perform intermediary functions.  It has standard interface






 and these are what I wish to employ.  The pseudo-class serves the purpose




 simplifying calls made to a DLL.  The
last thing I want to do is rewrite 186 DLL calls using intermediate






 tired of using intermediate dummy variables.
The class takes user parameters from an input text stream and turns them






 function call code.  A working
example:

WRAP( spmCalSync )
{
 static TypeCode types_in[]  =


 static TypeCode types_out[] =


 DEFAULT_PARSE;

 *Next_SPMERR(outpb,PUT) =
 spmCalSynch(
 *Pop_SPMHANDLE(inpb),
 Next_SPMHANDLE(outpb,PUT),
 *Pop_I32(inpb),
 BLCTruth(*Pop_BLC(inpb)));

 DEFAULT_FORMAT;
}

where WRAP, DEFAULT_PARSE, DEFAULT_FORMAT are preprocessor macros for


 type of code is very
easy to read and to write.  All it takes is a little care with the






 evaluation ordering.  The code implements a form of run-time type
 information in procedural C.
Some simple testing has revealed what I needed to know.  In procedural C






 tested C++ but would assume it's the same.
It would be nice if the documentation covered this topic since in


 although it does in this case.
Mark


On Mon, 14 May 2001 22:54:23 -0700, "Walter" <walter digitalmars.com>


 It depends on whether it is a C function, a C++ function, and whether








 has
 cdecl, pascal, fortran, stdcall, linkage.

 In other words, it's best to not depend on any particular order, and




 as:

     a = barOne(1.0);
     b = barTwo(2.0);
     c = barThree(3.0);
     test = foo(a, b, c);

 Now the order of evaluation is guaranteed.


 Mark Evans wrote in message <1103_989852553 evans>...
My question pertains to the order of evaluation of function










 expressed, in turn, as function calls.
 test = foo(barOne(1.0),barTwo(2.0),barThree(3.0));

I know that C has a convention about the ultimate ordering of










 on
 the stack.  That's not what concerns me.
What I need to know is the order of evaluation for barOne(),










 and
 barThree().  Is it left-to-right, right-to-left, or something




Thanks,

Mark

May 16 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

Since the evaluation order is dependent on many things, and may change from
function to function even in the same source file, setting a #define won't
help (since the #define would be global).

I understand what you're trying to do, and know that the temporary approach
looks ugly. But a lot of things that work wind up looking ugly <g>, and my
best recommendation is to just use it. If your code exists for any long
period of time (and I've found bits of code I wrote 20 years ago floating
around the internet!), might as well be pragmatic about it. At the very
least, put a comment in saying it is order dependent.

P.S. If I'd known at the time my source code would be in use 20 years later,
I would have written it better <g>. Some of it is embarassingly bad.


"Mark Evans" <mevans zyvex.com> wrote in message
news:1103_990029668 evans...
 If not a #pragma then how about a hardwired preprocessor #define (similar


 #ifndef __RTL_ARG_EVAL__
 #abort "This code requires a particular evaluation order for arguments."
 #endif

 or something similar to that.  Maybe the C standards folks would be


any.
 Mark


 On Wed, 16 May 2001 00:50:55 -0700, "Walter" <walter digitalmars.com>


 The pragma is a good idea, but the problem I have is that already there




 too many options for code generation such that it is a mathematical
 impossibility to test every combination of options. This makes it a




 sell to add more <g>.

 -Walter


 Mark Evans wrote in message <1103_989939560 evans>...
Walter,

Yes that is what I said, the order of evaluation need not conform to


Agreed it is risky, but as always, no risk, no reward.

Might I suggest the idea of a #pragma to enforce the order of






 thus avoiding the risks?  Perhaps compiler writers could offer




little more control in this area.

Mark


On Tue, 15 May 2001 08:53:40 -0700, "Walter" <walter digitalmars.com>


 Although the DMC compiler does not do this, it would be standard




 if the optimizer decided to rearrange the order of evaluation of








 parameters. So, when you depend on order-of-evaluation, there's a








 that
 the code may subtly break with different compilers, a different








 of
 the same one *or even* it may change depending on what expressions








 use
 for the parameters and how they interact with the optimizer.

 -Walter

 Mark Evans wrote in message <1103_989929526 evans>...
It may be best, but is not always desirable to do that.  In some










 as
 a,b,c in your example.  Instead I have a pseudo-
class to perform intermediary functions.  It has standard interface






 and these are what I wish to employ.  The pseudo-class serves the








 of
 simplifying calls made to a DLL.  The
last thing I want to do is rewrite 186 DLL calls using intermediate










 got
 tired of using intermediate dummy variables.
The class takes user parameters from an input text stream and turns










 into DLL calls.  I want the pseudo-class interface calls embedded in








 DLL
 function call code.  A working
example:

WRAP( spmCalSync )
{
 static TypeCode types_in[]  =


 static TypeCode types_out[] =


 DEFAULT_PARSE;

 *Next_SPMERR(outpb,PUT) =
 spmCalSynch(
 *Pop_SPMHANDLE(inpb),
 Next_SPMHANDLE(outpb,PUT),
 *Pop_I32(inpb),
 BLCTruth(*Pop_BLC(inpb)));

 DEFAULT_FORMAT;
}

where WRAP, DEFAULT_PARSE, DEFAULT_FORMAT are preprocessor macros










 various mundane housekeeping tasks.  The DLL call is "spmCalSynch".








 type of code is very
easy to read and to write.  All it takes is a little care with the






 evaluation ordering.  The code implements a form of run-time type
 information in procedural C.
Some simple testing has revealed what I needed to know.  In










 the evaluation order is right-to-left, same as the stack order.  I




 tested C++ but would assume it's the same.
It would be nice if the documentation covered this topic since in










 although it does in this case.
Mark


On Mon, 14 May 2001 22:54:23 -0700, "Walter"










 wrote:
 It depends on whether it is a C function, a C++ function, and












 it
 has
 cdecl, pascal, fortran, stdcall, linkage.

 In other words, it's best to not depend on any particular order,












 rewrite
 as:

     a = barOne(1.0);
     b = barTwo(2.0);
     c = barThree(3.0);
     test = foo(a, b, c);

 Now the order of evaluation is guaranteed.


 Mark Evans wrote in message <1103_989852553 evans>...
My question pertains to the order of evaluation of function










 expressed, in turn, as function calls.
 test = foo(barOne(1.0),barTwo(2.0),barThree(3.0));

I know that C has a convention about the ultimate ordering of










 on
 the stack.  That's not what concerns me.
What I need to know is the order of evaluation for barOne(),










 and
 barThree().  Is it left-to-right, right-to-left, or something




Thanks,

Mark

May 16 2001

↑ ↓ ← → Mark Evans <mevans zyvex.com> writes:

No, no, no, and no!  Temporary variables are being purposefully avoided with
deliberate intent.

I have already commented the code.

I think the safest option for me is an assert function which tests the ordering
and validates it from a running executable.

Mark


On Wed, 16 May 2001 12:04:02 -0700, "Walter" <walter digitalmars.com> wrote:
 Since the evaluation order is dependent on many things, and may change from
 function to function even in the same source file, setting a #define won't
 help (since the #define would be global).
 
 I understand what you're trying to do, and know that the temporary approach
 looks ugly. But a lot of things that work wind up looking ugly <g>, and my
 best recommendation is to just use it. If your code exists for any long
 period of time (and I've found bits of code I wrote 20 years ago floating
 around the internet!), might as well be pragmatic about it. At the very
 least, put a comment in saying it is order dependent.
 
 P.S. If I'd known at the time my source code would be in use 20 years later,
 I would have written it better <g>. Some of it is embarassingly bad.
 
 
 "Mark Evans" <mevans zyvex.com> wrote in message
 news:1103_990029668 evans...
 If not a #pragma then how about a hardwired preprocessor #define (similar


 #ifndef __RTL_ARG_EVAL__
 #abort "This code requires a particular evaluation order for arguments."
 #endif

 or something similar to that.  Maybe the C standards folks would be


 any.
 Mark


 On Wed, 16 May 2001 00:50:55 -0700, "Walter" <walter digitalmars.com>


 The pragma is a good idea, but the problem I have is that already there




 too many options for code generation such that it is a mathematical
 impossibility to test every combination of options. This makes it a




 sell to add more <g>.

 -Walter


 Mark Evans wrote in message <1103_989939560 evans>...
Walter,

Yes that is what I said, the order of evaluation need not conform to


Agreed it is risky, but as always, no risk, no reward.

Might I suggest the idea of a #pragma to enforce the order of






 thus avoiding the risks?  Perhaps compiler writers could offer




little more control in this area.

Mark


On Tue, 15 May 2001 08:53:40 -0700, "Walter" <walter digitalmars.com>


 Although the DMC compiler does not do this, it would be standard




 if the optimizer decided to rearrange the order of evaluation of








 parameters. So, when you depend on order-of-evaluation, there's a








 that
 the code may subtly break with different compilers, a different








 of
 the same one *or even* it may change depending on what expressions








 use
 for the parameters and how they interact with the optimizer.

 -Walter

 Mark Evans wrote in message <1103_989929526 evans>...
It may be best, but is not always desirable to do that.  In some










 as
 a,b,c in your example.  Instead I have a pseudo-
class to perform intermediary functions.  It has standard interface






 and these are what I wish to employ.  The pseudo-class serves the








 of
 simplifying calls made to a DLL.  The
last thing I want to do is rewrite 186 DLL calls using intermediate










 got
 tired of using intermediate dummy variables.
The class takes user parameters from an input text stream and turns










 into DLL calls.  I want the pseudo-class interface calls embedded in








 DLL
 function call code.  A working
example:

WRAP( spmCalSync )
{
 static TypeCode types_in[]  =


 static TypeCode types_out[] =


 DEFAULT_PARSE;

 *Next_SPMERR(outpb,PUT) =
 spmCalSynch(
 *Pop_SPMHANDLE(inpb),
 Next_SPMHANDLE(outpb,PUT),
 *Pop_I32(inpb),
 BLCTruth(*Pop_BLC(inpb)));

 DEFAULT_FORMAT;
}

where WRAP, DEFAULT_PARSE, DEFAULT_FORMAT are preprocessor macros










 various mundane housekeeping tasks.  The DLL call is "spmCalSynch".








 type of code is very
easy to read and to write.  All it takes is a little care with the






 evaluation ordering.  The code implements a form of run-time type
 information in procedural C.
Some simple testing has revealed what I needed to know.  In










 the evaluation order is right-to-left, same as the stack order.  I




 tested C++ but would assume it's the same.
It would be nice if the documentation covered this topic since in










 although it does in this case.
Mark


On Mon, 14 May 2001 22:54:23 -0700, "Walter"










 wrote:
 It depends on whether it is a C function, a C++ function, and












 it
 has
 cdecl, pascal, fortran, stdcall, linkage.

 In other words, it's best to not depend on any particular order,












 rewrite
 as:

     a = barOne(1.0);
     b = barTwo(2.0);
     c = barThree(3.0);
     test = foo(a, b, c);

 Now the order of evaluation is guaranteed.


 Mark Evans wrote in message <1103_989852553 evans>...
My question pertains to the order of evaluation of function










 expressed, in turn, as function calls.
 test = foo(barOne(1.0),barTwo(2.0),barThree(3.0));

I know that C has a convention about the ultimate ordering of










 on
 the stack.  That's not what concerns me.
What I need to know is the order of evaluation for barOne(),










 and
 barThree().  Is it left-to-right, right-to-left, or something




Thanks,

Mark

May 16 2001