Saturday, September 5, 2015

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

Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 05 01:22PM +0200

I have a code fragment to assign a local reference. Because references
must be initialized immediately I used a lambda as work around.
 
enum mux
{ M_R0,
M_R1
//...
};
enum ctx
{ IC_NONE,
IC_MUL,
IC_B
//...
};
 
ctx InstCtx;
mux MuxAA;
mux MuxAB;
mux MuxMA;
mux MuxMB;
 
mux& ret = [this]() -> mux&
{ switch (InstCtx & (IC_MUL|IC_B))
{case IC_NONE:
return MuxAA;
case IC_B:
return MuxAB;
case IC_MUL:
return MuxMA;
default:
return MuxMB;
}
}();
 
Is this possible without the lambda (or the ugly ?: operator)?
Does the lambda cause any runtime overhead?
 
In old style C a variable of type mux* and a switch does the job.
But I avoid raw pointer in C++ where possible.
 
 
Marcel
"Öö Tiib" <ootiib@hot.ee>: Sep 05 10:57AM -0700

On Saturday, 5 September 2015 14:22:51 UTC+3, Marcel Mueller wrote:
> }();
 
> Is this possible without the lambda (or the ugly ?: operator)?
> Does the lambda cause any runtime overhead?
 
Your pseudocode above leaves impression that you use reference to
local non-static variable as return value ('ret'?). If that is true
then that is obviously defect. Write real code that does compile
instead of such pseudocode; it is just few lines more but improves
communications with others tremendously.
 
Sure, complex logic (like that ?: chain) can be often replaced with
lookup table or ordinary inline function or member function.
 
I don't feel lambda is needed for that. I use lambda when I need to
store or pass (as argument or return value) a function that is
already instrumented with some of input data.
 
Real compilers optimize these very well and often optimize code that uses
references better than code that uses pointers. C++ standard does
not guarantee anything of it. If performance matters then just profile
things at end of life-cycle during stress- and limitation-testing
regardless of what style you use.
 
 
> In old style C a variable of type mux* and a switch does the job.
> But I avoid raw pointer in C++ where possible.
 
Makes sense! 'mux&' has to be initialized, can not be changed and
may not be null and its declaration and usage syntax is more terse
than that of 'mux*const'.
Luca Risolia <luca.risolia@linux-projects.org>: Sep 05 10:03PM +0200

Il 05/09/2015 13:22, Marcel Mueller ha scritto:
> must be initialized immediately I used a lambda as work around.
 
> mux& ret = [this]() -> mux&
> { switch (InstCtx & (IC_MUL|IC_B))
 
auto& ret = [this]() noexcept -> mux&
 
or
 
decltype(auto) ret = [this]() noexcept -> mux& // C++14
 
the approach is ok.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 05 10:04PM +0200

On 05.09.15 19.57, Öö Tiib wrote:
> Your pseudocode above leaves impression that you use reference to
> local non-static variable as return value ('ret'?). If that is true
> then that is obviously defect.
 
No. Logically the function really returns a value in one of the Mux
fields, but the signature returns void.
 
> Write real code that does compile
> instead of such pseudocode; it is just few lines more but improves
> communications with others tremendously.
 
Well, the code fragment is copied from a source file, in fact a GPU
assembler, but without the context of the surrounding (rather large)
class it makes no much sense.
 
But you are right. Only a few more lines made it compile
 
enum mux
{ M_R0,
M_R1
//...
};
enum ctx
{ IC_NONE,
IC_MUL,
IC_B
//...
};
 
struct test
{
ctx InstCtx;
mux MuxAA;
mux MuxAB;
mux MuxMA;
mux MuxMB;
 
void method()
{
mux& ret = [this]() -> mux&
{ switch (InstCtx & (IC_MUL|IC_B))
{case IC_NONE:
return MuxAA;
case IC_B:
return MuxAB;
case IC_MUL:
return MuxMA;
default:
return MuxMB;
}
}();
 
ret = M_R1; // example
}
};
 
int main()
{
test t;
t.InstCtx = IC_B; // example
t.method(); // write to MuxAB
 
return 0;
}
 
> not guarantee anything of it. If performance matters then just profile
> things at end of life-cycle during stress- and limitation-testing
> regardless of what style you use.
 
Performance is no killer in /this/ case. I just wanted to know what is
going on and whether there is prettier solution.
 
Just had a look to the assembler code. It made absolutely no difference
whether I use the lambda function or the old C style pointer syntax
(with optimizations).
Only when I create a dispatch table of type static mux test::*const
map[] on my own a more efficient code (shorter, no conditional branches)
is generated.
 
 
 
> Makes sense! 'mux&' has to be initialized, can not be changed and
> may not be null and its declaration and usage syntax is more terse
> than that of 'mux*const'.
 
Indeed.
 
Furthermore, I had to change several line of code in this case. The
function previously returned mux (no reference) and the assignment was
up the the caller which usually knows the right target field. But this
raised problems of deep sub functions that rely on the value to be
assigned sooner to perform some consistency checks. So I refactored the
code to identify the target field from the invocation context InstCtx.
 
 
Marcel
Paavo Helde <myfirstname@osa.pri.ee>: Sep 05 03:13PM -0500

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote in
 
> ret = M_R1; // example
> }
> };
 
I don't understand; if MuxAA et al are member variables and you do not
like a lambda, what prevents you from writing a member function returning
a reference to the needed member variable?
 
p.
ram@zedat.fu-berlin.de (Stefan Ram): Sep 05 07:07PM

>Is this possible without the lambda (or the ugly ?: operator)?
>Does the lambda cause any runtime overhead?
 
»?:« is not ugly, but »switch« might be more efficient
because it could use a lookup array in some cases.
 
Whether the lambda causes overhead, might depend on the
C++ implementation used (measure?).
 
(Whether using a reference is a feasible and good approach
here, can not easily be told from the fragments given.)
David Brown <david.brown@hesbynett.no>: Sep 05 02:45PM +0200

On 04/09/15 16:11, Mr Flibble wrote:
 
> Some guy that the fictional Jesus Christ may have been partially based
> on and the fictional Jesus Christ ARE NOT THE SAME INDIVIDUAL. Jesus
> Christ never existed.
 
Your problem here is that you imagine there are two people here - the
real, historical person, and the religious character crucial to
Christianity.
 
 
Let's take this step by step - do you agree or disagree on the following
points?
 
 
It looks like you now agree that there is some basis for claiming the
existence of the historical Jesus as a person (and if you don't agree on
that, I recommend you learn a little archaeology before you further
display your ignorance). There are, as I said, a few events in the life
of Jesus that have reasonably reliable corroboration - enough to make it
highly unlikely that there was no teacher/preacher named (approximately)
Jesus working around the 4th decade AD. Most of the "normal" events in
his life, as described in the Bible, have no evidence. And for some
things, such as his death, it is arguably surprising that there is no
other evidence.
 
You say there is no evidence for the "divine" Jesus, able to perform
miracles, rising from death, and so on. That is perfectly true - no
real, concrete evidence exists for anything supernatural like that.
It's a matter of faith and belief (though of course people who believe
in Jesus may describe things as "evidence" for his existence). That's
all a matter of choice and personal believe.
 
OK so far?
 
 
Where you seem to differ from everyone else is that you want to separate
these two aspects of Jesus, as though there was one historical person,
and one fictional person. That is simply not the case. For people who
believe in the divine Jesus, they are the same person - it is critical
to their faith that he was a real, ordinary person as well as the Son of
God. For people who /don't/ believe in a divine Jesus, the divine
aspects of Jesus were imaginary (either his own imagination, or that of
his followers). So the only Jesus is the historical one. Either way,
there was only one Jesus.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 05 07:45PM +0100

On 05/09/2015 00:24, Daniel wrote:
 
>> Turing test: false. Consciousness level of author detected: 0, because
>> algorithm matches exactly with what I predicted.
 
> The problem is that Mr Flibble is outside his field, and isn't familiar with the scholarly work, but still feels it necessary to make utterances. Had he read a bit about the minimalist position on the authenticity of the texts, he would have been able to engage with David in an interesting way, but he obviously hasn't.
 
Theology is not scientific and is arguably not scholarly either.
 
There is absolutely no evidence whatsoever that King David or Jesus
Christ existed, none.
 
 
> In much the same way, and just to bring this back on topic, it's rarely interesting to read something critical about C++ from somebody who doesn't know anything about C++.
 
Random assertion; I suspect I know more about C++ than you mate.
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 05 07:47PM +0100

On 05/09/2015 13:45, David Brown wrote:
 
> Your problem here is that you imagine there are two people here - the
> real, historical person, and the religious character crucial to
> Christianity.
 
No I do not imagine there was a historical Jesus Christ; the fictional
Jesus Christ may have been partially based on one or more individuals
which isn't saying the same thing. Jesus Christ never existed.
 
There is absolutely no contemporary evidence for Jesus Christ's
existence, none.
 
