Thursday, June 25, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

JiiPee <no@notvalid.com>: Jun 20 11:54AM +0100

I pretty much understand const correctness. But there is one thing I do
not understand 100%:
 
class A
{
public:
int& foo() const // does not compile, should be: const int& foo() const
{
return p_;
}
private:
int p_;
};
 
This does not compile because there foo should return a const reference:
const int& foo() const
 
But why? Because to my understanding a const function ( "...foo() const"
) means that the *function foo* promises not to change the data members
of the object. If I return a reference to a member then foo is not
changing the data members, right? Yes, the caller can change the private
member later on, but foo did not. What am I not understanding correctly?
Or is it that the definition of const function: "the function is not
changing the state of the object" is not accurate but should be like
"the function is not changing the state of the object AND also the
caller cannot change the state of the object with the return value"?
 
What is the real and full definition of "const member function"?
Obviously it is not "the *function* promises not to change the data
members of the object". It is confusing because it seems like most of
the web sites seem to define it wrongly like that.
JiiPee <no@notvalid.com>: Jun 20 01:24PM +0100

On 20/06/2015 13:23, JiiPee wrote:
> int foo() const { return p_; }
> it would mean that we are doing a copy for the return value:
 
> int return = p_;
 
well, better would be "returnValue = ..." not to confuse with the
keyword return, but am sure you got it :)
JiiPee <no@notvalid.com>: Jun 20 01:23PM +0100

On 20/06/2015 12:41, Victor Bazarov wrote:
>> members of the object". It is confusing because it seems like most of
>> the web sites seem to define it wrongly like that.
 
> It has nothing to do with what 'foo' does to the object.
 
just to clarify,
"it" - are you refering here to the definition of the "const member
function"?
 
> 'foo'. When you try to return 'p_', it is constant, and the compiler
> would have to convert a const lvalue to a non-const lvalue in order to
> bind the reference (the return value) to it. *That* is prohibited.
 
ok, so we can think that p_ (after declaring the function as const
function) becomes like:
const int p_;
And then for example for:
int foo() const { return p_; }
it would mean that we are doing a copy for the return value:
int return = p_;
which works because const can be copied to an int.
But with reference return value it would be like:
int& return = p_;
which is not working because non-const ref cannot refer to a const. Right?
 
If I see it like this then its easy to understand....
"Öö Tiib" <ootiib@hot.ee>: Jun 25 06:06AM -0700

On Thursday, 25 June 2015 15:51:24 UTC+3, gwowen wrote:
 
> template<class T> T::valuetype f(const T&t) {
> ...
> } // works ok
 
It is for cases like
 
template<class A, class B>
decltype( *static_cast<A*>(nullptr) * *static_cast<B*>(nullptr) ) multiplication(A const &a, B const &b )
{
return a * b;
}
David Brown <david.brown@hesbynett.no>: Jun 25 03:51PM +0200

On 25/06/15 15:06, 嘱 Tiib wrote:
> {
> return a * b;
> }
 
Which you would write as:
 
template<class A, class B>
auto multiplication(A const &a, B const &b) -> decltype(a * b)
{
return a * b;
}
 
 
With C++14, you could omit the return type entirely here:
 
template<class A, class B>
auto multiplication(A const &a, B const &b)
{
return a * b;
}
 
You only need the explicit return type in C++14 if there are multiple
return statements leading to ambiguous return type deduction:
 
template<class A, class B>
auto multiplication(A const &a, B const &b) -> decltype(a * b)
{
if (a == 0) return 0;
if (b == 0) return 0;
return a * b;
}
gwowen <gwowen@gmail.com>: Jun 25 07:23AM -0700

On Thursday, June 25, 2015 at 2:51:21 PM UTC+1, David Brown wrote:
 
> {
> return a * b;
> }
 
Ah yes, I'd overlooked decltype. Thank you (and to Öö). Definitely useful there. It'd be nice to have a decltype-equiv that works on types...
 
// obviously issues with free functions v. member functions for operator*
template <class A,class B> decltype(operator*(const A&,const B&))
func(const A&a,const B&b){....}
"Öö Tiib" <ootiib@hot.ee>: Jun 25 08:08AM -0700

On Thursday, 25 June 2015 17:23:12 UTC+3, gwowen wrote:
> > return a * b;
> > }
 
