Saturday, February 18, 2017

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

Manfred <noname@invalid.add>: Feb 18 04:40PM +0100

On 2/17/2017 4:08 PM, Tim Rentsch wrote:
 
> What if you want a variable that is guaranteed to refer to an
> actual object, but now and then you want to change which object
> it refers to?
 
Alf already answered about std::reference_wrapper, but I may add that
IME if you have a well defined problem domain, when a variable needs to
refer to selectable objects, most often it requires to be allowed to
refer to no object as well: typically such a variable is meant to
address an object in a set, and typically sets can be empty.
Tim Rentsch <txr@alumni.caltech.edu>: Feb 18 08:11AM -0800

>> actual object, but now and then you want to change which object
>> it refers to?
 
> That's std::reference_wrapper<T> for you.
 
I didn't know about reference_wrapper. Interesting.
 
> Copy assignment of a `std::reference_wrapper` makes it refer to
> another object.
 
I played around with reference_wrapper a bit, and it strikes me
as, well, maybe I would say a bit off. Or clunky? I appreciate
the semantics, clearly it would be useful in some circumstances,
but the interface is rather (if I may use a technical term) icky.
Tim Rentsch <txr@alumni.caltech.edu>: Feb 18 08:06AM -0800


> Maybe if you are making a commentary or review on it.
> Just copypasting significant portions of the text does not
> fall under fair use.
 
If you look into the question more fully I think you will
find (a) that there are other factors that bear on the issue
besides the ones you listed, and (b) that the lines between
what is allowed and what is not allowed (ie, under "fair
use") are fuzzy rather than sharp. Here though my best
understanding is that this case is pretty clearcut.
 
Like I said, IANAL. Feel free to draw your own conclusions.
JiiPee <no@notvalid.com>: Feb 18 11:06AM

I use this a lot but just dont know (even after reading about patterns)
which pattern it is. Surely a simple question..
 
Can somebody help me please, what pattern is this when you can add a
different behaviour by pointer member variable:
 
 
class DrivingStyle
{
public:
virtual void drive();
};
 
class DriveNormally : public DrivingStyle
{
public:
void drive();
};
 
class DriveErratically : public DrivingStyle
{
public:
void drive();
};
 
 
 
class Car
{
public:
DrivingStyle* m_drivingStyle;
void drive() {
m_drivingStyle->drive();
}
 
};
 
 
void main()
{
Car car1;
car1.m_drivingStyle = new DriveErratically();
car1.drive();
car1.m_drivingStyle = new DriveNormally();
car1.drive();
...
}
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 18 11:44AM

On 18/02/2017 11:06, JiiPee wrote:
> car1.drive();
> ...
> }
 
It is most definitely strategy, could be facade, it is almost proxy, but
what it actually is is just basic subtype polymorphism.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 18 01:36PM +0100

On 18.02.2017 12:06, JiiPee wrote:
 
> void main()
 
has always been invalid in both C and C++.
 
 
Cheers & hth.,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 18 01:00PM

On Sat, 18 Feb 2017 11:06:47 +0000
> car1.drive();
> ...
> }
 
It's called 1990s OOP pattern.
 
These days you would probably (depending on the problem area) consider
higher order functions with std::function.
JiiPee <no@notvalid.com>: Feb 18 01:39PM

On 18/02/2017 12:36, Alf P. Steinbach wrote:
> has always been invalid in both C and C++.
 
 
but is it a big error? maybe not...?? and it compiles...
JiiPee <no@notvalid.com>: Feb 18 01:42PM

On 18/02/2017 13:00, Chris Vine wrote:
> It's called 1990s OOP pattern.
 
 
yes but what is the name of that pattern?
JiiPee <no@notvalid.com>: Feb 18 01:43PM

On 18/02/2017 12:36, Alf P. Steinbach wrote:
 
> has always been invalid in both C and C++.
 
> Cheers & hth.,
 
> - Alf
 
..but.. even int main() does not need to return a value!!
JiiPee <no@notvalid.com>: Feb 18 01:44PM

On 18/02/2017 11:44, Mr Flibble wrote:
> It is most definitely strategy, could be facade, it is almost proxy,
> but what it actually is is just basic subtype polymorphism.
 
 
can you choose already? :) so which one??
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 18 02:18PM

On Sat, 18 Feb 2017 13:42:22 +0000
> On 18/02/2017 13:00, Chris Vine wrote:
> > It's called 1990s OOP pattern.
 
> yes but what is the name of that pattern?
 
That depends on why you are doing it. Based on your small example it
looks as if you want to implement the policy pattern (aka strategy
pattern) for run time.
 
