Wednesday, June 7, 2017

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

"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 06 04:26PM -0700

Check this talk by Kip Thorne out:
 
https://youtu.be/-KfI6qZyoQw
 
He explicitly mentions C++! Will try to refind the exact moment.
Melzzzzz <Melzzzzz@zzzzz.com>: Jun 06 11:33PM

> Check this talk by Kip Thorne out:
 
> https://youtu.be/-KfI6qZyoQw
 
> He explicitly mentions C++! Will try to refind the exact moment.
You like science fiction?
 
--
press any key to continue or any other to quit...
"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 06 04:35PM -0700

On 6/6/2017 4:33 PM, Melzzzzz wrote:
 
>> https://youtu.be/-KfI6qZyoQw
 
>> He explicitly mentions C++! Will try to refind the exact moment.
> You like science fiction?
 
Yes!
"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 06 05:55PM -0700

On 6/6/2017 4:26 PM, Chris M. Thomasson wrote:
> Check this talk by Kip Thorne out:
 
> https://youtu.be/-KfI6qZyoQw
 
> He explicitly mentions C++! Will try to refind the exact moment.
 
Found it!
 
https://youtu.be/-KfI6qZyoQw?t=1938
 
It about 32:18 - 32:20
 
C++, nice. ;^D
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 06 06:31PM -0700

On Tuesday, June 6, 2017 at 8:55:53 PM UTC-4, Chris M. Thomasson wrote:
> https://youtu.be/-KfI6qZyoQw?t=1938
> It about 32:18 - 32:20
 
On YouTube, you can append an easily readable timestamp in the format
&t=XhYmZs to the end to go directly to an hour, minute, second, as in:
 
https://youtu.be/-KfI6qZyoQw?t=32m17s
https://www.youtube.com/watch?v=-KfI6qZyoQw&t=32m17s
 
The hour's not required, but if you don't have a minute use 0m as in
"&t=0m7s" to go straight to 7s in.
 
Thank you,
Rick C. Hodgin
"Chris M. Thomasson" <invalid@invalid.invalid>: Jun 07 01:43PM -0700

On 6/6/2017 6:31 PM, Rick C. Hodgin wrote:
> https://www.youtube.com/watch?v=-KfI6qZyoQw&t=32m17s
 
> The hour's not required, but if you don't have a minute use 0m as in
> "&t=0m7s" to go straight to 7s in.
[...]
 
Thank you for that information Rick. :^)
Ralf Goertz <me@myprovider.invalid>: Jun 07 10:20AM +0200

Am Tue, 6 Jun 2017 18:30:13 +0200
> the encoding, and when you put it at the start of an UTF-16 encoded
> sequence then it additionally indicates the byte order, hence the
> acronym.
 
But that's even worse in my opinion. Who in his right mind would want to
mix encodings in a single file? And if encodings are not mixed than we
don't need BOMs in the middle of a file. It might be okay to have to
check for a BOM at the beginning but when we read a line from the middle
we should not be supposed to check every wchar_t for it being a byte
order mark.
 
Consider a utf8 encoded file with BOM reading:
 
is ø the empty set symbol?
is ∅ the empty set symbol?
 
and this small program
 
#include <iostream>
#include <locale>
#include <string>
 
using namespace std;
 
int main() {
ios::sync_with_stdio(false);
wstring s;
locale loc("C.UTF-8");
wcin.imbue(loc);
while (getline(wcin,s)) {
wcout<<s.size()<<endl;
}
return 0;
}
 
 
Due to the BOM we get this output:
 
27
26
 
although both lines are of the same length when read as wide strings.
The BOM at the beginning can easily be dealt with because it can/should
be expected. But to have to check every wide character just because a
BOM is allowed everywhere? It would be a nightmare.
 
Interestingly, the option to switch on the use of BOMs in vim is
 
:set bomb
 
That says it all. ;-)
Jerry Stuckle <jstucklex@attglobal.net>: Jun 06 08:12PM -0400

On 6/6/2017 5:20 PM, Alf P. Steinbach wrote:
>> You would have to have the macro before every call to malloc() to ensure
>> you don't have a problem.
 
> I'm sorry but this is not meaningful; it's utter nonsense.
 
Ah, once again you can't argue facts, so you resort to denigrating comments.
 
>> And during development (or even during maintenance), the type of p may
>> need to be changed for one reason or another.
 
> Again I'm sorry but this is not meaningful; it's utter nonsense.
 
Ah, once again you can't argue facts, so you resort to denigrating
comments. The fact is - types DO change during both development and
maintenance.
 
 
>> The cost is only a few cycles at compile time - less, in fact, than the
>> cost of your macro.
 
> And yet again I'm sorry but this is not meaningful; it's utter nonsense.
 
Ah, once again you can't argue facts, so you resort to denigrating
comments. The truth hurts, doesn't it?
 
>> no type conversions between pointers to different types, like there are
>> with other types. Even a first year student understands that.
 
> Oh. I'm sorry. This is not meaningful, it's nonsense.
 
It wouldn't be to you, but it is to a first year student.
 
Ah, once again you can't argue facts, so you resort to denigrating comments.
 
 
> You COULD look at the comments on that guideline.
 
> Given the above avalanche of nonsense I guess relying on authority is a
> reasonable strategy, but do be careful about that.
 
I did, and I stand by my comments.
 
Ah, once again you can't argue facts, so you resort to denigrating comments.
 
But then you expect people to rely on YOU - but not on CERT? It doesn't
work that way, Alf.
 
You have yet to show any reason why your way is better than CERTs. All
you have done is call CERTs recommendations "lunacy". The last resort
of those who can't argue facts.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Ian Collins <ian-news@hotmail.com>: Jun 07 12:46PM +1200

On 06/ 7/17 09:15 AM, Jerry Stuckle wrote:
 
 
> Personally, I take CERT's guidelines over any I see in a newsgroup.
> Those people know how to develop safe code.
 
"Robert Seacord
 
Much earlier, John Bode suggested the following compliant solution:
widget *p;
...
p = malloc(sizeof *p);
 
as well as the use of Abstract Data Types (ADT). The ADT discussion is
probably orthogonal to this guideline, but the approach of taking the
sizeof *p seems to be a reasonable compliant solution that would seem to
be noncompliant given the title of this rule."
 
--
Ian
Jerry Stuckle <jstucklex@attglobal.net>: Jun 06 10:11PM -0400

On 6/6/2017 8:46 PM, Ian Collins wrote:
> probably orthogonal to this guideline, but the approach of taking the
> sizeof *p seems to be a reasonable compliant solution that would seem to
> be noncompliant given the title of this rule."
 
That is correct. And you should also notice that was not accepted as
the preferred solution, due to the reasons I mentioned.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Lynn McGuire <lynnmcguire5@gmail.com>: Jun 06 06:37PM -0500

"C++17 in details: fixes and deprecation"
http://www.bfilipek.com/2017/05/cpp17-details-fixes-deprecation.html
 
"The new C++ Standard - C++17 - is near the end to be accepted and
published. There's already a working draft, and not that long ago it
went to the final ISO balloting. It's a good occasion to learn and
understand what are the new features."
 
"Let's start slowly, and today we'll look at language/library fixes and
removed elements."
 
Lynn
woodbrian77@gmail.com: Jun 06 05:14PM -0700

On Tuesday, June 6, 2017 at 6:38:07 PM UTC-5, Lynn McGuire wrote:
 
> "Let's start slowly, and today we'll look at language/library fixes and
> removed elements."
 
> Lynn
 
2017 C++Now videos are available from Duckduckgo:
 
https://duckduckgo.com/?q=c%2B%2Bnow+2017&t=qupzilla&iar=videos
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
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)