> Ah yes, I'd overlooked decltype. Thank you (and to Öö). Definitely useful there. It'd be nice to have a decltype-equiv that works on types...
 
There actually is ... the 'std::result_of' in <type_traits> (loaned from boost).
It is less powerful than 'decltype' but also sometimes less ugly. Its
main shortcoming is that it does not work with built-in operators
that you possibly may want to invoke in your example below.
 
alf.p.steinbach@gmail.com: Jun 25 08:49AM -0700

On Thursday, June 25, 2015 at 12:07:39 PM UTC+2, gwowen wrote:
 
> The question was, what's the advantage?
 
Thank you for clarifying your earlier posting. I failed to infer that meaning from your earlier
 
> Is this from some sort of competition to the write least-comprehensible and backward-compatible code possible?
 
I read that as just a trolling maneuver.
 
Likewise, the following paragraph you posted,

> What is the possible benefit of saying "please infer the return type (the answer is int, by the way)"?
 
didn't strike me as technically meaningful, so I reasoned it was just trolling again.
 
But now, with your clarification, I, and possibly others, understand that you really meant to /ask/, "what's the advantage". And even though that question contains an unwarranted assumption of a single main advantage, it's answerable.
 
If you would care to ask that, possibly modified to get rid of the assumption, and not introducing more of that earlier difficult-to-read-as-other-than-trolling stuff, i.e. like "What are the advantages of this notation?", in direct response to my code, then if I happen to see it (I do not visit here often) I'll try to answer it. Or you may look at SO, where it's been answered numerous times.
 
Cheers & hth.,
 
- Alf
bartekltg <bartekltg@gmail.com>: Jun 19 01:23PM +0200

On 16.06.2015 21:12, Paul wrote:
> ages to do. Any insights on how I can improve it? The problem is
> stated more accurately in the initial comments. Many thanks for your
> help.
 
 
Use stack, so you dont have to recompute previous part of
a expression. This stack have exactly the same function as
hardware stack during recursion, but at the end you can
easily read from all levels.
 
It is quite convinient to build expresion from the end,
and add operator on the right.
Operations in string "...-67+89" will be
"concatenate 9"
"add 8"
"concatenate 7"
"minus 6"
 
The last one (1) is treated as "+1".
 
 
 
bartek@Kotoputerek:~/QTproj/build-stack_comp_lang_cpp-Desktop_Qt_5_4_1_GCC_64bit-Release$
time ./stack_comp_lang_cpp
+1+23-4+56+7+8+9
+12+3-4+5+67+8+9
+1+2+34-5+67-8+9
+1+2+3-4+5+6+78+9
+123-4-5-6-7+8-9
+123+45-67+8-9
+1+23-4+5+6+78-9
+12-3-4+5-6+7+89
+12+3+4+5-6-7+89
+123-45-67+89
+123+4-5+67-89
 
real 0m0.003s
user 0m0.001s
sys 0m0.002s
 
 
**************
 
#include <iostream>
#include <stack>
 
using namespace std;
 
class state
{
public:
int accumulator;
int next_val;
int digits;
char last_op;
 
void res() {
cout<<accumulator<<" "<<next_val<<endl;
}
 
state():accumulator(0),next_val(0),digits(1),last_op(' '){}
 
void plus(int x) {
accumulator+= x*digits + next_val;
next_val = 0;
digits=1;
last_op = '+';
}
void minus(int x) {
accumulator-=x*digits + next_val;
next_val = 0;
digits=1;
last_op = '-';
}
void conc(int x){
next_val += digits*x;
digits*=10;
last_op = ' ';
}
};
 
 
 
stack<state> St;
 
void search ( int n )//main recursion
{
 
if (n==1) { // the last level
state s = St.top();
s.plus(n);
St.push(s);
if (s.accumulator==100) {
stack<state> stack_copy(St);
int i=1;
while (stack_copy.size()>1) //we have one dummy
{
s=stack_copy.top();
stack_copy.pop();
if (s.last_op==' ')
cout<<i;
else
cout<<s.last_op<<i;
i++;
}
cout<<endl;
}
St.pop();
}
else { //not the prettiest part. Add updated state to the
stack, run recursion, delete the state you just put from stack, repeat
for next two operations
state s = St.top();
s.plus(n);
St.push(s);
search(n-1);
St.pop();
 
s = St.top();
s.minus(n);
St.push(s);
search(n-1);
St.pop();
 
s = St.top();
s.conc(n);
St.push(s);
search(n-1);
St.pop();
}
}
 
 
int main()
{
St.push(state());//dummy
search(9);
return 0;
}
bartekltg <bartekltg@gmail.com>: Jun 19 01:47PM +0200

