Thursday, October 30, 2014

Digest for comp.lang.c++@googlegroups.com - 15 updates in 3 topics

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 01:42PM -0700

Why does g++ generate this warning?
 
----[ Start ]-----
 
#include <stdio.h>
 
void test_function(int* tnX)
{
*tnX++; // Warning "value computed is not used [-Wunused-value]"
}
 
int main(int argc, char* argv[])
{
int lnI, tnLevel;
 
for (lnI = 0, tnLevel = 0; lnI < 10; lnI++)
test_function(&tnLevel);
 
printf("%u\n", tnLevel);
return(0);
}
 
----[ End ]-----
 
I would think g++ would suppress this particular warning because the
data being updated was passed in as a parameter, which means it is
updating something external to itself.
 
I would expect it to warn something else, like:
 
"value computed is not used locally"
^^^^^^^
 
Best regards,
Rick C. Hodgin
Christopher Pisz <nospam@notanaddress.com>: Oct 30 04:14PM -0500

On 10/30/2014 3:42 PM, Rick C. Hodgin wrote:
> ^^^^^^^
 
> Best regards,
> Rick C. Hodgin
 
Yucky C style code, making it error prone.
 
What do you think *tnX++ is doing? What is the operator precedence
there? I'd look it up (I just did) and it means bad things for that code.
 
This has worse problems than the warning.
 
 
Why not:
 
#include <iostream>
 
void test_function(int & tnX)
{
++tnX;
}
 
int main(int argc, char* argv[])
{
for (int lnI = 0, int tnLevel = 0; lnI < 10; ++lnI)
{
test_function(&tnLevel);
}
 
std::cout << tnLevel << std::endl;
return 0;
}
 
 
or:
 
 
#include <iostream>
 
int test_function(const int tnX)
{
return ++tnX;
}
 
int main(int argc, char* argv[])
{
for (int lnI = 0, int tnLevel = 0; lnI < 10; ++lnI)
{
test_function(&tnLevel);
}
 
std::cout << tnLevel << std::endl;
return 0;
}
 
 
or if you must use printf:
 
 
#include <cstdio>
 
int test_function(const int tnX)
{
++tnX;
}
 
int main(int argc, char* argv[])
{
for (int lnI = 0, int tnLevel = 0; lnI < 10; ++lnI)
{
test_function(&tnLevel);
}
 
printf("%u\n", tnLevel);
return 0;
}
 
 
 
and why wrap the return value in parenthesis?
return (0)....
Are you telling the compiler, "Hey! You better figure out what zero
means before you return it?"
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 02:48PM -0700

On Thursday, October 30, 2014 5:14:51 PM UTC-4, Christopher Pisz wrote:
> Yucky C style code, making it error prone.
 
> What do you think *tnX++ is doing?
 
Increasing the int pointed to by tnX. I see from your cue below,
and in looking at the disassembly, that it is not, hence the warning.
 
> What is the operator precedence there? I'd look it up (I just did)
> and it means bad things for that code.
 
It disassembles in GDB to this:
 
0x004016b0 push ebp
0x004016b1 mov ebp,esp
0x004016b3 int3 // Breakpoint added
0x004016b4 mov eax,DWORD PTR [ebp+0x8] // Read tnX
0x004016b7 add eax,0x4 // Increase by sizeof(int)
0x004016ba mov DWORD PTR [ebp+0x8],eax // Store tnX
0x004016bd pop ebp
0x004016be ret
 
That's why. Thank you. Fixed. :-)
 
 
> std::cout << tnLevel << std::endl;
> return 0;
> }
 
To answer your question, I don't like using parameters of the form
int& because they hide the underlying operation in a line-by-line
examination of the source code.
 
I don't like that because it leads to confusion.
 
> return (0)....
> Are you telling the compiler, "Hey! You better figure out what zero
> means before you return it?"
 