If so, something on the scale of your example Car type would be much
more easily implemented by delegating the polymorphic behavior to a
std::function object as a member of the Car type, holding a lambda
object or some other function object giving effect to the selected
behavior.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 18 04:49AM -0800

This message is for those who have a drawing from within to do so. I want
you to know that drawing is from God. He is reaching out to you to save
your eternal soul from the judgment for sin.
 
If you hear His call on the inside, then go to church on Sunday. Seek to
learn more about this drawing, why it exists, and what it means to you.
 
You know that have sinned. You know that you need to be forgiven. You
will find Jesus, His big carpenter's hands, ready to receive you into His
arms, to forgive you for what you've done, and to welcome you into His
eternal Kingdom.
 
Do not silence His voice. Embrace it. He reaches out to you because He
loves you and wants you to be with Him where He is in Heaven.
 
-----
I, Rick C. Hodgin, from Indiana, am a sinner. I have been saved by grace.
I do not have my own righteousness. In my life I continually struggle. I
fall down. I make mistakes. I come up short. It was not until I met the
Lord at almost 35 years old that I came to know what it means to be on a
proper course. On the right track.
 
Until that time I thought I had it all figured out. What I learned from
Him was that there's more to our existence than that which we know in this
world. There is a spiritual component, and that spiritual component is
the true life. It is eternal life. It is the life we do not know until
we come to Jesus and ask forgiveness for our sins.
 
From that day forward, we are alive spiritually, born again, and forever
changed, sealed from within by the presence of His Holy Spirit, a down
payment for the day of redemption after we leave this world.
 
Jesus is everything we need. He teaches us about truth, about righteous-
ness, about holiness, about the enemy, and about His Kingdom.
 
-----
If you hear His call, do not harden your heart. Answer Him. He is
reaching out to save you from judgment from sin. He wants you to be with
Him where He is:
 
http://biblehub.com/kjv/john/14.htm
1 Let not your heart be troubled: ye believe in God, believe also
in me.
2 In my Father's house [Heaven] are many mansions: if it were not
so, I would have told you. I go to prepare a place for you.
3 And if I go and prepare a place for you, I will come again, and
receive you unto myself; that where I am, there ye may be also.
4 And whither I go ye know, and the way ye know.
 
6 Jesus saith unto him, I am the way, the truth, and the life: no
man cometh unto the Father, but by me.
 
Only Jesus can set you free from sin because of what He did at the
cross. He made a real exchange: His perfect righteousness for your
black-stained sin. He set you free from judgment, and received that
judgment onto Himself. He took your punishment in your place so that
you could be redeemed ... His gift to us as our Creator desiring to
save His creation.
 
All who come to Him are received. Nobody is turned away no matter what
you've done, for how long, how bad it was, nothing. He will forgive it
all and set you free.
 
Sin is our weakness, and the enemy of this world (Satan and all his
demon imps) use that weakness against us to keep us in more sin. Jesus
is the cure because He takes our sin away. Once we are sin free we are
again in right standing with God, such that we are alive again spiritually.
He then comes to live with us (spiritually) so that His Holy Spirit is
there to continually guide us into all truth, all righteousness. We
still have free will, we are still in these sin-loving bodies, and we
still make bad choices and mistakes sometimes, but the ongoing direction
and movement of our lives will be toward Him from hat day forward, rather
than toward the world.
 
-----
If you already know this to be true, reach out to those around you and
teach them the same. And if you are only beginning to see it, then go
to church this weekend and listen to the message. Pay less attention
to the goings on of the people in the congregation, and more attention
to what God has to say to you through the pastor's message, and
specifically through the Bible passages.
 
Say a little prayer before you go asking God to guide you from within.
If you are sincere He will know this, and He will guide you.
 
Love you.
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 18 05:04AM -0800

Listen to this song. It has the lyrics written out.
 
Chris Tomlin - Lord I Need You
https://www.youtube.com/watch?v=_rR_Rdb1CTE
 
There is comfort in coming to Jesus Christ and being forgiven. A real
inner peace greater than the best inner peace you had as a child in the
comfort of your parent's arms. When they held you close and told you
everything was going to be alright, and you felt so warm and safe and
secure ... what Jesus brings us is even more than that. The pictures
in the video show that comfort in the eyes, in their countenance, and
in their embracing Jesus in those pictures as well.
 
Jesus fills every hole. Seals every crack. He sets you back on the
true path He intended for your life, and leads you to prosperity that
will endure in His Kingdom, as by service to Him in pursuit of His
righteousness, both for yourself, and more importantly, to others.
 