On 18.06.2015 19:07, Paul wrote:
 
> I got the problem from here: https://blog.svpino.com/2015/05/07/five-programming-problems-every-software-engineer-should-be-able-to-solve-in-less-than-1-hour
 
For more math oriented problems you can look at
https://projecteuler.net/
First several dozens are very easy, the newest are mostly
hardcore algebra and number theory, but it contain many
interesting and doable problems.
 
 
bartek
Luca Risolia <luca.risolia@linux-projects.org>: Jun 19 02:40PM +0200

On 18/06/2015 16:53, Victor Bazarov wrote:
> possible solution # 4744 : 1+23-4+5+6+78-9
> possible solution # 5274 : 123+45-67+8-9
> possible solution # 5823 : 123-4-5-6-7+8-9
 
Are those supposed to be ALL the possible solutions?
 
I don't see -1 +2 -3 +4 +5 +6 +78 +9 in the list, for example.
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 19 09:03AM -0400

On 6/19/2015 8:40 AM, Luca Risolia wrote:
>> possible solution # 5823 : 123-4-5-6-7+8-9
 
> Are those supposed to be ALL the possible solutions?
 
> I don't see -1 +2 -3 +4 +5 +6 +78 +9 in the list, for example.
 
The specification was that the arithmetic signs shall be placed *between
the digits*.
 
V
--
I do not respond to top-posted replies, please don't ask
Luca Risolia <luca.risolia@linux-projects.org>: Jun 19 03:10PM +0200

On 19/06/2015 14:24, Rosario19 wrote:
 
> +1+23-4+5+6+78-9==100 op=1 0 2 1 1 1 0 2
> +123+45-67+8-9==100 op=0 0 1 0 2 0 1 2
> +123-4-5-6-7+8-9==100 op=0 0 2 2 2 2 1 2
 
It seems that this one is not a solution because of the leading '-':
 
Christian Gollwitzer <auriocus@gmx.de>: Jun 19 03:56PM +0200

Am 19.06.15 um 14:24 schrieb Rosario19:
> #define u32 unsigned
> #define i32 int
> [...]
 
Are you preparing your submission to IOCCC?
 
Christian
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 19 11:39AM -0400

On 6/19/2015 11:36 AM, Stefan Ram wrote:
>> Here is my attempt to generate all possible sequences:
 
> Here's my attempt to print all terms summing up to 100:
> [..]
 
It is actually gratifying to see that all solutions are quite similar.
 
V
--
I do not respond to top-posted replies, please don't ask
Rosario19 <Ros@invalid.invalid>: Jun 19 06:13PM +0200

On Thu, 18 Jun 2015 10:53:42 -0400, Victor Bazarov wrote:
> cout << ss << endl;
> }
>}
 
not compile with these errors:
Error E2108 m.cpp 8: Improper use of typedef 'string'
Error E2293 m.cpp 8: ) expected
Error E2141 m.cpp 83: Declaration syntax error
*** 3 errors in Compile ***
Rosario19 <Ros@invalid.invalid>: Jun 19 06:15PM +0200

On Fri, 19 Jun 2015 15:56:38 +0200, Christian Gollwitzer wrote:
>> [...]
 
>Are you preparing your submission to IOCCC?
 
> Christian
 
for me the IOCCC ones, are the ones posted in this thread in C++;
i understand little in their C++ code, library use etc etc
i understand at first see, instead, what the above code does [or seems
to me so]
 
how one easy problem seen using some goto, some array and pointers in
C became difficult in C++ using hevy libraries etc
 
what is IOCCC became readable
and what would be readable is IOCCC (even the C++ compiler here not
compile one of these examples)
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 19 01:05PM -0400

On 6/19/2015 12:13 PM, Rosario19 wrote:
> Error E2293 m.cpp 8: ) expected
> Error E2141 m.cpp 83: Declaration syntax error
> *** 3 errors in Compile ***
 
Can't help you, sorry. Compiles for me fine. And if you include
<cmath>, compiles on G++ v4.8.3 online as well. Make sure your compiler
is C++11 compliant (at implements 'decltype').
 
