Tuesday, April 24, 2018

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

Tim Rentsch <txr@alumni.caltech.edu>: Apr 24 07:00AM -0700

> detail. Trying to cover many levels of detail is a large part of
> why big functions are hard to understand."
 
> He also used the word 'cover' to explain what he was saying.
 
I did use the word 'cover'. It is 'crossing' though that expresses
what I mean. Crossing a level of detail is what the code does;
trying to cover a level of detail is what the programmer does. To
me 'crossing' connotes depth, with 'cover' being more like breadth,
or perhaps some sort of product of the two. What I find difficult
is transitioning between levels of detail, hence 'crossing' - when
the depth gets larger than about two or three is usually where I
run into a knee in the understandability curve.
 
I do appreciate your suggestion. For some people 'cover' may offer
a more accessible framing, even if it isn't how I think of it.
ruurd <rfpels@gmail.com>: Apr 24 03:58PM +0200

On 16 Apr 2018, Cholo Lennon wrote
 
> just add him to your kill file
 
Hahaha that's like playing whackamole really he keeps popping up with all
sorts of names :-)
 
--
ruurd
boltar@cylonHQ.com: Apr 24 08:28AM

On Tue, 24 Apr 2018 00:12:11 +0300
 
>I agree that &s[0] is a bit ugly, but it did work in all known
>implementations AFAIK even before C++11 officially forced the strings to
>use contiguous storage.
 
Would it nor have made more sense for c_str() to return a pointer to mutable
memory rather than taking an address of the first element which seems a
pretty strange way to get the address?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 24 11:42AM +0200

>> use contiguous storage.
 
> Would it nor have made more sense for c_str() to return a pointer to mutable
> memory rather than taking an address of the first element
 
Consider whether the c_str() buffer should be the string's own main
buffer, so that changes to one of them is directly visible in the other.
 
If so, then for C++98 and C++03 this would impose a contiguous buffer
requirement. At the time it was envisioned that implementors might
choose a non-contiguous main buffer. It turned out that they didn't, so
C++11 imposed a contiguous buffer requirement, but at the time that was
not known: keeping the possibility of non-contiguous buffer open was
considered important enough to, well, to keep that possibility open.
 
But if changes to the c_str() buffer should not be reflected in the main
buffer, then a mutable c_str() buffer would require dynamic allocation
and copying of the string contents also in the case where, at the
moment, the main string buffer was contiguous. This would be at odds
with the C++ principle of not paying for what you don't use.
 
One might however envision wording that would allow, but not require,
changes to be reflected in the main buffer.
 
But that would make code less portable, and brittle, and possibly
depending on the dynamic internal state of the string for correctness.
 
 
> which seems a pretty strange way to get the address?
 
It's the ordinary way to get the address of an array in C and C++,
except that for raw arrays one usually lets type decays do the job.
 
There is nothing strange whatsoever about it.
 
What's /strange/ is doing it in some other way.
 
 
Cheeers & hth.,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Apr 24 01:17PM +0300


> Would it nor have made more sense for c_str() to return a pointer to mutable
> memory rather than taking an address of the first element which seems a
> pretty strange way to get the address?
 
I think for C++17 they had to choose whether to provide a non-const
c_str() or a non-const data(). Other containers already had non-const
data(), so that's one point in favor of data().
 
Another is that as the name implies c_str() is meant for interfacing
with C, and one does not want to give impression that this interfacing
can be easily done for non-const strings, e.g.
 
std::string a = "foo";
strcat(a.c_str(), "bar");
boltar@cylonHQ.com: Apr 24 10:21AM

On Tue, 24 Apr 2018 11:42:32 +0200
>But if changes to the c_str() buffer should not be reflected in the main
>buffer, then a mutable c_str() buffer would require dynamic allocation
>and copying of the string contents also in the case where, at the
 
And why is using the [] operator guaranteed to provide a pointer to a
contiguous buffer? The overload function could simply be doing a mapping
just like c_str().
 