Thank you,
Rick C. Hodgin
ram@zedat.fu-berlin.de (Stefan Ram): Feb 18 12:16PM

>I use this a lot but just dont know (even after reading about patterns)
>which pattern it is. Surely a simple question..
 
A pattern has four /essential/ elements:
 
- The pattern name
 
- The problem (describing when to apply the pattern)
 
- The solution (describing the elements that make up the
design)
 
- The consequences (the results and trade-offs of
applying the pattern)
 
One of them missing, and it's not a pattern.
 
Since you ask about the name, you might omit
the first element, but then you should still
provide the other three.
 
When you only want to write code and read code,
but not English prose, that's fine, but in this
way you will never get (grasp, understand) patterns.
 
>Can somebody help me please, what pattern is this when you
>can add a different behaviour by pointer member variable:
...
>car1.m_drivingStyle = new DriveErratically();
 
Yes, modifying an object /from without it's class/
in the above way has the name "anti-pattern".
"K. Frank" <kfrank29.c@gmail.com>: Feb 17 05:41PM -0800

Hello Group!
 
I desire a recursive class. Is something like the following
a good way to go?
 
struct RecursiveClass {
RecursiveClass (unsigned n) : n_(n), rc_((n_) ? new RecursiveClass(n-1) : nullptr) {}
unsigned n_;
std::unique_ptr<RecursiveClass> rc_;
unsigned val() { return (n_) ? rc_->val() + n_ : 0; }
};
 
This was about the best I could think of, but the initialization
of rc_ looks a bit cumbersome.
 
(Just to make the example a little less vacuous, I made
the class return "triangle numbers" via the member function
val().)
 
(By the way, is this a correct and sensible use of unique_ptr?)
 
Note, n is to be determined at run time, not compile time, so
I did not pursue a template approach, such as:
 
template<unsigned N> struct RecursiveClass {
RecursiveClass<N-1> rc_;
unsigned val() { return rc_.val() + N; }
};
 
template<> struct RecursiveClass<0> {
unsigned val() { return 0; }
};
 
Am I right that the template-class approach cannot be
made to work with run-time n (N in the template example)?
 
 
Thanks for any ideas.
 
 
K. Frank
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 18 10:51AM

On Fri, 17 Feb 2017 17:41:19 -0800 (PST)
> };
 
> Am I right that the template-class approach cannot be
> made to work with run-time n (N in the template example)?
 
The classic example of compile time recursion is std::tuple, which you
might find instructive to have a look at. tuples are normally
implemented using recursive inheritance, something like:
 
template <class Head, class... Tail>
class Tuple<Head, Tail...>: private Tuple<Tail...> {
Head elt;
public:
...
};
 
with a specialization:
 
template <> struct Tuple<> { ... };
 
which ends recursion. I think most people go through the business of
writing their own tuple implementation at some point in their lives for
pedagogical purposes (and to learn how variadic templates work).
 
This is of course doing different things from your RecursiveClass.
A tuple keeps values via this recursive inheritance which can be
accessed individually by a get function such as std::get(), which would
traverse the inheritance graph. Yours provides an accessor which sums
all the values.
 
You are right that at compile time the size of the tuple and the types
for which it is instantiated must be known. It is part of the
tuple's type.
 
As regards your non-templated RecursiveClass, your use of
std::unique_ptr looks OK. If your compiler supports C++17, as an
alternative you could try std::optional, which I have never used. If
this implementation is a toy for fun, then it looks OK but in practice
to keep a collection of unsigned ints of a size determined at run time I
would use std::vector, which would be much more flexible because it
would not restrict you to summing the elements - std::accumulate can
fold over the container to do whatever you want. std::forward_list
would be a more exact container replacement for your implementation, but
be much less efficient for keeping unsigned ints.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 18 11:04AM

On Sat, 18 Feb 2017 10:51:27 +0000
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]
> std::forward_list would be a more exact container replacement for
> your implementation, but be much less efficient for keeping unsigned
> ints.
 
By the way, it occurs to me that if you are interested in other
approaches to your problem, you might want to look into cons cells,
which lisps use to construct singly-linked lists. A cons cell is a
pair, and these can be strung together to produce a list (the second
element of the pair, called the 'cdr', being itself a cons cell). Your
RecursiveClass is basically a cons cell which can only be used to
construct a singly-linked list (it cannot be used as a pair only).
 
You can reproduce this in C++ using std::pair.
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Feb 17 11:23PM -0800