V
--
I do not respond to top-posted replies, please don't ask
legalize+jeeves@mail.xmission.com (Richard): Jun 19 05:17PM

[Please do not mail me a copy of your followup]
 
Victor Bazarov <v.bazarov@comcast.invalid> spake the secret code
 
>Can't help you, sorry. Compiles for me fine. And if you include
><cmath>, compiles on G++ v4.8.3 online as well. Make sure your compiler
>is C++11 compliant (at implements 'decltype').
 
And for gcc/clang be sure to use '-std' with an appropriate value.
(Why this isn't set to -std=c++11 as the default on a compiler that
implements C++11, I don't understand.)
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Victor Bazarov <v.bazarov@comcast.invalid>: Jun 19 12:05PM -0400

On 6/19/2015 11:51 AM, gwowen wrote:
>>> [..]
 
>> It is actually gratifying to see that all solutions are quite similar.
 
> Maybe, but I am slightly amazed how many of them use recursion.
 
I am not sure I am reading the meaning of your statement correctly. Do
you consider recursion superfluous? And, in general, what's your take,
is recursion OK or, if another solution (a loop, perhaps) exists,
recursion should be avoided?
 
V
--
I do not respond to top-posted replies, please don't ask
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 25 05:17PM +0100

On Thu, 25 Jun 2015 08:49:42 -0700 (PDT)
> > type (the answer is int, by the way)"?
 
> didn't strike me as technically meaningful, so I reasoned it was just
> trolling again.
 
It hasn't taken you very long to get back to your "everyone who
disagrees with me is a troll" meme. Try hard to avoid it if you can:
not everyone will always agree with you, however poorly they explain
their disagreement to your satisfaction.
 
Chris
gwowen <gwowen@gmail.com>: Jun 25 09:21AM -0700


> > What is the possible benefit of saying "please infer the return type (the answer is int, by the way)"?
 
> didn't strike me as technically meaningful, so I reasoned it was just trolling again.
 
Well, there's a surprise.
bartekltg <bartekltg@gmail.com>: Jun 20 02:21PM +0200

On 20.06.2015 08:26, gwowen wrote:
> On Saturday, June 20, 2015 at 7:16:50 AM UTC+1, gwowen wrote:
>> I'd be interested to see how you got O(3^n) for the recursive version.
>> Not questioning it, just interested.
 
This post was superseded or my server lost it?
 
I have posted the solution in this thread earlier:
Message-ID: <mm0u43$7ie$1@node1.news.atman.pl>
Not the prettiest one, but I think quite readable.
 
> No need Bart, I thought about it and I see now. That's definitely a
> win for recursion when n gets large (as long as you can avoid
> smashing the stack). Tail-recursion would help.
 
In this particular problem when a stack is to short,
life of the universe is to short to finish the computation too ;-)
 
I have no idea how good gcc is with tail-recursion (gcc is not ocaml;-)
In my code t-r is not used (A looked at asm output, three recursive
calls, and with tail-recursion should be two). But simple factorial
code gcc compile correctly to loop.
 
int factorial (int x){
if (x>1) return x*factorial(x-1);
else return x;
}
 
.type _Z9factoriali, @function
_Z9factoriali:
.LFB1879:
.cfi_startproc
cmpl $1, %edi
jle .L50
movl $1, %edx
.p2align 4,,10
.p2align 3
.L49:
leal -1(%rdi), %eax
imull %edi, %edx
cmpl $1, %eax
movl %eax, %edi
jne .L49
.L48:
imull %edx, %eax
ret
.L50:
movl %edi, %eax
movl $1, %edx
jmp .L48
 
 
bartekltg
JiiPee <no@notvalid.com>: Jun 20 11:59AM +0100

On 13/06/2015 00:56, Victor Bazarov wrote:
>> »-« operator in their Google search specifications.
 
> Pfft! Real programmers never read manuals! ;-)
 
> V
 
More commonly: Men do not read manuals when buying something and start
using it
Rosario19 <Ros@invalid.invalid>: Jun 20 07:50AM +0200

On Sat, 20 Jun 2015 00:41:07 +0200, David Brown wrote:
 
>seldom smaller than a few nH. You might use pH for the inductance of
>wires, chip pins/balls, pcb vias, etc.
 
>Usually it's clear in the context what you mean by pH.
 
PH whould be a misure for acid-base
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)