I prefer to put return values in parenthesis because it makes it easier
for me to read. I don't know why. It's also the same reason I
vertically align everything in my code to an almost obsessive degree.
 
:-)
 
Best regards,
Rick C. Hodgin
jacob navia <jacob@spamsink.net>: Oct 30 10:53PM +0100

Le 30/10/2014 22:14, Christopher Pisz a écrit :
> Yucky C style code, making it error prone.
Yeah of course "C style". You can't help it.
 
Each time you see a bug in C++ code it is "C style" bug.
 
Even if it is 100% LEGAL C++ CODE!
 
The code has an error. Yes. But it is not necessary nor even justified
to go on with your "anti C " campaign.
Christopher Pisz <nospam@notanaddress.com>: Oct 30 05:26PM -0500

On 10/30/2014 4:53 PM, jacob navia wrote:
 
> Even if it is 100% LEGAL C++ CODE!
 
> The code has an error. Yes. But it is not necessary nor even justified
> to go on with your "anti C " campaign.
 
(good)C++ programmers don't use #include <stdio.h>, (most)C programmers do.
 
(good) C++ programmers don't usually pass raw pointers to public methods
or global functions, (most) C programmers do
 
(good) C++ programmers certainly would check if the pointer was null
before using it, (most) C programmers rely on foreknowledge and would
say, "Well, we just know the pointer has to be initialized before using
it", that's the way this API works.
 
This was a very good example of how C style code creates unexpected
errors. If he has passed the int by reference or by one of the many C++
constructs to manage pointers, then the error would have never occurred.
 
and you can see by his responses to why he didn't pass it by reference
and why he returns (0) instead of returning 0, that he is a C style
programmer, because he chalks it up to his personal preference and as is
the case all too often with C style code, that personal preference made
the code more error prone.
 
When "my preference" > "maintainability" we have a problem.
Christopher Pisz <nospam@notanaddress.com>: Oct 30 05:32PM -0500

On 10/30/2014 4:22 PM, Martin Shobe wrote:
> On 10/30/2014 3:42 PM, Rick C. Hodgin wrote:
SNIP
 
> The '++' operator takes precedence over the '*' operator so the line in question
 
True.
 
> ....takes the value of tnX, increments it, returns the old value of tnX,
> dereferences tnX, and discards the result.
 
Disagree.
 
tnX is a pointer. Operator ++ on a pointer is going to increment the
pointer. The pointer is now pointing to memory that the method has no
business looking at. Then we are dereferencing that memory and doing
nothing with it.
 
am I wrong?
Barry Schwarz <schwarzb@dqel.com>: Oct 30 03:39PM -0700

On Thu, 30 Oct 2014 17:32:18 -0500, Christopher Pisz
>business looking at. Then we are dereferencing that memory and doing
>nothing with it.
 
>am I wrong?
 
Yes, you are wrong. It is true that the ++ post-increment operator
increments the value of its operand. However, that incremented value
does not participate in any other operations until a sequence point is
reached. The ++ post-increment operator evaluates to the
un-incremented value of its operand. The incrementing is often
referred to as a side affect.
 
a = 5;
b = a++;
c = ++a;
 
b will be 5. c and a will both be 7.
 
--
Remove del for email
Christopher Pisz <nospam@notanaddress.com>: Oct 30 05:43PM -0500

On 10/30/2014 5:39 PM, Barry Schwarz wrote:
> b = a++;
> c = ++a;
 
> b will be 5. c and a will both be 7.
 
boo, I hate being wrong. but realized that as soon as I saw the response
:P postfix...5 o clock...brain tired.
Luca Risolia <luca.risolia@linux-projects.org>: Oct 30 11:45PM +0100

Il 30/10/2014 23:32, Christopher Pisz ha scritto:
> business looking at. Then we are dereferencing that memory and doing
> nothing with it.
 
> am I wrong?
 
Why don't you try?
 
