Tuesday, May 29, 2018

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

Lynn McGuire <lynnmcguire5@gmail.com>: May 29 06:12PM -0500

"Why does most C/C++ developer prefers char *c instead of char* c?"
https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx
 
I prefer "char * c".
 
Lynn
Melzzzzz <Melzzzzz@zzzzz.com>: May 29 11:24PM

> "Why does most C/C++ developer prefers char *c instead of char* c?"
> https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx
 
> I prefer "char * c".
 
char* c;
but
char *c,*d;
 
--
press any key to continue or any other to quit...
Vir Campestris <vir.campestris@invalid.invalid>: May 29 09:41PM +0100

On 28/05/2018 14:23, Scott Lurndal wrote:
 
>> You get an exception when you access a page that you're not allowed to.
 
> Which, of course, takes longer than an access that doesn't get
> an exception. Covert channel #1.
 
I pick an address that might be a kernel address, and might be an
invalid address. CPU traps out to privileged code, and says to the
kernel "What do I do now?" Privileged code fiddles around for a while,
then passes control to the exception handler in the naughty program.
This will take quite a long time. IF you're really concerned about
security your kernel will make sure it's a _loooooong_ time.
 
Obviously in either case this will take much longer than accessing an
address to which the program has access. But the times for the two cases
need not be significantly different.
 
 
>> System flushes the cache.
 
> Which, of course, changes the timing of the code that executes following
> the flush. Covert channel #2.
 
Yes. But since the app has been given an exception it _knows_ it wasn't
allowed to access the address. And it will soon realise the cache is
empty (if it is that way inclined) because everything will be slow for a
while.
 
 
>> There is no way to determine whether this is an illegal address, or a
>> forbidden address - unless of course the system chooses to tell you.
 
> Doesn't matter. It's information that can be used.
 
There is no difference between the exception code nor the timing between
an illegal access fault for an invalid address, and an address which is
merely invalid for that privilege level. There is no information to use.
> information to those attempting to subvert the kernel; and certainly
> key to the exploits enabled by Spectre/Meltdown. Amongst other things,
> it allows the attacker to subvert KASLR.
 
OK, good point there. I still don't see how you get to differentiate the
two cases.
 
Andy
Sky89 <Sky89@sky68.com>: May 29 03:16PM -0400

Hello....
 
Read this:
 
 
I correct a typo, please read again..
 
I explain my work..
 
I am an inventor of scalable algorithms and other softwares..
 
Now you have to understand me more, why do you think i am posting on CPUs
and computers ?
 
Because parallel programming will "like" extend rapidly Moore's Law,
because look for example at this:
 
Intel: 1,000-core Processor Possible
 
An experimental Intel chip shows the feasibility of building processors
with 1,000 cores, an Intel researcher has asserted.
 
The architecture for the Intel 48-core Single Chip Cloud Computer (SCC)
processor is "arbitrarily scalable," said Intel researcher Timothy
Mattson, during a talk at the Supercomputer 2010 conference being held
this week in New Orleans.
 
Read more here:
 
https://www.pcworld.com/article/211238/intel_1000core_processor_possible.html
 
 
And look at this:
 
3D stacked computer chips could make computers 1,000 times faster
 
Read more here:
 
https://www.zmescience.com/research/technology/3d-stacked-computer-chips-43243/
 
 
This is why parallel computing and 3D stacking of memory and CPUs
beyond 1000 cores of Intel above, will make CPUs and computers rapidly
very powerful and this will permit to revolutionize rapidly
artificial intelligence and genetics etc., Look for example at the
following video to understand more:
 
Michio Kaku: Genetics: The Key to Immortality?
 
https://www.youtube.com/watch?v=QsHuGQieyjY
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 29 03:08PM -0400

Hello...
 
 
I explain my work..
 
I am an inventor of scalable algorithms and other softwares..
 
Now you have to understand me more, why do you think i am posting on CPUs
and computers ?
 
Because parallel programming will "like" extend rapidly Moors law,
because look for example at this:
 
Intel: 1,000-core Processor Possible
 
An experimental Intel chip shows the feasibility of building processors
with 1,000 cores, an Intel researcher has asserted.
 
The architecture for the Intel 48-core Single Chip Cloud Computer (SCC)
processor is "arbitrarily scalable," said Intel researcher Timothy
Mattson, during a talk at the Supercomputer 2010 conference being held
this week in New Orleans.
 
Read more here:
 
https://www.pcworld.com/article/211238/intel_1000core_processor_possible.html
 
 
And look at this:
 
3D stacked computer chips could make computers 1,000 times faster
 
Read more here:
 
https://www.zmescience.com/research/technology/3d-stacked-computer-chips-43243/
 
 
This is why parallel computing and 3D stacking of memory and CPUs
beyond 1000 cores of Intel above, will make CPUs and computers rapidly
very powerful and this will permit to revolutionize rapidly
artificial intelligence and genetics etc., Look for example at the
following video to understand more:
 