>It's the ordinary way to get the address of an array in C and C++,
 
Not in C. Why would you bother with "&str[0]" when you can just use "str"?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 24 12:52PM +0200

> just like c_str().
 
>> It's the ordinary way to get the address of an array in C and C++,
 
> Not in C. Why would you bother with "&str[0]" when you can just use "str"?
 
The selective out-of-context quoting means you're a troll. Plink.
 
- Alf
boltaar@cyloneaichqueue.com: Apr 24 11:18AM

On Tue, 24 Apr 2018 12:52:44 +0200
 
>>> It's the ordinary way to get the address of an array in C and C++,
 
>> Not in C. Why would you bother with "&str[0]" when you can just use "str"?
 
>The selective out-of-context quoting means you're a troll. Plink.
 
I didn't quote anything out of context. If you realised you made an idiotic
assertion which you now wish to deny, don't accuse someone of being troll just
for pointing it out to you you utter tool.
 
Oh, and I changed my From: address so I know you'll have read this. Feel
free to respond and dig the hole deeper and or just accept you're an idiot
and move on.
Bo Persson <bop@gmb.dk>: Apr 24 01:34PM +0200


> And why is using the [] operator guaranteed to provide a pointer to a
> contiguous buffer? The overload function could simply be doing a mapping
> just like c_str().
 
Operator[] must return a reference to the string's internal buffer, to
support s[i] = 'x'.
 
c_str() was originally allowed to allocate a separate temporary buffer,
or to possibly return a pointer to a shared buffer for copy-on-write
implementations.
 
Originally it wasn't required for the buffer to be contiguous, but in
practice it was. So the allowance for other options was removed from the
standard, because they had never been used.
 
 
 
Bo Persson
boltar@cylonHQ.com: Apr 24 11:54AM

On Tue, 24 Apr 2018 13:34:37 +0200
>> just like c_str().
 
>Operator[] must return a reference to the string's internal buffer, to
>support s[i] = 'x'.
 
Not necessarily. [] could simply return a type that has = overloaded. And
for obtaining the value or printing out it could have various standard cast
overloads defined. Thats almost certainly not the way its done but that doesn't
preclude it.
 
>c_str() was originally allowed to allocate a separate temporary buffer,
>or to possibly return a pointer to a shared buffer for copy-on-write
>implementations.
 
Given that I had some obscure bugs when I tried to write to the buffer
returned by c_str() when I was younger and didn't know any better, I'd say
some implementations actually did do something like that.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 24 04:46PM +0300


> Given that I had some obscure bugs when I tried to write to the buffer
> returned by c_str() when I was younger and didn't know any better, I'd say
> some implementations actually did do something like that.
 
g++ and many other implementations used to have copy-on-write strings
and indeed returned a pointer to a shared buffer. However, this did not
play so well with the multithreading, so in C++11 they introduced new
rules "effectively disallowing copy-on-write implementations" and all
vendors switched away from COW strings.
 
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm
for more details.
Rick <rick.c.hodgin@usa.com>: Apr 22 07:54AM

Psalm 100
 
http://biblehub.com/kjv/psalms/100.htm
 
Shout for Joy to the Lord, All You Lands!
 
1 {A Psalm of praise.} Make a joyful noise unto the LORD, all ye lands.
 
2 Serve the LORD with gladness: come before his presence with singing.
 
3 Know ye that the LORD he is God: it is he that hath made us, and not
we ourselves; we are his people, and the sheep of his pasture.
 
4 Enter into his gates with thanksgiving, and into his courts with
praise: be thankful unto him, and bless his name.
 
5 For the LORD is good; his mercy is everlasting; and his truth
endureth to all generations.
 
-----
There is love, peace, and joy in the house of the Lord, but only when
you keep your eyes focused on Him. If you begin looking around at the
things of the world, they will quickly pull you under. But when you
look up to Him, and keep looking up, there you find your peace, because
only there is your salvation.
 