int a[2] = {0, 1};
int* tnX = a;
assert(*tnX++ == 0);
Martijn Lievaart <m@rtij.nl.invlalid>: Oct 30 08:55AM +0100

On Wed, 29 Oct 2014 16:04:02 +0000, Scott Lurndal wrote:
 
 
> As a thought experiment, whose result would invariably be "don't do
> this",
> perhaps.
 
Agree.

> Bad enough having them in filenames.
 
Don't agree at all. Besides the obvious arguments, those are here to stay
so we'ld better accommodate them.
 
Now a CR and/or LF in a filename, that's obscene. (but possible, so
account for it).
 
M4
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 30 10:28AM

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> The thing about adding the ability to use spaces into a language, and
> therefore make it more human-friendly,
 
Just help the discussion along a bit, you are confusing two separate
things: the presentation with the name. They can be separated. Algol
68 permitted names to be written with spaces, but the spaces were not
part of the name. This is, of course, ordinary spaces, not some special
space-like character code. It meant that accidentally typing two spaces
instead of one did not make a different name.
 
<snip>
--
Ben.
drew@furrfu.invalid (Drew Lawson): Oct 30 01:20PM

In article <61dfd69d-8340-4662-985a-3b970ab4de8f@googlegroups.com>
>character. Surely someone has thought of this before. Surely?? I
>mean it's clear as an empty character there in extended ASCII character
>code 255. It looks just like a space even. :-)
 
Actually, with my normal dev setup, 0xFF looks like a question mark.
In my 2nd choice environment, it looks like \ff with highlighting.
 
I'd never willingly develop code in an editor that hides the
difference between two distinct characters.
 
 
 
--
Drew Lawson So risk all or don't risk anything
You can lose all the same
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 07:04AM -0700

On Thursday, October 30, 2014 9:20:42 AM UTC-4, Drew Lawson wrote:
> In my 2nd choice environment, it looks like \ff with highlighting.
 
> I'd never willingly develop code in an editor that hides the
> difference between two distinct characters.
 
I would not use the default font's character for this, but instead I
would display it as I have indicated, a half-space with some coloring
around it. You would only ever see it as a space in my editor because
I would graphically be manipulating what is displayed to show it that
way.
 
I'll get this coded soon (James 4:15) and demonstrate it to everybody.
Perhaps even tonight as I'm finally done with another project that's
consumed the last couple of weeks.
 
Best regards,
Rick C. Hodgin
"Chris M. Thomasson" <no@spam.invalid>: Oct 29 09:44PM -0700


> The compiler would've caught that. I just typed it off the top of
> my head. :-) RDC also has only public members, so the public/private
> are superfluous as well.
 
No problem.
 
:^)
 
[...]
Juha Nieminen <nospam@thanks.invalid>: Oct 30 12:31PM

> Thanx, the following syntax do compile :
 
> template <typename First, typename... Rest>
> Toto(const First & first, const Rest&... rest):subToto_(rest...){}
 
In general, the ... syntax for variadic templates goes like this:
 
In the template declaration you use "typename... [name]" to indicate
a variable amount of parameters. (Could also be "[type]... [name]",
eg "int... Values", but that's besides the point.)
 
Then wherever you are going to use the typename [name], you use
the entire type expression and append "..." to it.
 
For example "const Rest&..." means that each of the types will be
expanded as "const [the specified type]&".
 
The place where you use the actual parameter, you can write any
expression you want, and append "..." to it, which means that the
expression will be repeated for each of the specified types, separated
by commas. In other words, something like this is completely valid:
 
template<typename... T>
void foo(const T&... parameters)
{
int results[] = { someFunction(parameters)... };
}
 
Notice that "someFunction(parameters...)" would be different from
"someFunction(parameters)...". The former means that all the parameters
are given to the single function call (which must of course support
being given a variable number of parameters), while the latter means
that a "someFunction()" call will be created for each parameter (in
other words, said function just takes one parameter), and all these
calls basically separated with commas.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)