- Why I can't split a static library? - 2 Updates
- How all the cool kids are getting array lengths from C++11 onwards - 6 Updates
- Users needed - 4 Updates
- Thread must sleep forever (Try to double-lock mutex?) - 5 Updates
- The next technological singularity .. coming soon - 1 Update
- Lock-free LRU-cache-algorithm - 3 Updates
- Vector with memory from global storage (static duration) - 4 Updates
| Ian Collins <ian-news@hotmail.com>: Oct 26 12:21AM +1300 On 25/10/2019 22:21, Frederick Gotham wrote: > I added a static library to my project (Linux ".a" file), but then I > went to commit the changes to a repository, but the commit failed > because the ".a" file was too big. So don't do that. There's seldom a need to commit generated files to SCM. -- Ian. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 25 03:18PM On Fri, 2019-10-25, Frederick Gotham wrote: > My program would be too easy to reverse-engineer if I linked the > library dynamically, so I'm linking it statically and obfuscating it > as best I can. I'll not comment on obscurity as a technique for security, but what you write is orthogonal to what Ian Collins wrote. You don't have to commit libfoo.a binaries to SCM in order to link statically. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Oct 24 12:51PM +0200 On 24/10/2019 11:01, Bonita Montero wrote: >> gcc and clang produce using automatic vectorization? Because I have. > Have you checked the compiler-docs? They document which code-patterns > they can detect and vectorize. That are only very special patterns. Can you give links to these documentation pages for gcc and clang? |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 24 04:23PM +0200 https://gcc.gnu.org/projects/tree-ssa/vectorization.html |
| Real Troll <real.troll@trolls.com>: Oct 24 12:40PM -0400 On 22/10/2019 08:28, Frederick Gotham wrote: > std::cout << std::extent<decltype(values)>::value << std::endl; > } > Or is there an even nicer way? values.size(); |
| scott@slp53.sl.home (Scott Lurndal): Oct 24 03:50PM >On Wednesday, October 23, 2019 at 6:18:17 PM UTC+1, James Kuyper wrote: >I think it's likely that the modern use of "troll" on internet forums actually comes from the doll: https://en.wikipedia.org/wiki/Troll_doll >This makes the most sense to me out of all the possibilities (including your angling one). I've been on usenet for almost forty years; It has always been well understood that the term derives from the fishing usage. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 24 01:37PM +0200 > Can you give links to these documentation pages for gcc and clang? No, but I'll bet they're not cleverer as Intel-C++: https://software.intel.com/en-us/cpp-compiler-developer-guide-and-reference-automatic-vectorization-overview |
| Ian Collins <ian-news@hotmail.com>: Oct 25 05:05PM +1300 On 25/10/2019 09:44, David Brown wrote: > It is quite clear that you don't know about auto-vectorisation in > compilers - .. and you have been successfully tolled again :) -- Ian. |
| David Brown <david.brown@hesbynett.no>: Oct 25 09:11AM +0200 > project if we use my software as part of the project. > More info here: http://webEbenezer.net/about.html > . You do realise that spam is not appreciated in this group? If you want to talk about C++ aspects of your project, great. If you want to advertise your commercial company, do it elsewhere. (And my advice is don't advertise like that - it makes you sound utterly desperate. If you have been working on this system for years, and you have to offer heavy bribes to have any chance of getting a single user, then you should be questioning the business sense of the project.) |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 25 09:14AM +0200 There are already good serialization-frameworks like Google Protocol Buffers which are far supoerior to your rudimentary code. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 25 11:11AM > You do realise that spam is not appreciated in this group? > If you want to talk about C++ aspects of your project, great. If you > want to advertise your commercial company, do it elsewhere. To be completely honest, I think you are being a bit too harsh, probably based on his past behavior in this newsgroup. > desperate. If you have been working on this system for years, and you > have to offer heavy bribes to have any chance of getting a single user, > then you should be questioning the business sense of the project.) But you may have a point there. |
| Keith Thompson <kst-u@mib.org>: Oct 25 11:47AM -0700 David Brown <david.brown@hesbynett.no> writes: [...] > His post is therefore an unsolicited commercial post - spam. [...] Spam needn't be commercial. (This is a small quibble, not affecting your main point.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 25 04:07PM On Fri, 2019-10-25, Scott Lurndal wrote: > red floyd <no.spam@its.invalid> writes: >>On 10/24/19 1:46 AM, Jorgen Grahn wrote: ... >>loop: >> for (;;) pause(); > raise(SIGSTOP); The exec() solution has one more benefit: it frees up virtual memory. But we're pretty far offtopic now; I brought it up as a reminder that platform-specific features are sometimes the best tool for the job. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 24 05:38AM On Wed, 2019-10-23, Chris M. Thomasson wrote: > non-recursive mutex twice in the same thread is an error. This can be > solved multiple ways. The easy way is to create the Supervisor as a > service/ daemon. Robust mutexs can be used to detect when a process dies. The software (as I understand it) is Unix-specific; standard practice there is to have parent--child process relationships, and to use the wait() family of functions to detect when a child dies. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ian Collins <ian-news@hotmail.com>: Oct 25 05:02PM +1300 On 24/10/2019 18:38, Jorgen Grahn wrote: > The software (as I understand it) is Unix-specific; standard practice > there is to have parent--child process relationships, and to use the > wait() family of functions to detect when a child dies. Or simply use the platform's service management framework rather than reinventing it! -- Ian. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 24 08:46AM On Wed, 2019-10-23, Frederick Gotham wrote: >> the job. > I don't want to complicate the Supervisor, and so I'm happy to put > the gas_monitor process to sleep. In a way you /are/ complicating it already, by stretching the meaning of "supervise". Especially if there is some kind of heartbeat mechanism too, but maybe there isn't. If you /really/ want to sleep forever and consume minimal resources on Unix, the optimal way would be to close all file descriptors, release anything else which would survive an exec(), and exec() a tiny 'sleep_forever' binary. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Oct 25 02:33PM >Or, close all fds, set all signals to SIG_IGN, and run the following >loop: > for (;;) pause(); raise(SIGSTOP); |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 25 08:36PM +0100 Hi! The sequel to Google's "quantum supremacy" technological singularity in the form of "neos" my universal compiler than can compile ANY programming language is coming soon. https://neos.dev /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 24 11:06PM -0700 On 10/24/2019 9:53 PM, Bonita Montero wrote: >>> No, I'm not using ABA-counters. >> Are you embedding any state with a pointer? bit stealing? > No. Interesting. Are you "pinning" with the CAS? or does that fall to locking? Fwiw, I do like my hashed locks on pointer addresses. It can do many things, meta data makes it powerful in certain scenarios, also meta data in the pointer address itself can effect the hash function, fun times... Also, there is no need to lock the root. I remember you saying how my work would always have to lock the head when updating the double linked list wrt grabbing a LRU cache item. It can use lock-free here. Eluding the lock. Here is a pure lock-free version wrt a singly linked list. I am going to add the ability to delete from this: https://groups.google.com/d/topic/comp.lang.c++/7U_Zjb7qj98/discussion This is dynamic in nature. However, a LRU is easier because once its full, it does not need to grow. It just replaces the LRU. Not sure if I have to double link it or not. It might be a fun challenge to keep it a single linked list. Not sure if I want to use hashed locking, or go for pure lock-free. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 24 01:14PM -0700 On 10/24/2019 1:13 PM, Chris M. Thomasson wrote: >>> have to restart, or unroll if you will? >> No, I'm not using ABA-counters. > Are you embedding any state with a pointer? bit stealing? It can be fun to align pointers on a large boundary, and use that extra space for meta data. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 25 06:53AM +0200 >> No, I'm not using ABA-counters. > Are you embedding any state with a pointer? bit stealing? No. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 24 12:19AM +0100 On 23/10/2019 23:15, Keith Thompson wrote: > means that the elements will have the same storage duration as the > std::array object itself. (That's why the number of elements in > a std::array has to be known at compile time.) Wrong. std::string usually employs the "small string optimization" whereby small strings are allocated within the object itself. I have also created a "vecarray" container that does a similar thing for vectors. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 24 09:49PM +0300 On 24.10.2019 21:15, Soviet_Mario wrote: > I was just considering that one could not always have the full storage > (lifetime) control they expect. > I tend to think too much in a C-like mindshape surely What makes you think that? Are you maybe afraid that any dynamically allocated pieces in a static std::string object might somehow have shorter lifetime than the std::string object itself? That cannot be, this would ruin all invariants. Or more probably, maybe you think that the lifetime of a static std::string object has already begun before the program start, when it maybe occupies some bytes in some data section of the executable on the disk? No, it isn't, in C++ the lifetime of an object with a non-trivial constructor begins when its initialization is complete. This only happens at run-time. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 24 05:21PM +0300 On 24.10.2019 16:58, Öö Tiib wrote: > assert(s.length() == strlen(s.c_str())); > ... does not hold. So one byte is needed for length of > short string and other is needed for zero terminator. Right, thanks for the correction! Storing the length separately would also mean that it's not needed to calculate it as if by strlen() each time when needed (although strlen() should also by very fast on such small strings). |
| Juha Nieminen <nospam@thanks.invalid>: Oct 24 07:49AM > The small_vector has also preallocated capacity in it but can > grow over that using an allocator: > <https://www.boost.org/doc/libs/1_71_0/doc/html/boost/container/small_vector.html> I am talking about an allocator (usable with any standard library container), not a std::vector replacement. |
| 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