- "Why does most C/C++ developer prefers char *c instead of char* c? Pin" - 2 Updates
- Forget about C++, C is not a low-level language either - 1 Update
- I correct a typo, please read again.. - 1 Update
- Read again, i correct - 1 Update
- I explain my work.. - 1 Update
- Here is my new invention - 1 Update
- static constexpr with inner type doesn't compile - 4 Updates
- Threads on Windoze (was Re: Let's call the <=> operator "trike") - 4 Updates
- Remember the Vasa! - 4 Updates
- Group comp-lang-cpp - 2 Updates
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:
Post a Comment