Michio Kaku: Genetics: The Key to Immortality?
 
https://www.youtube.com/watch?v=QsHuGQieyjY
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 29 03:06PM -0400

Hello..
 
 
I explain my work..
 
I am an inventor of scalable algorithms and other softwares..
 
Now you have to understand me more, why do you think i am posting on CPUs
and computers ?
 
Because parallel programming will "like" extend rapidly Moors law,
because look for example at this:
 
Intel: 1,000-core Processor Possible
 
An experimental Intel chip shows the feasibility of building processors
with 1,000 cores, an Intel researcher has asserted.
 
The architecture for the Intel 48-core Single Chip Cloud Computer (SCC)
processor is "arbitrarily scalable," said Intel researcher Timothy
Mattson, during a talk at the Supercomputer 2010 conference being held
this week in New Orleans.
 
Read more here:
 
https://www.pcworld.com/article/211238/intel_1000core_processor_possible.html
 
 
And look at this:
 
3D stacked computer chips could make computers 1,000 times faster
 
Read more here:
 
https://www.zmescience.com/research/technology/3d-stacked-computer-chips-43243/
 
 
This is why parallel computing and 3D stacking of memory and CPUs
beyond 1000 cores of Intel above, will make CPUs and computers rapidly
very powerful and this will permit to revolutionize rapidly
artificial intelligence and genetics etc., Look for example at the
following video to understand more:
 
Michio Kaku: Genetics: The Key to Immortality?
 
https://www.youtube.com/watch?v=QsHuGQieyjY
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 29 02:36PM -0400

Hello,
 
 
Here is my new invention:
 
I am finishing a C++ implementation of a "scalable" reference counting
with a scalable C++ shared_ptr and weak_ptr. Because the implementation
in Boost and C++ are not scalable. I will bring to you my new scalable
algorithms soon.
 
 
So stay tuned !
 
 
Thank you,
Amine Moulay Ramdane.
Juha Nieminen <nospam@thanks.invalid>: May 23 06:24AM

Why doesn't the last line compile?
 
//------------------------------------------------------------
struct Test1 {};
struct Test2 { constexpr Test2() {} };
 
struct Container
{
struct Test3 {};
struct Test4 { constexpr Test4() {} };
 
static constexpr Test1 object1; // Compiles
static constexpr Test2 object2; // Compiles
static constexpr Test3 object3; // Compiles
static constexpr Test4 object4; // Does not compile
};
//------------------------------------------------------------
Ian Collins <ian-news@hotmail.com>: May 23 10:08PM +1200

On 23/05/18 21:07, Paavo Helde wrote:
>>> static constexpr Test4 object4; // Does not compile
>>> };
>>> //------------------------------------------------------------
 
<snip>
 
 
> This will just declare a bunch of functions, which is probably not what
> OP had in mind. One ought to use object[1234]{}, but this doesn't
> compile for Test4 either:
 
That was what I meant to type...
 
> constant expression before its definition is complete
> static constexpr Test4 object4{}; // Does not compile
> ^
 
I wonder if it is to do with where inline member function definitions
are parsed? The nested class is within the scope of Container, so where
is a local class constructor complete?
 
--
Ian.
Paavo Helde <myfirstname@osa.pri.ee>: May 23 12:07PM +0300

On 23.05.2018 10:27, Ian Collins wrote:
> static constexpr Test4 object4; // Does not compile
> ^~~~~~~
 
> Change the objects to object[1234]():
 
This will just declare a bunch of functions, which is probably not what
OP had in mind. One ought to use object[1234]{}, but this doesn't
compile for Test4 either:
 
>g++ main.cpp
main.cpp:15:33: error: 'constexpr Container::Test4::Test4()' called in a
constant expression before its definition is complete
static constexpr Test4 object4{}; // Does not compile
^
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 23 12:54PM +0200

On 23.05.2018 08:24, Juha Nieminen wrote:
> static constexpr Test4 object4; // Does not compile
> };
> //------------------------------------------------------------
 
It's clearly a bug, but the question is whether it's in the compilers or
in the standard.
 
I'd guess that the compilers somehow incorrectly regard `Test4` as
incomplete because the containing class `Container` is incomplete.
 
As a workaround it "should" work to just provide the explicit
initialization that the error messages quoted else-thread, refer to.
 
 
Cheers!,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 23 04:46PM +0100

On Wed, 23 May 2018 13:26:46 GMT
> Paavo Helde <myfirstname@osa.pri.ee> writes:
[anip]
> >programs.
 
> Sure it can. With care. Unixware even has a 'forkall()' system call
> that clones all the parent threads.
 
I thought it was SunOS/Solaris which had forkall(). Are you sure about
unixware?
 
However, forkall() doesn't solve the issue. Before forkall()ing, the
forking thread has the same problem of needing to synchronise with other
threads. In the case of forkall() this is so that the other threads are
in a state which allows them to be duplicated; in the face of fork()
this is so that they are in a state which allows them not to be
duplicated. Forkall() cannot be performed willy nilly without other
threads' knowledge or consent, in particular with respect to side
effects. Forkall()ing a process where a thread happens to be doing
some IO is an obvious example of a disaster waiting to happen.
forkall() just redistributes the problem.
 