/Flibble
SG <s.gesemann@gmail.com>: Sep 05 05:45AM -0700

Am Freitag, 4. September 2015 13:25:26 UTC+2 schrieb DeMarcus:
> PS. No I'm not paid to write this, it's just that Alexandrescu's books,
> talks, and work in general have contributed a lot to the programming
> community and to me personally. :)
 
I've watched lots of D presentations by Alexandrescu but for some
reason nothing resonated with me. Are there any key features that
made you like D or is it just the overall feel and interaction of
many smaller properties that makes programming in D fun for you?
 
(Personally, I find another language much more attractive as C++
alternative. No, it's not Go.)
 
Cheers!
SG
"Öö Tiib" <ootiib@hot.ee>: Sep 05 10:59AM -0700

On Saturday, 5 September 2015 15:45:27 UTC+3, SG wrote:
> many smaller properties that makes programming in D fun for you?
 
> (Personally, I find another language much more attractive as C++
> alternative. No, it's not Go.)
 
So it is rust then.
Laszlo Lebrun <lazlo.lebrun@googlemail.com>: Sep 05 03:01PM

On Mon, 31 Aug 2015 19:03:41 +0000, Richard wrote:
 
 
> of this newsgroup, but this stack overflow thread might help for
> Windows:
> <http://stackoverflow.com/questions/1605721/faking-an-rs232-serial-port>
 
Thank you Richard, that helps.
Writing to serial output is easier.
 
 
--
Stand up against TTIP and ISDS !
Gerhard Wolf <leawolf@gmx.de>: Sep 05 08:19AM +0200

Hi,
i am not so experienced in template programing as I would like to be, so
i have some questions to Stefans templat example in the "A Preferred or
better Way?" Re-Post.
 
I tried to compile this code with bcc64. it drops an error:
 
Implicit instantiation of undefined template
'std::basic_stringstream<char, std::char_traits<char>,
std::allocator<char> >'
 
i changed the line
scanner s
to
scanner * s
which solved this problem.
 
If the prior line compiles with a other compiler is ist a compiler
feature/setting?
 
This change produces 'member-reference basetype 'T *' is no struct or
union' errors on all 's' calls.
 
how can i change this?
 
 
---her Stephans code---------------------------------------------
 
#include <iostream>
#include <ostream>
#include <sstream>
 
template< typename scanner >struct parser
{ scanner s; parser( char const * s ): s{ s } {}
int numeral(){ return s.get() - '0'; }
int prefix(){ int sign = 1;
while( '-' == s.peek() ){ s.get(); sign *= -1; } return sign *
numeral(); }
int start(){ int result = prefix();
while( '-' == s.get() )result -= prefix(); return result; }};
 
int main()
{ using p = ::parser< ::std::stringstream >;
auto test = []( char const * s ){ ::std::cout << p{ s }.start() <<
'\n'; };
test( "4-2" ); test( "-4-2" ); test( "4--2" ); test( "-4--2" );
test( "-4---2" ); test( "--4--2" ); test( "4-2-1" ); test( "4-2--1" ); }
Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 05 09:10AM +0200

On 05.09.15 08.19, Gerhard Wolf wrote:
 
> Implicit instantiation of undefined template
> 'std::basic_stringstream<char, std::char_traits<char>,
> std::allocator<char> >'
 
Works for me. (gcc 4.8.2 @ eCS)
Maybe a compiler bug.
 
> to
> scanner * s
> which solved this problem.
 
This, of course, no longer works since ::std::stringstream* cannot be
initialized from const char*.
 
> If the prior line compiles with a other compiler is ist a compiler
> feature/setting?
 
Some compilers need an option to enable C++11. But basic_stringstream
should work anyway. It is quite old.
 
> This change produces 'member-reference basetype 'T *' is no struct or
> union' errors on all 's' calls.
 
> how can i change this?
 
Undo the change. It is completely wrong.
 
 
Marcel
Paavo Helde <myfirstname@osa.pri.ee>: Sep 05 02:43AM -0500

Gerhard Wolf <leawolf@gmx.de> wrote in
 
> Implicit instantiation of undefined template
> 'std::basic_stringstream<char, std::char_traits<char>,
> std::allocator<char> >'
 
This error message says that the compiler thinks stringstream is only
declared, not defined, but the standard header <sstream> where it is
defined is clearly included. Looks like a problem with the compiler or
its standard library. It might be it gets confused by the newer C++11
features like auto and lambda used in the example. You may try to rewrite
the example to use an ordinary function instead of a lambda.
 
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)