x64 ports ...

[carbonera]

I used to work for a medical company that ported an application to x64.

In one of the meetings held, there was a discussion of whether to change in general functions with prototypes such as f(double const &, int const &) to f(double, int).

Could you please share your thoughts on this subject?

[LAfSLyTq]

whats the difference, why does it matter?

[BlackSheep]

Basic data types are usually faster to just pass as copies on the stack, since a reference needs to be dereferenced, which can be fairly slow. Large classes are by far more economical to pass by reference.

[carbonera]

Suppose that somewhere in your code base you have the following

double g(int &);

f(g(i), i);

[CrucialPoint]

*f(double const &, int const &)*

the objects' addresses are supposed to be constant references

*f(double, int)*
f accepts values of double and integer types only.

[carbonera]

nobody has any concerns?

[firedraco]

I would personally pass them by copy even on 32 bit machines.

[carbonera]

no one sees a problem with changing the actual function f?

Somewhere in your code you may have the following being changed from

double g(int &);
void f(double const &, int const &);
.
.
.
f(g(i), i);

to

double g(int &);
void f(double, int);
.
.
.
f(g(i), i);

[Cubbi]

If you feel like it's a good opportunity to enforce a company-wide coding style guideline, by all means do so, but the change is completely irrelevant to your 64-bit porting effort, and has no visible effects. Most compilers produce identical code anyway.