Friday, October 25, 2019

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

woodbrian77@gmail.com: Oct 24 07:39PM -0700

Shalom
 
I'm looking for someone interested in using my messaging
and serialization library:
https://github.com/Ebenezer-group/onwards
 
. I'll spend 16 hours/week for six months on your
project if we use my software as part of the project.
More info here: http://webEbenezer.net/about.html
.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
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.
"Öö Tiib" <ootiib@hot.ee>: Oct 25 04:06AM -0700

On Friday, 25 October 2019 10:12:22 UTC+3, David Brown wrote:
 
> 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.
 
That isn't even spam. That middleware writer has been in same
hard-to understand state for more than decade. Perhaps it is
search for email correspondents.
 
> 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.)
 
It is perhaps not bribe but absolute must ... without woodbrian
no one can imagine how to integrate that thing into anything.
Competitors offer well-documented header only library under
BSD license like that: <https://github.com/USCiLab/cereal>
So he has to provide something to overcome that chasm of
difference in ease of usage.
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.
David Brown <david.brown@hesbynett.no>: Oct 25 05:11PM +0200

On 25/10/2019 13:11, Juha Nieminen wrote:
>> 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.
 
As I understand it (and I hope he'll correct any mistakes I make), he is
running a company based on software services, including this
"middleware". He does not charge any money for this serialisation
library or the use of his "online generator", but is presumably hoping
that people who use it will pay for other development services. He has
offered sponsorship money and time resources to anyone using the
middleware - this is clearly a business prospect, with the expectation
that the user will pay for other services or at least provide a
reference as advertising for other customers.
 
His post is therefore an unsolicited commercial post - spam.
 
If one of the more helpful posters in the group were to make a small,
one-off announcement of a new and exciting product they had made, I
think many people would not object. But a substantial proportion of
Brian's posts are spam like this, or direct requests for other people to
support his commercial work with reviews, suggestions, and other help -
often such spam hijacks other people's threads. (I am quite happy with
his on-topic posts and discussions about C++.)
 
No, I don't think I am being too harsh - and yes, this is because of his
past behaviour in this newsgroup.
 
 
>> 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.
 
My advice here was given sincerely. I don't think it is right for him
to post spam in this group, but I am still happy to give suggestions to
help his business.
red floyd <no.spam@its.invalid>: Oct 24 08:25PM -0700

On 10/24/19 1:46 AM, Jorgen Grahn wrote:
> 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.
 
Or, close all fds, set all signals to SIG_IGN, and run the following
loop:
 
for (;;) pause();
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.
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);
Soviet_Mario <SovietMario@CCCP.MIR>: Oct 25 09:49AM +0200

Il 24/10/19 20:49, Paavo Helde ha scritto:
> 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.
 
almost
 
I was thinking slightly differently.
The requirements of a pure static object (not using malloc,
which is suitable only for fixed size arrays and strings,
not to dynamic ones) would be assessed at startup, that is
at the earliest stage of runtine, when the program is loading.
Either the static ram is enough and the program goes on to
never mind about any more, or not and it aborts.
 
Dynamically allocation may happen at any time during the
run, and it can fail to provide ram umpredictably. So we
would have a strange STATIC object without storage. I'm not
saying this would be a common scenario : just a violation of
the pact of the reserved ram in advance.
 
Now when one use the STATIC qualifier it might want more
than one effect, but one of them is just : being sure since
load that the ram requirements of a crucial object are
fulfilled or else to abort.
 
A static string entailing some dynamic allocation is strange
to me
 
> 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?
 
yes sort of
 
> No, it isn't, in
 
ah ... I take note :\
 
> C++ the lifetime of an object with a non-trivial constructor
> begins when its initialization is complete. This only
> happens at run-time.
 
necessarily so, but ... HOW EARLY ?
I believed STATIC qualified objects were to be created at
LOADING of the program, not later, at least RAM would have
been reserved : it the actual data for initialization became
available later, then that ram would have been inited later,
but still just reserved.
 
If not the staticness seems to me rather faint :\
 
but ok, nice to learn things and change mind about my
misconceptions.
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
"Öö Tiib" <ootiib@hot.ee>: Oct 25 04:18AM -0700

On Friday, 25 October 2019 10:50:09 UTC+3, Soviet_Mario wrote:
 
> If not the staticness seems to me rather faint :\
 
> but ok, nice to learn things and change mind about my
> misconceptions.
 
The statics are initialized before running main in unspecified
order. That can cause famous fiasco that is also in FAQ:
<https://isocpp.org/wiki/faq/ctors#static-init-order>
 
Perhaps you find couple days to look over the whole FAQ,
C++ is *full* of "commonly misunderstood aspects" that
can pretty much work like bear traps.
Soviet_Mario <SovietMario@CCCP.MIR>: Oct 25 04:04PM +0200

Il 25/10/19 13:18, Öö Tiib ha scritto:
 
> Perhaps you find couple days to look over the whole FAQ,
> C++ is *full* of "commonly misunderstood aspects" that
> can pretty much work like bear traps.
 