There is some discussion by Butenhof of this here in the context of the
uselessness of pthread_atfork() (that was before our dear spammer drove
the newsgroup concerned out of use):
https://groups.google.com/d/msg/comp.programming.threads/ThHE32-vRsg/3j-YICgSQzoJ
boltar@cylonHQ.com: May 23 09:45AM

On Tue, 22 May 2018 09:22:53 -0700
 
>> If I have to explain why its an ugly hack there's little point discussing it.
 
>Nope. You're the one making an assertion without providing evidence.
>Therefore you are the one who has to back up the assertion.
 
Because starting up an entirely new process to pass a command line parameter
that has to be parsed first then do an explicit jump or call to a particular
function or location is utterly prehistoric compared to doing a switch() on
the return value of fork(). Its aesthetically ugly and inefficient from a
processor POV too.
boltar@cylonHQ.com: May 23 09:54AM

On Tue, 22 May 2018 21:42:40 +0200
 
>>What do you think fork() does?
 
>It creates a copy of the current process, which in most use cases is
>immediately disposed afterwards by calling one of the exec() variants.
 
In most use cases? The shell, sure. Most other programs that use fork use it
to undertake multi process processing.
 
>Creating that unwanted copy may be expensive in the first place,
>depending on the OS and MMU architecture. And it has ugly side-effects
>for programs dealing with a lot of open handles, especially socket handles.
 
Not at all. The open handles are a necessity for a lot of things and there
is the SOCK_CLOEXEC option to automatically close sockets on an exec anyway.
 
>running an arbitrary exe, passing over only explicitly specified
>information through command line parameters, pipes, or environment
>variables.
 
Windows approach is a poor hack presumably because starting a new process
from scratch is a lot simpler than effectively splitting one in 2 and
having to manage everything that goes with that.
Paavo Helde <myfirstname@osa.pri.ee>: May 23 02:22PM +0300


> Windows approach is a poor hack presumably because starting a new process
> from scratch is a lot simpler than effectively splitting one in 2 and
> having to manage everything that goes with that.
 
And since when is a simpler way to do something called a "poor hack"?
 
With fork+exec one needs to make sure that all the irrelevant open
files, sockets and pipes (including the ones created by any third party
libraries) have the proper FD_CLOEXEC flags attached. Yes, this is
complicated and there are ugly hacks used to forcible close them. At
least in Windows one needs to create inheritable handles explicitly and
CreateProcess() function has the bInheritHandles parameter which gives
another simple way to control it. But I guess this is too simple for
your taste.
"Jouko Koski" <joukokoskispam101@netti.fi>: May 29 01:47PM +0300

Bjarne Stroustrup himself is expressing some concerns about the C++
language development:
 
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
 
I'm afraid that some of these concerns should have applied already
in earlier rounds of the standardization, but it is good that they
are stated at least now.
 
--
Jouko
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 29 04:24PM +0200

On 29.05.2018 12:47, Jouko Koski wrote:
 
> I'm afraid that some of these concerns should have applied already
> in earlier rounds of the standardization, but it is good that they
> are stated at least now.
 
Strong words,
 
> Together [the proposals] are insanity to the point of endangering the
> future of C++
 
 
… but he's right on the mark.
 
 
Cheers!,
 
- Alf
scott@slp53.sl.home (Scott Lurndal): May 29 03:45PM


>Strong words,
 
>> Together [the proposals] are insanity to the point of endangering the
>> future of C++
 
 
That horse left the stable after C++11.
woodbrian77@gmail.com: May 29 10:48AM -0700

On Tuesday, May 29, 2018 at 5:47:18 AM UTC-5, Jouko Koski wrote:
 
> I'm afraid that some of these concerns should have applied already
> in earlier rounds of the standardization, but it is good that they
> are stated at least now.
 
It's hard to imagine C++ 2020 being a big success.
I hope it won't be a dud, but ...
 
 
Brian
Ebenzer Enterprises
http://webEbenezer.net
legalize+jeeves@mail.xmission.com (Richard): May 23 02:53PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>(Also, it annoys me when people call C++ "cpp", since cpp is also the
>C preprocessor.)
 
Web thingies notoriously confuse + with ' ' because of URL encodings.
--
"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>
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 23 07:10AM

On Mon, 2018-05-21, Christiano wrote:
> std-discussion and I want to suggest to isocpp.org to add comp-lang-cpp
> here:
> https://isocpp.org/std/forums
 
Hasn't comp.lang.c++ always been unrelated to the commitee?
Do you perhaps mean comp.std.c++?
 
> This is being discussed here:
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/pAL2dOe9MIk
 
> I would like to know your opinion.
 
Not interested, personally.
 
(Also, it annoys me when people call C++ "cpp", since cpp is also the
C preprocessor.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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: