Hi guys!
This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
... Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ). The
compiler in this case checks of any assignment or possible change of
the parameter/variable and gives an potential error message, thus
ensuring robustness of the code and also, imho, by following this
convention the readability and understanding of the code for future
re/viewers is better.
The opposite opinion was based on fact, that when you need to
use/declare a local variable inside the function, the code is less
efficient (because you lose speed and memory usage is higher), since
you could you use a stack variable provided as a parameter ( and since
is it YOU who writes the body of a function YOU take care of proper
content of the variable ).
The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...
The fact is that we develop time and memory critical system, but
overall such subtle memory and speed differences do not have critical
impact on the whole system since it runs on hardware which is powerful
and dimensed enough to host the sw; therefore, this is, IMHO, a
completely nonsense, and the questions are:
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
- are those benefits really so high that you can ignore possible future
bugs ?
- does it even make sense to reason in this context in terms like speed
and memory efficiency ?
Thanks for comments..:)
9  2035  bu*************@gmail.com wrote:
[...]
This whle thing belongs to 'comp.software-eng', really. I don't see
a *C++ language* problem here.
The fact is that we develop time and memory critical system, but
overall such subtle memory and speed differences do not have critical
impact on the whole system since it runs on hardware which is powerful
and dimensed enough to host the sw; therefore, this is, IMHO, a
completely nonsense, and the questions are:
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
Why are you asking us? If *you* can't decide, who can? Every case is
different. Sometimes you need to squeeze every CPU tick, sometimes it
isn't that important.
Besides, this sounds (looks) like a rhetoric question. If you need some
kind of affirmation from us, you won't really get it. It's a toss-up.
And it's case-specific.
- are those benefits really so high that you can ignore possible
future bugs ?
Again, this sounds (looks) like a rhetoric question. Are you losing the
argument to your colleagues who don't think so? Here is my question:
*what* future bugs? Performance is sometimes paramount. When you get
any "future" bugs, deal with them. If (and it sounds like it) you have
the performance problem *now*, you have to deal with it in any way you
can. But you won't know whether you have the performance problem *until*
you measure for it.
- does it even make sense to reason in this context in terms like
speed and memory efficiency ?
Possibly not. Performance is not an abstract concept. It cannot be
argued about. It can only be measured.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
In article <11*********************@p79g2000cwp.googlegroups. com>, bu*************@gmail.com wrote:
This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ).
IE: void fn( const int foo );
Your talking about an issue that is local to one function. If the
functions are small enough that a programmer can easily tell if and
where the parameter is modified, I don't see where the const nets you
anything useful.
If your functions are so long that only Sherlock Holmes could tell what
is happening to a parameter, then the "const" keyword won't help much.
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
I don't see where the const keyword in this case gives you quick
comprehension...
- are those benefits really so high that you can ignore possible future
bugs ?
Again, you are assuming that the 'const' keyword in this case reduces
the possibility of bugs. I don't see it.
Victor Bazarov wrote:
bu*************@gmail.com wrote:
[...]
This whle thing belongs to 'comp.software-eng', really. I don't see
a *C++ language* problem here.
I posted it in c++ groups because the sw is written in c++ which I
forgot to mention, but I will repost it there.
The fact is that we develop time and memory critical system, but
overall such subtle memory and speed differences do not have critical
impact on the whole system since it runs on hardware which is powerful
and dimensed enough to host the sw; therefore, this is, IMHO, a
completely nonsense, and the questions are:
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
Why are you asking us? If *you* can't decide, who can? Every case is
different. Sometimes you need to squeeze every CPU tick, sometimes it
isn't that important.
Besides, this sounds (looks) like a rhetoric question. If you need some
kind of affirmation from us, you won't really get it. It's a toss-up.
And it's case-specific.
- are those benefits really so high that you can ignore possible
future bugs ?
Again, this sounds (looks) like a rhetoric question. Are you losing the
argument to your colleagues who don't think so? Here is my question:
*what* future bugs? Performance is sometimes paramount. When you get
any "future" bugs, deal with them. If (and it sounds like it) you have
the performance problem *now*, you have to deal with it in any way you
can. But you won't know whether you have the performance problem *until*
you measure for it.
Yes, I think you got the point. Further debate would be propabaly
pointless without proper measurement of resource usage.
- does it even make sense to reason in this context in terms like
speed and memory efficiency ?
Possibly not. Performance is not an abstract concept. It cannot be
argued about. It can only be measured.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Thank you very much!
In article <11*********************@p79g2000cwp.googlegroups. com>, bu*************@gmail.com says...
[ ... ]
.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ). The
compiler in this case checks of any assignment or possible change of
the parameter/variable and gives an potential error message, thus
ensuring robustness of the code and also, imho, by following this
convention the readability and understanding of the code for future
re/viewers is better.
[ ... ]
The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...
You're wrong and they're right, but not for the reasons they've
given.
Your position shows a fundamental misunderstanding of one of the most
basic ideas in all of software engineering: separation of interface
from implementation.
Specifically, the interface consists of the _externally visible_
behavior of the function. Anything and everything that's not
externally visible is implementation -- and external code has no
business knowing or caring about it at all.
In this case, the mistake is a subtle one -- for the most part, the
type of parameter taken by a function IS externally visible. Top-
level cv-qualifiers, however, do NOT specify an externally visible
behavior -- they specify only implementation.
As such, such top-level cv-qualifiers should be used only to the
extent that they make sense in terms of the implementation. Looking
at it in more concrete terms, the function receives a copy of the
value that was passed to it. While the TYPE of data matters to the
outside world, the copy itself is "owned" by the function, and it's
nobody else's business what the function does with its own data.
Your opinion that this will make the code easier to read and/or
understand is also wrong. In reality, it makes the code easier to
MISunderstand. In particular, you're attempting to act as if a cv-
qualified parameter creates a different type -- but you're wrong, and
the compiler knows you're wrong. If they were really different types,
you should be able to (for one example) overload based on that type
difference, such as in code like this:
void f(int) {}
void f(const int) {}
Assuming you use a compiler that works anywhere close to correctly,
it'll attempt to correct your misconception if you give it code like
this. For one example, Comeau C++ says: "error: function "f" has
already been defined". MS VC++ says: "function 'void f(int)' already
has a body".
Though it's a rarity, in this case, I'd say Microsoft's error message
is more informative than Comeau's -- it's much more clear about the
fact that your 'f(const int)' has a signature of 'f(int)', because
that's the real interface to the function.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Hello, bu*************@gmail.com wrote:
Hi guys!
This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
course, design requirements always more important and thus one should
always use const keyword with parameters whose values shouldn't get
changed inside a function ( lets call these ,In' parameters ). The
compiler in this case checks of any assignment or possible change of
the parameter/variable and gives an potential error message, thus
ensuring robustness of the code and also, imho, by following this
convention the readability and understanding of the code for future
re/viewers is better.
It is a wise decision to use const references for parameters as default.
Then the compiler can check that the const is respected in the called
function, and it has the freedom to create a copy instead of passing
the reference in those cases, where the copy is faster, e.g. for the
builtin types. This becomes important for templates, when different
kinds of types are used as parameters, then const references allow the
compiler to chose the best. That way the compiler might be able to use
CPU registers more efficiently in both the calling and the called
function.
E.g. an integer in a register in the calling function will be
transferred in registers to the called function, since it is const
reference the value will not be changed in the called function, so
nobody could miss a change to a copy. A large object, which is in
memory, will be passed by its address. Although it could be changed in
the called function, it won't because it is a const reference. Well,
there is mutable, but not critical here.
If you have an integer in a register and pass it via non-const
reference, the compiler will have to move the integer to the stack, and
pass its address there.
If you have a large object and pass it by value, then the copy
constructor will be called, which is not cheap.
Const reference is the only possibility to let the compiler do its best
in all cases.
The opposite opinion was based on fact, that when you need to
use/declare a local variable inside the function, the code is less
efficient (because you lose speed and memory usage is higher), since
you could you use a stack variable provided as a parameter ( and since
is it YOU who writes the body of a function YOU take care of proper
content of the variable ).
The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...
No it is not the same. Const for non-reference parameters does not
enable more efficient parameter handling. A copy will be created,
anyway, and the problem to be prevented, changing a copy, are only
delayed to the next copy created.
It is a good question, if someone does not realize that parameter by
value does not get its changes retransferred, then another copy won't
be recognized as a problem, as well.
The fact is that we develop time and memory critical system, but
overall such subtle memory and speed differences do not have critical
impact on the whole system since it runs on hardware which is powerful
and dimensed enough to host the sw; therefore, this is, IMHO, a
completely nonsense, and the questions are:
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
- are those benefits really so high that you can ignore possible
future bugs ?
- does it even make sense to reason in this context in terms like
speed and memory efficiency ?
Const without reference has low chances to improve efficiency.
Bernd Strieder bu*************@gmail.com wrote:
The opposite opinion was based on fact, that when you need to
use/declare a local variable inside the function, the code is less
efficient (because you lose speed and memory usage is higher), since
you could you use a stack variable provided as a parameter ( and since
is it YOU who writes the body of a function YOU take care of proper
content of the variable ).
Are you sure? Compilers are very smart nowdays. If you don't actually
change the parameter in question does it really make any difference, in
the executable code, whether you use it directly or first "copy" it
into a variable and use that variable? Could the compiler be smart
enough that it ignores the copy command entirely? Most are capable of
this at least with return values...
The debate was mainly about the parameters given by value, with
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...
There is no reason to use const on value parameters, as others have
stated. The const keyword is for when you want to show that your
object will not be changed by passing it into this function and it
otherwise could have been. So there is no benefit to using const in
this context.
- are the benefits gained in more efficient code worth of losing quick
comprehension of the code ?
Depends on the requirements. In general absolutely not as you will
need to modify most of your code later. Less understandable code leads
to changes that are inefficient.
- are those benefits really so high that you can ignore possible future
bugs ?
No.
- does it even make sense to reason in this context in terms like speed
and memory efficiency ?
Not really. You can keep it in mind as you code that certain practices
could be inefficient but you should never try to produce optimized code
before profiling.
Jerry Coffin wrote:
Your position shows a fundamental misunderstanding of one of the most
basic ideas in all of software engineering: separation of interface
from implementation.
Specifically, the interface consists of the _externally visible_
behavior of the function. Anything and everything that's not
externally visible is implementation -- and external code has no
business knowing or caring about it at all.
In this case, the mistake is a subtle one -- for the most part, the
type of parameter taken by a function IS externally visible. Top-
level cv-qualifiers, however, do NOT specify an externally visible
behavior -- they specify only implementation.
As such, such top-level cv-qualifiers should be used only to the
extent that they make sense in terms of the implementation. Looking
at it in more concrete terms, the function receives a copy of the
value that was passed to it. While the TYPE of data matters to the
outside world, the copy itself is "owned" by the function, and it's
nobody else's business what the function does with its own data.
I had this argument at work as well (I'm not the OP). I argued that
using cv qualifiers on parameters exposed implementation details
unnecessarily. Of course, I lost the argument. bu*************@gmail.com wrote:
Hi guys!
This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
.. Recently we've had at work a little talk about the way of providing
const modifier for function parameters. From my point of view are, of
[ snip ]
The debate was mainly about the parameters given by value, with
[ Attention to the "by value" part ]
reference parameters we basically agreed that const is useful, but in
essence this is imho the same...
You and your coworkers appear to be confused.
The const qualifier means almost nothing when it is the parameter
itself that is qualified. This comes from ANSI C. For instance, these
two type declarations are compatible:
int foo(const int x);
int foo(int x);
And in fact the declaration that you put into the header file can be:
int foo(const int);
and your function definition can still be:
int foo(int x)
{
}
or vice versa.
In other words, the qualifier does not affect the function interface.
So why are qualifiers on parameters allowed? It's because in a function
definition, they are, after all, just local variables. What makes
parameters special is that they receive their initial values from the
function arguments, but in other respects they are just locals. It's
useful to declare a parameter const for the same reasons that it's
useful to declare any other local variable const: to indicate that its
value is should not change, and obtain the related diagnostics.
In article <7b********************@newssvr21.news.prodigy.com >, no*****@here.dude says...
[ ... ]
I had this argument at work as well (I'm not the OP). I argued that
using cv qualifiers on parameters exposed implementation details
unnecessarily. Of course, I lost the argument.
You may have lost the argument, but you were mostly right.
One possibility to consider would be to put the qualifier there in
the function implementation (to the extent that it makes sense for it
to be there from the viewpoint of the implementation). Then, in the
header that exposes the function to the world, you leave the cv-
qualifier out of the declaration.
This avoids exposing the implementation detail to the world, while
maintaining the qualifier on those (admittedly rare) parameters for
which they really DO make sense. To the compiler (assuming it works
correctly) this is perfectly fine -- a function implemented as f
(const int) will match/link up with a declaration of f(int) just
fine.
--
Later,
Jerry.
The universe is a figment of its own imagination. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Montrose... |
last post by:
After working in c# for a year, the only conclusion I can come to is
that I wish I knew c.
All I need is Linux, the gnu c compiler and I can do anything.
Web services are just open sockets...
|
by: James Brown |
last post by:
Hi all,
Having problems designing a template-class. I'll describe my scenario
first then show what I've come up with so far:
Need a class to provide pointer/array-like access to an area of...
|
by: Paul Brown |
last post by:
I am confused - I have gone through a two day exercise tuning up an
FFT routine, and at the last stage I find that where the biggest gains
were expected, all my conventional understanding of...
|
by: yehoshua |
last post by:
Is there anyway to explicitly tell the garbage collector you are done
with an object? In my app I have a point where I am sure there should
be no references to an set of objects (well i remove...
|
by: PD |
last post by:
I am currently making a dating website.
I want to have some information on how to structure the database and
the php files so that I can achieve speed and efficiency.
Can some one please give...
|
by: Snis Pilbor |
last post by:
Hello,
Here is an idea I've been toying with to speed up programs but
still keep them portable. It's just a very handwavey rough description
right now since I haven't worked out details.
The...
|
by: vamshi |
last post by:
Hi all,
This is a question about the efficiency of the code.
a :-
int i;
for( i = 0; i < 20; i++ )
printf("%d",i);
b:-
int i = 10;
|
by: jphelan |
last post by:
Ever since I successfully applied some techniques for increasing the
speed of my 17 meg. Application; it has only made me hunger for more.
First, let me list what I have done so far:
1. Split...
|
by: christophe.chazeau |
last post by:
Hi,
I have a problem with a really simple chunk of code which should work
but does obviously does not.
This chunk of code is just a POC aimed at finding a bug in a larger
project in which the...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