I'm wandering among FAQs ... my God, how many situations of
danger I've never ever thought about ! :o
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 25 02:21AM -0700

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 first I split the static library file into individual object files:
 
ar -x libwhatever.a
 
And then I moved the files into four different folders, and made four library files:
 
cd 1
ar -r lib1.a *
cd ../2
ar -r lib2.a *
cd ../3
ar -r lib3.a *
cd ../4
ar -r lib4.a *
 
And so finally I linked my project with these 4 files.
 
The linking failed, there were undefined references.
 
Is there something I'm missing here?
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.
"Öö Tiib" <ootiib@hot.ee>: Oct 25 05:15AM -0700

On Friday, 25 October 2019 12:21:47 UTC+3, 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.
 
Git isn't designed as storage of frequently changing large binary
files. Common solutions are:
1) avoid doing that, store the textual source from what such
files are compiled or generated.
2) use git LFS (literally "Large File Storage") extension for large
binary files.
 
Why you had undefined references to symbols is impossible
to tell without actual reproducible example. Linkers are rather
dumb so perhaps you do not put the libraries in correct order
or there is cyclic dependency between those.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 25 03:21PM +0300

On 25.10.2019 12:21, Frederick Gotham wrote:
 
> And so finally I linked my project with these 4 files.
 
> The linking failed, there were undefined references.
 
> Is there something I'm missing here?
 
First, it appears that you did not read the error messages and did not
find out which piece is missing which symbols and where they should come
from. So we must use our crystal balls here and figure this out in blind.
 
Anyway, the most obvious error would be to link the pieces in the wrong
order. Beware that in case of circular dependencies there might not be a
right order, maybe one could solve it by listing the pieces twice.
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 25 06:28AM -0700

On Friday, October 25, 2019 at 1:21:19 PM UTC+1, Paavo Helde wrote:
 
> Anyway, the most obvious error would be to link the pieces in the wrong
> order.
 
 
Thank you, this hadn't crossed my mind. A function in "1.a" must be looking for a function that resides in "2.a".
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 25 06:31AM -0700

On Friday, October 25, 2019 at 12:21:25 PM UTC+1, Ian Collins wrote:
 
> So don't do that. There's seldom a need to commit generated files to SCM.
 
 
I am deliberately obfuscating my code. I'm working on a security product, and so after I produce my binary executables and libraries, I run them through a decompiler and try to see how difficult it would be to reverse-engineer.
 
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.
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 25 02:34AM -0700

Here's what I'm going right now:
 
 
ifstream logfile("/etc/log.txt");

string hex_str;

copy_n( istream_iterator<char>(logfile), sizeof(my_POD_object) * 2u, std::back_inserter(hex_str) );

boost::algorithm::unhex( hex_str.begin(), hex_str.end(), reinterpret_cast<uint8_t*>(&my_POD_object) );
 
 
. . .when really I would just prefer to do this:
 
 
ifstream logfile("/etc/log.txt");
 
boost::algorithm::unhex( istream_iterator<char>(logfile), istream_iterator<char>(logfile) + (sizeof(my_POD_object) * 2u), reinterpret_cast<uint8_t*>(&my_POD_object) );
 
but of course you can't add to an input iterator like that.
 
Is there some sort of trickery I can do here?
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.
"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.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 25 08:20AM +0200

> Interesting. Are you "pinning" with the CAS?
 
Yes, I pin entries in the LRU-list with a CAS so that they can't be
evicted. But that has nothing to do with the parallel updates of the
LRU-list.
 
So I describe it another time to give you a chance to guess how my
idea works: cache-hits cann occur paralell, i.e. the updating of the
links to push a LRU-entry to the first place can be done by an arbi-
trary numbr of threads. That's the most relevant case because cache
-hits have a high frequency. When new elements are inserted into the
LRU-list or flushed from it the LRU-list is exclusively locked. But
this doesn't hurt since I/O is usually slow in comparison to a cache
hit.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 25 05:43AM +0200

On 22.10.2019 11:11, Öö Tiib wrote:
 
> // Since C++17 there is uniform way
> std::cout << std::size(legacy) << std::endl;
> std::cout << std::size(values) << std::endl;
 
With C++20 we will get std::ssize(), which returns signed type. :)
 
template <class C>
constexpr ptrdiff_t ssize(const C& c);
// Returns: static_cast<ptrdiff_t>(c.size())
 
template <class T, ptrdiff_t N>
constexpr ptrdiff_t ssize(const T (&array)[N]) noexcept;
// Returns: N.
 
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r1.html>
 
I had the impression that there would also be a signed `ssize_t` type,
perhaps just as an alias of `ptrdiff_t`, but alas: my googling now
indicates there will not be such a type, so just
 
using Size = ptrdiff_t;
using Index = Size;
 
- Alf
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.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 25 06:42AM +0200

> That page is not part of the gcc compiler documentation, ...
 
"Auto-vectorization in GCC" under gcc.gnu.org.
 
> It does not describe limits of the code patterns that can be vectorised, ...
 
"Vectorizable Loops"
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)