Can anybody suggest me the best c++ library which works really good in integrating c++ with html.So far i have come accross Wt and Cppcms but i really cant figure out whether using this would be worth it in terms of productivity.I want to integerate c++ just as a backend with html and writing html javascript css alongside it.
Thanks
Kushal
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Feb 17 11:27PM -0800

To put it in other words i want to use c++ as backend for processing tasks from the client end just as php or any other server side scripting language does
Robert Wessel <robertwessel2@yahoo.com>: Feb 18 12:20AM -0600

On Fri, 17 Feb 2017 07:30:18 -0800, Tim Rentsch
 
>that calculates x**y (please excuse my fortran). Probably easier
>in C++14 but still doable in C++11 (and the accuracy looks fairly
>good in the tests I ran).
 
 
I never meant to express doubt that you *could* implement a pow()
function as a constexpr. Doing it well (errors bounded to something
somewhere near an ULP - and that flatly rules out any simple
implementation that does a simple reduction of pow(x,y) to
exp(y*log(x)) *), and handling all the special cases**, would
doubtless make for some pretty ugly code given the restrictions in
constexpr function (although a convention implementation is pretty
ugly as well, and even so, several hundred lines of code, when you
count the required support functions).
 
OTOH, it's certainly possible for a compiler to recognize many special
cases (notably, in this case, where the two parameters are constants),
and inline that. In appears that GCC, for example, does actually do
that in some cases, and then allows the result in a constexpr (that
was in Scott's example that I commented on). But it's not at all
clear to me that this is standard behavior, or something that can be
counted on.
 
 
*The problem is that log(x) basically shoves most of the exponent bits
into the mantissa, and shoves the same number of bits off the low end
of the mantissa - IOW, log(x) on a double pretty much starts with
throwing away as many as the low 10 bits of the input. You can, and
often do, use exp(y*log(x)) as part of the calculation, but you can
only do that after scaling both operands to be fairly near the base of
convenient log and exp functions*** (which will make the result near
1.0). You factor the exponents back in after.
 
 
**Most of the various combinations of signs, infinities, NaNs and
zeros for the two operands end up needing specific handling.
 
 
***There are various tradeoffs as to the exact range, and it's often
easiest to split the exponent and mantissa directly from the FP
format, thus leading to base 2 log/exp.
Jeff-Relf.Me <@.>: Feb 17 07:11PM -0800

"Christopher J. Pisz" <cpisz@austin.rr.com>: Feb 17 09:59PM -0600

On 2/17/2017 9:11 PM, Jeff-Relf.Me wrote:
 
> http://Jeff-Relf.Me/Visual-Studio-2017.PNG
 
> 236 columns of text, No side panels. To find a function,
> I just search for it, instead of using a side panel of "classes".
 
I hope you never work on a project where others have to maintain that code.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 18 05:29AM +0100

On 18.02.2017 04:59, Christopher J. Pisz wrote:
 
>> 236 columns of text, No side panels. To find a function,
>> I just search for it, instead of using a side panel of "classes".
 
> I hope you never work on a project where others have to maintain that code.
 
Interesting. Apparently C++ code to spam/troll newsgroups, expressed in
a delightful font and colors, in actually 236 columns! Well the good
Jeff is in my killfile, so I didn't see it: thanks for reposting. :)
 
 
Cheers!,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 18 03:54AM +0100

On 17.02.2017 22:55, Vir Campestris wrote:
 
> I can imagine a future where the two functions might be run in parallel
> on different CPUs. Currently the overhead of setting such a thing up is
> too much, so any parallelism is explicit (threads, or OpenCL).
 
I support explicit notation for where one wants or wants to permit
parallelism.
 
The consequences could be quite serious if the calls in
 
cout << a() << " " << b() << "\n";
 
were executed in parallel, without `a` and `b` being designed for
parallelism, e.g. trying to update the same variable.
 
Explicit is good, implicit is bad. In general. ;-)
 
In C++98 and C++03 the non-normative examples at the start of section 5,
like
 
i = v[i++]; // the behavior is unspecified
 
… directly contradicted the normative text right above,
 
"Between the previous and next sequence point a scalar object shall
have its stored value modified at most once by the evaluation of an
expression."
 
… which dictates undefined behavior.
 
I think that these examples signal an original intent different from the
normative text's wording. Just like all the C++98/C++03 examples using
`<iostream>` output and failing to include also `<ostream>`, probably
signal an original intent that `operator<<` should be provided also via
the `<iostream>` header. It is now, as of C++11 and later.
 
So, is the presumed original intent of /unspecified/ behavior
incompatible with your envisioned possible parallelism?
 
 
Cheers!,
 
- Alf
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.

No comments: