Friday, January 27, 2023

Digest for comp.lang.c++@googlegroups.com - 14 updates in 2 topics

Michael S <already5chosen@yahoo.com>: Jan 27 02:37AM -0800

On Friday, January 27, 2023 at 1:07:19 AM UTC+2, Frederick Virchanza Gotham wrote:
 
> Next I made a command line argument list from them: cat all_symbols.txt | awk '{print "--redefine-sym " $s "=SomeProgram_" $s}' | tr '\n' ' ' > cmd_line_args.txt
 
> Next I renamed all of the symbols in all of the object files: find -iname "*.o" | xargs -i -r -n1 objcopy `cat cmd_line_args.txt` "{}"
 
> After doing all that, I was assured that there wouldn't be a name collision, so I linked it all together and I didn't get a multiple definition error.
 
You still didn't explain what exactly do you try to achieve. And you didn't
explain what you don't like about normal method where you keep your
executable program as is and call them with spawn().
Paavo Helde <eesnimi@osa.pri.ee>: Jan 27 01:39PM +0200

27.01.2023 01:07 Frederick Virchanza Gotham kirjutas:
 
> Next I made a command line argument list from them: cat all_symbols.txt | awk '{print "--redefine-sym " $s "=SomeProgram_" $s}' | tr '\n' ' ' > cmd_line_args.txt
 
> Next I renamed all of the symbols in all of the object files: find -iname "*.o" | xargs -i -r -n1 objcopy `cat cmd_line_args.txt` "{}"
 
> After doing all that, I was assured that there wouldn't be a name collision, so I linked it all together and I didn't get a multiple definition error.
 
You sure get some points for originality in the software development.
Brings the no-code movement to new heights. Maybe we should call it
blind-source development?
 
My only question still remains: why???
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 27 03:44AM -0800

On Friday, January 27, 2023 at 11:40:19 AM UTC, Paavo Helde wrote:
 
> Brings the no-code movement to new heights. Maybe we should call it
> blind-source development?
 
> My only question still remains: why???
 
 
Program A writes into a TCP socket.
 
Program B reads in from a TCP socket.
 
I'm making one program, i.e. Program C, out of them.
 
Program A is about 10 times the size of Program B, so it makes sense to put B into A rather than put A into B.
 
Program C will have two threads, one thread running the 'main' of Program A, and one thread running the 'main' of Program B.
 
Since Program A and Program B are now in the one process and have access to each other's memory, I can do away with the TCP socket between them, and replace it with a lockfree container, e.g. boost::lockfree:spsc_queue.
Paavo Helde <eesnimi@osa.pri.ee>: Jan 27 03:13PM +0200

27.01.2023 13:44 Frederick Virchanza Gotham kirjutas:
 
> Program B reads in from a TCP socket.
 
> I'm making one program, i.e. Program C, out of them.
 
> Program A is about 10 times the size of Program B, so it makes sense to put B into A rather than put A into B.
 
This is non-sequitur. Also, in the previous line you said you put both
of them in C.
 
 
> Program C will have two threads, one thread running the 'main' of Program A, and one thread running the 'main' of Program B.
 
> Since Program A and Program B are now in the one process and have access to each other's memory, I can do away with the TCP socket between them, and replace it with a lockfree container, e.g. boost::lockfree:spsc_queue.
 
So what are the timings and which operations are too slow, and by how
much? I.e. is this project going to solve a real or an imagined problem?
 
You are planning extensive modifications in the source code of both A
and B. What prevents you to change the name of main() and other
conflicting symbols in the source code of A and B?
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 27 06:20AM -0800

On Friday, January 27, 2023 at 1:14:03 PM UTC, Paavo Helde wrote:
 
> > Program A is about 10 times the size of Program B, so it makes sense to put B into A rather than put A into B.
> This is non-sequitur. Also, in the previous line you said you put both of them in C.
 
C is the combination of A and B. In order to create C, I had three options:
(1) Start with nothing, then add in A, then add in B
(2) Start with A, then add in B
(3) Start with B, then add in A
 
I opted for option 2. So I forked A on Github, and started copying files from B into A.
 
> So what are the timings and which operations are too slow, and by how
> much? I.e. is this project going to solve a real or an imagined problem?
 
The main reason I'm doing this is to greatly simplify the running of these two programs. As things stand now, you have to run program A with a load of options:
 
progA --opt1 --opt2 --opt3=monkey.txt -k2 -f6 -m8 -c7 --save-n2
 
and then you have to create a virtual network device, then you've to alter the routing table, then you've to wait for progA to take effect, and then you've to analyse the effect that progA has had, and then you take what you analysed about progA and feed it as the command line to progB along with another bunch of command line arguments:
 
progB --opt1 --opt2=something_from_progA --opt3 -k -m -n3 --open-n2
 
I will be able to reduce this all to a simple one-liner at the command line:
 
progC --my-simple-option
 
Literally you will only need to give one simple command line argument when starting Program C.
 
Program C will start Program A (as a new thread), it will wait until A's ready, then it will create a virtual network device, then it will analyse the routing table and make changes, then it will run program B to communicate with program A.
 
> You are planning extensive modifications in the source code of both A
> and B. What prevents you to change the name of main() and other
> conflicting symbols in the source code of A and B?
 
I *do* change the symbol names, but not in the C++ source and header files. I wait until the object files are produced and then I use 'objcopy --redefine-sym' on the object files. It works and it means I can automate the process without having to write a C/C++ parser.
 
People have written scripts to do what I'm doing, i.e. to combine Program A and Program B, but my program (i.e. Program C) will be much more capable of dealing with adversity, for example it will analyse the routing table and try to find a free network even if there's already 8 entries in there. It will use ephemeral port numbers where possible.
 
The lockfree container between the two threads is just the icing on the cake although I'll smile when it's working and I get the CPU usage down below 1%.
scott@slp53.sl.home (Scott Lurndal): Jan 27 03:20PM


>Program A is about 10 times the size of Program B, so it makes sense to put B into A rather than put A into B.
 
>Program C will have two threads, one thread running the 'main' of Program A, and one thread running the 'main' of Program B.
 
>Since Program A and Program B are now in the one process and have access to each other's memory, I can do away with the TCP socket between them, and replace it with a lockfree container, e.g. boost::lockfree:spsc_queue.
 
So use mmap(2) or shmat(2) to share memory between the processes.
gazelle@shell.xmission.com (Kenny McCormack): Jan 27 03:32PM

In article <tr0d6f$1m1sc$1@dont-email.me>,
Paavo Helde <eesnimi@osa.pri.ee> wrote:
...
>You sure get some points for originality in the software development.
>Brings the no-code movement to new heights. Maybe we should call it
>blind-source development?
 
Blah, blah, blah.
 
>My only question still remains: why???
 
This isn't a question. It's just a slam.
 
(OP's situation is perfectly clear to me)
 
--
Republican Congressman Matt Gaetz claims that only ugly women want
abortions, which they will never need since no one will impregnate them.
Paavo Helde <eesnimi@osa.pri.ee>: Jan 27 05:57PM +0200

27.01.2023 16:20 Frederick Virchanza Gotham kirjutas:
 
> I will be able to reduce this all to a simple one-liner at the command line:
 
> progC --my-simple-option
 
> Literally you will only need to give one simple command line argument when starting Program C.
 
Sounds like a perfect jobs for a shell script.
 
>> and B. What prevents you to change the name of main() and other
>> conflicting symbols in the source code of A and B?
 
> I *do* change the symbol names, but not in the C++ source and header files. I wait until the object files are produced and then I use 'objcopy --redefine-sym' on the object files. It works and it means I can automate the process without having to write a C/C++ parser.
 
This is insane. Why would you need a C++ parser? How many name conflicts
do you exactly have, something like 3? Why do you need to automate
replacing them?
 
Compiling and linking libraries (static or dynamic) is very common
practice. I have some programs with tens of third-party libraries linked
in, mostly as static libraries. Never ever have I needed to use objcopy
or C++ parser with that.
 
It's true that when some C code is not written with the mindset to be
used in a library, it might contain some too generic names which may
easily get into conflict with other code. In C they have their own hacks
to cope with that. In C++ we luckily have a standard way to solve this,
just put all code in a library-specific namespace.
Christian Gollwitzer <auriocus@gmx.de>: Jan 27 07:53PM +0100

Am 27.01.23 um 15:20 schrieb Frederick Virchanza Gotham: > The main
reason I'm doing this is to greatly simplify the running of these two
programs. As things stand now, you have to run program A with a load of
options:
 
> I will be able to reduce this all to a simple one-liner at the command line:
 
> progC --my-simple-option
 
> Literally you will only need to give one simple command line argument when starting Program C.
 
Sounds like Program C could be a smallish shell script. Bash is an
excellent language for this kind of thing.
 
 
Christian
Christian Gollwitzer <auriocus@gmx.de>: Jan 27 08:03PM +0100

Am 27.01.23 um 16:32 schrieb Kenny McCormack:
 
>> My only question still remains: why???
 
> This isn't a question. It's just a slam.
 
> (OP's situation is perfectly clear to me)
 
The situation maybe clear, but I can't understand how anyone in their
right mind could think that editing object files is a good idea *when
you have the source code*
 
 
Christian
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 27 12:31PM -0800

On 1/27/2023 5:13 AM, Paavo Helde wrote:
>> access to each other's memory, I can do away with the TCP socket
>> between them, and replace it with a lockfree container, e.g.
>> boost::lockfree:spsc_queue.
 
You have to be careful with them.
 
 
 
> You are planning extensive modifications in the source code of both A
> and B. What prevents you to change the name of main() and other
> conflicting symbols in the source code of A and B?
 
Fwiw, are you familiar with the two lock queue?
 
https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 27 12:33PM -0800

On 1/27/2023 3:44 AM, Frederick Virchanza Gotham wrote:
 
> Program A is about 10 times the size of Program B, so it makes sense to put B into A rather than put A into B.
 
> Program C will have two threads, one thread running the 'main' of Program A, and one thread running the 'main' of Program B.
 
> Since Program A and Program B are now in the one process and have access to each other's memory, I can do away with the TCP socket between them, and replace it with a lockfree container, e.g. boost::lockfree:spsc_queue.
 
You can share memory between processes.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 27 12:35PM -0800

On 1/27/2023 12:31 PM, Chris M. Thomasson wrote:
>> conflicting symbols in the source code of A and B?
 
> Fwiw, are you familiar with the two lock queue?
 
> https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html
 
Oops, I meant to respond to:
 
Frederick Virchanza Gotham
 
Sorry Paavo.
Pawel Por <porparek@gmail.com>: Jan 27 12:27PM -0800

> fl.push_front
> __cdecl Dog::Dog(struct Dog &&)
 
> - Alf
 
Thank you for an answer. Please note that the MyList<T>::push_front(T &&v) argument is still passed by lvalue reference. Only inside the body of its function the move semantics is in use.
 
void push_front(T &&v)
{
p("T x = std::move( v ); (void) x;");
T x = std::move( v ); (void) x;
}
 
Output:
ml.push_front
T x = std::move( v ); (void) x;
Dog::Dog(Dog&&)
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)