Remember also ... Peter walked on water too, but only when he was
looking at the Lord!
 
http://biblehub.com/kjv/matthew/14.htm
 
28 And Peter answered him and said, Lord, if it be thou, bid me
come unto thee on the water.
29 And he said, Come. And when Peter was come down out of the ship,
he walked on the water, to go to Jesus.
30 But when he saw the wind boisterous, he was afraid; and beginning
to sink, he cried, saying, Lord, save me.
31 And immediately Jesus stretched forth his hand, and caught him,
and said unto him, O thou of little faith, wherefore didst thou
doubt?
32 And when they were come into the ship, the wind ceased.
33 Then they that were in the ship came and worshipped him, saying,
Of a truth thou art the Son of God.
 
Jesus will save your eternal soul, and give you eternal life. All you
have to do is trust and believe.
 
Best regards,
Rick C. Hodgin
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 24 01:25PM

On Tue, 2018-04-17, Ralf Goertz wrote:
> repeatedly. And in all my other use cases I could probably use other
> tricks. But having many different scenarios where it would be beneficial
> to be able to match repetitive patterns I wonder why it isn't possible.
 
I'd try this approach:
- Split away "some text"
- Split into not-quite-pairs with a regex.
- Parse each pair with a regex, or with std::strtod() and manual
parsing (the latter is simplified by you knowing the text matches a
certain regex).
 
Doing too much in one regex is dangerous in any language.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 24 05:32AM -0700

Until I get my post validation system up and running, I will not post
any additional messages after this round this morning indicating the
same.
 
The impersonation posts are given to drive you away from Christ. They
are given to push you away from Christ by giving you a reason to be
angry at me for my apparent flood of posts causing you distress and
much grief. They belie the underlying message that each of us has sin,
each of us needs to be forgiven by Jesus to enter into eternity alive.
 
They are nothing short of a full-on attack against your soul. Do not
let that attack succeed. Seek the true meaning of the message, and in
so doing come to receive victory in Christ.
 
I will post this message in other groups, and then it will be my last
post until I get my post validation system up and running.
 
--
Rick C. Hodgin
gazelle@shell.xmission.com (Kenny McCormack): Apr 24 01:07PM

In article <e6d2c634-dfc9-4123-8fae-bf521a1a0a62@googlegroups.com>,
>Until I get my post validation system up and running, I will not post
>any additional messages after this round this morning indicating the
>same.
 
Promises, promises!
 
--
 
First of all, I do not appreciate your playing stupid here at all.
 
- Thomas 'PointedEars' Lahn -
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 24 10:54AM +0100

On Mon, 23 Apr 2018 09:30:50 -0400
"James R. Kuyper" <jameskuyper@verizon.net> wrote:
[snip]
> safely converted to and from void*. That doesn't guarantee that any
> other function pointers can be safely converted, but it does make it
> more likely.
 
There is provision in the C++ standard for conversions of function
pointer to object pointer and vice versa. They are conditionally
supported in C++, and the behaviour is implementation defined rather
than undefined. This is to support the POSIX requirement that you
mention:
 
"Converting a function pointer to an object pointer type or vice versa
is conditionally-supported. The meaning of such a conversion is
implementation-defined, except that if an implementation supports
conversions in both directions, converting a prvalue of one type to the
other type and back, possibly with different cv-qualification, shall
yield the original pointer value." (5.2.10/8 of C++14)
kmo <this@e.mail.is.invalid>: Apr 24 10:54AM

jameskuyper@verizon.net wrote in
>> miss the () after the template invocation?
 
> I missed the explicit cast to void*, which is pretty dumb. My comments
> about that conversion having undefined behavior remain valid.
 
Yes, that was my bad. This should fix the undefined behavior:
---------------------------------
template<typename T, T *ptr>
inline void *fid() {
static int t;
return &t;
};
---------------------------------
The results are almost the same. The only change is that now
Visual Studio produces different pointers in case where 3 equal
pointers were printed.
 
>> > set of overloaded functions (6.4, 16.3, 16.4), unless it is a pure
>> > virtual function and either its name is not explicitly qualified or the
>> > expression forms a pointer to member (8.3.1)."
 
Thank you for clarifying this fragment for me. I was staring at it
and could not decide if it applies to a template argument.
 
> but as a matter of QoI, I think it shouldn't link. What I know about
> linking doesn't suggest any reason why that should be difficult to
> achieve - but I'm not by any means an expert on real world linkers.
 
I see I have used "compile" in too broad sense. What I meant was
compile and link (since there is no other code).
 
Anyway, thank you for helping me understand this.
To sum up: f1, f2, f3 are ODR used but not defined
so it is an undefined behavior with no diagnostic required
(and indeed, there is no diagnostic in most cases).
kmo <this@e.mail.is.invalid>: Apr 24 11:09AM

=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote in
 
> I think the compilers are incorrect, but I can't imagine an actual
> problem, some motivating example that their incorrectness would break
> for me.
 
Actually, the problem came up when I was implementing a toy RPC.
I wanted the description of the RPC interface to be as concise as
possible -- ideally it would be a header file with declarations
of allowed calls. Therefore, I needed a method of creating some kind
of identifer based on a declaration to identify what needs to be called.
 
Anyway, the attempt failed. While it may work for most compilers now,
it can break at any time: it employs undefined behavior by not defining
an ODR used function, as explained by James R. Kuyper in other response.
"James R. Kuyper" <jameskuyper@verizon.net>: Apr 24 08:48AM -0400

On 04/24/2018 05:54 AM, Chris Vine wrote:
> conversions in both directions, converting a prvalue of one type to the
> other type and back, possibly with different cv-qualification, shall
> yield the original pointer value." (5.2.10/8 of C++14)
 
Correction: 8.2.10p8, at least in my copy of C++17.
I'm still more familiar with C++98 than the newer versions of the
standard. I read p6, about function pointers, saw that p7 was about
object pointers, and apparently stopped reading because I failed to
notice that p8 was about both. As a conditionally-supported feature with
an implementation-defined meaning, it's still something to be avoided in
code that's intended to be portable.
Rick <rick.c.hodgin@usa.com>: Apr 24 10:06AM

I declare Jesus loves you
Rick <rick.c.hodgin@usa.com>: Apr 24 10:06AM

I, the real Rick C. Hodgin, declares this is my real email address.
Rick <rick.c.hodgin@usa.com>: Apr 24 10:04AM

Jesus Loves You
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 23 06:58PM -0500

On 4/23/2018 5:57 PM, Melzzzzz wrote:
>> be able to beat Fortran for certain use cases"? Fair enough, I
>> suppose.
 
> Question is why he wants to convert calculation engine to C++...
 
Because I prefer C++ nowadays. The calculation engine is about 700K
lines of F77 code with 10K lines of C and C++. We cannot use the Intel
Fortran compiler since it has two showstopper bugs that we have run into
so we use the old Watcom F77 compiler for now.
 
When life slows down a little, we are going to try the Fable F77 to C++
converter on our code:
http://cci.lbl.gov/fable/
 
Lynn
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 24 01:05AM


> When life slows down a little, we are going to try the Fable F77 to C++
> converter on our code:
> http://cci.lbl.gov/fable/
 
So reason for all the fuss is bug in Intel Fortran compiler? Hm, what
about gfortran?
 
 
--
press any key to continue or any other to quit...
Paavo Helde <myfirstname@osa.pri.ee>: Apr 24 07:22AM +0300

On 24.04.2018 2:58, Lynn McGuire wrote:
 
> Because I prefer C++ nowadays. The calculation engine is about 700K
> lines of F77 code with 10K lines of C and C++. We cannot use the Intel
> Fortran compiler since it has two showstopper bugs
 
Converting 700K lines of code from one language to another seems like a
daunting task, whatever the tools. What about reporting the bugs to
Intel and waiting a couple of years until they fix them?
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)