Tuesday, November 14, 2017

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

Nikki Locke <nikki@trumphurst.com>: Nov 14 11:23PM

Available C++ Libraries FAQ
 
URL: http://www.trumphurst.com/cpplibs/
 
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
 
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
Vir Campestris <vir.campestris@invalid.invalid>: Nov 14 09:09PM

(This is derived from real code, but that's horribly complicated. I
didn't write it)
 
Suppose there is a class omega that has three members
class omega {
alpha a;
beta b;
gamma c;
 
And the constructor is something like this:
 
omega::omega(): a(1), b(this), c(2) {...}
 
- Is there anything in the language spec that forbids this?
- Assuming b doesn't use c (at least until later), will the code behave
correctly?
 
In the real code beta handles inter-object communication, and may
receive signals from other threads.
 
Andy
legalize+jeeves@mail.xmission.com (Richard): Nov 14 09:14PM

[Please do not mail me a copy of your followup]
 
Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
 
>In the real code beta handles inter-object communication, and may
>receive signals from other threads.
 
>Andy
 
Nothing in the language specifciation forbids this.
 
Assuming that beta's constructor doesn't do anything more with its
argument than store it, you're fine.
 
If beta's constructor needs to call methods on the passed in omega
pointer, then you've got a chicken-and-egg situation. The omega
instance hasn't been fully constructed so it is in a state that can't
guarantee anything about invariants assumed by its methods.
 
The typical solution to this is to refactor the code into two-phase
construction. Phase 1 gets all the objects constructed with the
pointer references between them. Phase 2 calls any necessary methods
to complete the construction.
 
We can't answer if you need 2 phase construction based on the code
you've shown because we don't know what beta's constructor does with
the passed in pointer to the omega.
 
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 15 12:18AM +0100

On 11/14/2017 10:14 PM, Richard wrote:
> construction. Phase 1 gets all the objects constructed with the
> pointer references between them. Phase 2 calls any necessary methods
> to complete the construction.
 
I wouldn't recommend two phase construction in general.
 
Usually there are better ways.
 
The situation you describe is a FAQ: <url:
https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctor-idiom>.
 
 
Cheers & hth.,
 
- Alf
David Brown <david.brown@hesbynett.no>: Nov 14 09:08AM +0100

On 13/11/17 22:50, Paul N wrote:
 
>> This [] has changed his FROM address so it is time to change the
>> filters again.
 
> Rick denies that this particular post is from him, and I'm inclined to believe him.
 
Many bad things have been said about Rick and his posts, but I have not
seen him change his posting address - nor have I known him to lie.
(Whatever you may think about his religious posts - and I don't think
highly of them myself - he believes in what he is writing, so it is not
lying.)
 
Impersonating someone else on Usenet really, /really/ annoys me. I find
it much worse than posting about religion or politics in a technical
newsgroup, or top-posting, or scrambled quoting and attributions, or
pretty much any other misuse of the medium. I hope this imposter goes
away, or has the decency to post in his/her own name instead of Rick's.
"Öö Tiib" <ootiib@hot.ee>: Nov 14 12:34AM -0800

On Tuesday, 14 November 2017 10:08:43 UTC+2, David Brown wrote:
> newsgroup, or top-posting, or scrambled quoting and attributions, or
> pretty much any other misuse of the medium. I hope this imposter goes
> away, or has the decency to post in his/her own name instead of Rick's.
 
Achieving attention through annoyance (and worse) is seemingly the goal
of most advertisers, spammers, annoying kids, "men of God" and other
trolls. It is active-destructive path (by Alfred Adler's behavioral pattern
typology) for gaining attention. So you being really, *REALLY* annoyed
and announcing it is 10:10 and success checkbox filled for those types.
David Brown <david.brown@hesbynett.no>: Nov 14 11:18AM +0100

On 14/11/17 09:34, Öö Tiib wrote:
> trolls. It is active-destructive path (by Alfred Adler's behavioral pattern
> typology) for gaining attention. So you being really, *REALLY* annoyed
> and announcing it is 10:10 and success checkbox filled for those types.
 
I don't think getting attention through annoyance is Rick's (the /real/
Rick) goal with his religious posts. It is certainly the effect he has,
but not his goal. He sincerely believes he is "teaching" people, even
though everyone else, religious or not, knows he is just pissing people
off and making sure they would never consider joining his particular
cult version of Christianity.
 
As for this new fake Rick - I have no idea what his motivations might
be. I suspect he is only interested in annoying the real Rick. But no,
he does not receive attention from me.
 
I made my post because I think it is important to make it clear that
impersonation is not something we should tolerate or accept - no matter
whom the target is. It does not matter how much people may dislike the
real Rick's religious posts, it is /still/ wrong to make posts claiming
to be him.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 14 12:58PM -0800

On 11/12/2017 10:08 AM, Rick C. Hodgin wrote:
> Cheung. He has been spamming me, my family, and the groups I post
> to online:
 
> https://groups.google.com/d/msg/alt.os.development/onsW08u4DJw/SslLCSkzBAAJ
 
I believe you. Btw, thank you for taking a look at my vector field
algorithm in ShaderToy.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 14 01:45PM -0800

On 11/13/2017 1:50 PM, Paul N wrote:
 
>> This [] has changed his FROM address so it is time to change the
>> filters again.
 
> Rick denies that this particular post is from him, and I'm inclined to believe him.
 
I concur.
"Öö Tiib" <ootiib@hot.ee>: Nov 14 02:14PM -0800

On Tuesday, 14 November 2017 12:18:49 UTC+2, David Brown wrote:
> though everyone else, religious or not, knows he is just pissing people
> off and making sure they would never consider joining his particular
> cult version of Christianity.
 
Ok, but he sometimes displays capability of thinking rationally. Given
that it is so difficult to give him benefit of the doubt, I'm sorry.
 
> whom the target is. It does not matter how much people may dislike the
> real Rick's religious posts, it is /still/ wrong to make posts claiming
> to be him.
 
Yes, I agree with you that it is worse. It wasn't my point to disagree
with you. I also do not know for sure the true motivation of anyone.
My best guess is that annoying us in relation to Rick is the goal of
particular identity thief. What else?
"James R. Kuyper" <jameskuyper@verizon.net>: Nov 14 05:26PM -0500

On 11/13/2017 04:50 PM, Paul N wrote:
 
>> This [] has changed his FROM address so it is time to change the
>> filters again.
 
> Rick denies that this particular post is from him, and I'm inclined to believe him.
 
I agree. These new messages are clearly intended as parodies of his. His
attitudes invite and justify parody, but they don't justify identity
theft. And nothing that anyone else has done on this newsgroup justifies
forcing us to deal with either his original messages, or the parodies.
However, just as there's nothing we can do to stop his off-topic posts,
there's also nothing we can do to stop the parodies of them.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 14 11:51AM

On Thu, 2017-11-09, JiiPee wrote:
> Thanks, but just thinking another thing: is is a good idea at all using
> enums as (option) flags? I read some say online that should use
> constants instead.
 
More interestingly, is it a good idea to use "(option) flags"?
 
I guess you mean those things you or together to enable or disable
features of a function you're calling. But I don't see those getting
used a lot, except in the POSIX APIs, which are a bit special.
I don't find myself writing a lot of such code.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paavo Helde <myfirstname@osa.pri.ee>: Nov 14 03:16PM +0200

On 14.11.2017 13:51, Jorgen Grahn wrote:
> features of a function you're calling. But I don't see those getting
> used a lot, except in the POSIX APIs, which are a bit special.
> I don't find myself writing a lot of such code.
 
By some reason, I do. In my current project I have for example 20 enums
with bit flag values. A typical such enum contains about ten values,
some do more.
 
I guess I could use some struct or class with lots of bool members
instead, but this would just waste more memory, with no substantial
benefit as far as I can see.
 
Cheers
Paavo
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 14 04:16PM

On Tue, 2017-11-14, Paavo Helde wrote:
 
> I guess I could use some struct or class with lots of bool members
> instead, but this would just waste more memory, with no substantial
> benefit as far as I can see.
 
No, that wouldn't be a big improvement. It would give you a good place
(the constructor) to check that the combination of flags makes sense,
but that's about it I think.
 
Better ones would be to use several different functions or a template,
when the choice of options is a compile-time decision. Or passing in
a functor which selects some aspect of the function's behavior. Both
of these get rid of "if (option) ... else ..." in the implementation.
 
I can't say for sure I do this a lot, and that that's why I don't
define option flags. To be honest I think it may have more to do with
that I try to avoid writing general and flexible code.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Nov 14 01:42PM -0800

On Tuesday, 14 November 2017 13:51:27 UTC+2, Jorgen Grahn wrote:
> features of a function you're calling. But I don't see those getting
> used a lot, except in the POSIX APIs, which are a bit special.
> I don't find myself writing a lot of such code.
 
That can be because the problem domain you deal with does not need
flags.
 
For me the idea of "flags" is often same as the idea of discrete
"set". When the objects that can be (members or elements) in set is
rather limited then it is more efficient to represent presence (or
absence) of an element in set as a flag.
 
Just imagine std::set<uint8_t>. It is on most cases terribly
inefficient compared to std::bitset<256> that takes fixed 32 bytes,
and without trees and dynamic allocations provides effectively
exactly same functionality.
Ralf Goertz <me@myprovider.invalid>: Nov 14 07:54AM +0100

Am Mon, 13 Nov 2017 14:45:23 -0800
> [...]
 
> And did that work? It shouldn't, since `numString [i]` will always
> be a null character.

That is not the problem, is it?. numString[i] gets set to str[i] but
unconditionally since the null character is not equal to ','. The
problem is that numString instead of str is queried for the existence of
commas.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 14 12:24PM

>> be a null character.
 
> That is not the problem, is it?. numString[i] gets set to str[i] but
> unconditionally since the null character is not equal to ','.
 
It's a problem because the function won't do what it's supposed to!
Instead, it's just an unsafe version of
 
double asDouble(const char *str) { return str ? atof(str) : 0; }
 
But the error (in effect a typo) is not a serious one in the sense that
it will show up on the very first test and can't cause dangerous
behaviour such as the code appearing to work.
 
I'd do something along these lines:
 
double asDouble(const char *str)
{
if (str) {
char str_cpy[100], *cp = str_cpy;
while (cp < str_cpy + sizeof str_cpy)
if ((*cp = *str++) == 0)
return atof(str_cpy);
else if (*cp != ',')
cp += 1;
}
return NAN;
}
 
I think NAN (from math.h) is a better error return on most systems (and
you can use an ifdef to to something else on implementations without a
quiet NaN) and I'd want to prevent overflow even if I knew it could not
happen in this program. That's just because code often gets re-used and
it may not always be safe.
 
I say "along these lines" because I'd probably use strtod and return a
NaN when strtod reports an error too, at least in some cases.
 
<snip>
--
Ben.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 14 02:29PM -0600

On 11/13/2017 4:45 PM, Keith Thompson wrote:
 
> And did that work? It shouldn't, since `numString [i]` will always be a
> null character.
 
> Incidentally, atof() does no error checking.
 
Nope, as you pointed out, I had a bug. Once fixed, yes, it worked fine
once I replaced all the calls to atof with asDouble.
 
I am ok with atof not having any error checking.
 
Thanks,
Lynn
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 13 08:38PM -0800

Prostitutes right off the street are having their lives changed by this
message. This is hard-core preaching that will pin you to the wall. Do
you dare examine your own soul against the light of truth?
 
https://www.youtube.com/watch?v=kAaSGPp16fU
 
--
Rick C. Hodgin
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)