Tuesday, January 31, 2023

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

Zorro <zorabih@gmail.com>: Jan 31 11:00AM -0800

On Tuesday, January 24, 2023 at 5:14:39 PM UTC-6, Chris M. Thomasson wrote:
> ________________
 
> void main
 
> God damn it!
 
Answer:
This program does not compile. You get error: Error 50001 (Linker): No entry points found.
So, what are you trying to run?
 
A function in Z++ must end with: "end;". In fact all constructs have their ending tag. For instance
if ... elsif ...else...endif;
 
Second, you can execute both, Debug and Release builds within z++visual. For you program, I checked they run great.
If you want to execute a Z++ program outside of z++visual, it must be in Release build. Otherwise you will get a message
telling you that your program contains debug info, and terminates.
 
To run a Z++ program from a console, you have two options. Either go the Release directory of your project (via cd), then type
 
zvp Sample.zxe
 
Z++ executable will have extension ".zxe" , find it in Release folder and do as above.
 
Or, do: zvp full-path/Sample.zxe
 
I really do not understand the call: "void main". Sorry for your trouble. However, the product works as documented.
 
Regards.
Zorro <zorabih@gmail.com>: Jan 31 11:07AM -0800

On Tuesday, January 24, 2023 at 6:42:07 PM UTC-6, Öö Tiib wrote:
> Can't even return if a program completed successfully or failed?
> Instead some kind of agents start to roam around autonomously
> and moan "Braiins!" Maybe that is what the "z" comes from.
 
Answer.
Your insult is without any basis. I have answered those who indicated they had trouble.
What do you mean: Can't even return if a program completed successfully or failed?
 
What did you do?
 
Insults and other tactics will not stop people who no better to give themselves a chance.
scott@slp53.sl.home (Scott Lurndal): Jan 31 07:27PM


>What did you do?
 
>Insults and other tactics will not stop people who no better to give themse=
>lves a chance.
 
I'm reluctant to interfere with the rant fest, but I believe Tiib was
commenting on the apparent inability of Z++ to return a completion
status to the program (e.g. shell) which executed the Z++ application;
which can then be subsequently used to determine the success of the
application (or a myriad of other uses) in a shell script or parent
process.
 
In C, that would be the final return statement in the function 'main'
which is specified to return a signed integer value.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 31 02:22PM -0800

> ________________
 
> void main
 
> God damn it!
 
I don't see any good reason why that should annoy anyone. C++ requires
main to return int (and C almost requires the same thing; the details
are off-topic here). There's no reason that a *different language*
should have the same rule (unless it's intended to be a strict superset
of C++, but I don't think it is). It's likely (I haven't checked) that
Z++ has some other mechanism for returning a status to the calling
environment; perhaps it can call std::exit().
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 31 02:29PM -0800

On 1/31/2023 2:22 PM, Keith Thompson wrote:
> of C++, but I don't think it is). It's likely (I haven't checked) that
> Z++ has some other mechanism for returning a status to the calling
> environment; perhaps it can call std::exit().
 
True. I just pointed out that a C programmer is going to possibly get
annoyed at the sheer sight of void main.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 31 02:29PM -0800

On Monday, January 30, 2023 at 10:58:59 AM UTC, Kenny McCormack wrote:
 
> I'm sure the Jonestown folks would state in all sincerity that they were
> not "indoctrinated". No one ever thinks it could happen to them.
 
 
Some things just feel wrong to us because of where we grew up and the people we had around us. I consider keeping a dog as a pet, and I'm happy to have people farm cows for us to eat beef. I wouldn't want dogs farmed for food though -- it just feels wrong to me, however in other parts of the world they eat dogs.
 
Some people won't eat dog, and some people won't edit a binary. You probably won't change that streak in them. It just feels wrong to some people.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 30 09:17PM -0800

On 1/23/2023 7:59 PM, Chris M. Thomasson wrote:
 
>>> https://groups.google.com/g/comp.lang.c++/c/FBqOMvqWpR4/m/gfFd4J2GBAAJ
>> I don't know this thread. I will read.
 
> Thank you. Any input is welcome, indeed.
 
Imagine using a node outside of the collector, ABA and all of the nodes
lifetime issues. Who is going to drive it home tonight? ;^)
 
https://youtu.be/xuZA6qiJVfU
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 30 09:20PM -0800

On 1/30/2023 9:17 PM, Chris M. Thomasson wrote:
 
> Imagine using a node outside of the collector, ABA and all of the nodes
> lifetime issues. Who is going to drive it home tonight? ;^)
 
> https://youtu.be/xuZA6qiJVfU
 
Actually reusing a node is a good thing! It can take a lot of pressure
off of a GC. When a user can stuff in the counter and has access to
DWCAS, well.... NICE!
Bonita Montero <Bonita.Montero@gmail.com>: Jan 31 06:57AM +0100

Am 20.01.2023 um 10:52 schrieb Chris M. Thomasson:
 
> How does it compare to RCU wrt read mostly, write rarely workloads?
 
RCU in userspace is pseudo-RCU.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 30 11:16PM -0800

On 1/30/2023 9:57 PM, Bonita Montero wrote:
> Am 20.01.2023 um 10:52 schrieb Chris M. Thomasson:
 
>> How does it compare to RCU wrt read mostly, write rarely workloads?
 
> RCU in userspace is pseudo-RCU.
 
poor mans rcu, in a sense... Fair enough?
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:

Monday, January 30, 2023

Digest for comp.lang.c++@googlegroups.com - 17 updates in 6 topics

Kunal Goswami <20cs06014@iitbbs.ac.in>: Jan 30 01:04PM -0800

Hii ,
How can we assure that only one object is created for a class. And when second do not happen.
 
Note - don't use counter .
 
Someone asked me this in an interview.
 
--
*Disclaimer: *This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
scott@slp53.sl.home (Scott Lurndal): Jan 30 09:28PM

>Hii ,
> How can we assure that only one object is created for a class. And when second do not happen.
 
>Note - don't use counter .
 
A static class member seems like a good starting point.
 
Is it required to be thread-safe and/or re-entrant?
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 30 01:39PM -0800

On Monday, January 30, 2023 at 9:04:19 PM UTC, 20cs wrote:
> How can we assure that only one object is created for a class. And when second do not happen.
 
> Note - don't use counter .
 
> Someone asked me this in an interview.
 
I'd probably have a global object "std::optional<SomeClass> g_object", and I'd protect it with an "std::recursive_mutex".
 
Any thread can 'emplace' or 'reset' it as they like so long as they lock the mutex first.
red floyd <no.spam.here@its.invalid>: Jan 30 01:51PM -0800

On 1/30/2023 1:28 PM, Scott Lurndal wrote:
 
>> Note - don't use counter .
 
> A static class member seems like a good starting point.
 
> Is it required to be thread-safe and/or re-entrant?
 
What Scott said. This is a well known design pattern called "Singleton".
 
class Singleton {
static Singleton the_singleton;
public:
static Singleton& get_object { return the_singleton; }
};
 
Singleton Singleton::the_singleton{};
legalize+jeeves@mail.xmission.com (Richard): Jan 30 04:24PM

[Please do not mail me a copy of your followup]
 
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
 
>https://www.zdnet.com/article/c-programming-language-and-safety-heres-where-it-goes-next/
 
>"There's been a shift towards 'memory safe' languages. So, can updates
>to C++ help it catch up in the eyes of developers?"
 
That article doesn't mention cpp2 specifically, but the ISO C++ paper[*]
linked by the article does mention cpp2. I find cpp2 to be an
appealing approach that preserves existing code bases and maintains
100% compatability with ISO C++.
 
Herb Sutter's video on cpp2:
<https://www.youtube.com/watch?v=ELeZAKCN4tY>
 
[*] <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2759r0.pdf>
--
"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>
wij <wyniijj5@gmail.com>: Jan 30 10:08AM -0800

On Tuesday, January 24, 2023 at 10:21:39 AM UTC+8, Lynn McGuire wrote:
 
> "There's been a shift towards 'memory safe' languages. So, can updates
> to C++ help it catch up in the eyes of developers?"
 
> Lynn
 
It is all about correctness and efficiency. The development of C++ has been deviating
the basics for many years, in searching for (blind) expressiveness.
David Brown <david.brown@hesbynett.no>: Jan 30 08:18AM +0100

On 29/01/2023 16:57, Frederick Virchanza Gotham wrote:
> solution is an abomination. If you don't have any qualms
> about editing object files, then I've given a few reasons
> why my solution is superior to editing source files.
 
That is a completely meaningless thing to write. Yes, if I think that
editing compiled files is a terrible idea, then I will think your idea
of editing compiled files is terrible - and if I don't have anything
against editing compiled files, then I won't object to it.
 
I /do/ have something against it - and it is not indoctrination.
Frankly, I haven't heard anyone suggest it before now, much less argue
either for or against it.
 
The norm, however, is that programmers write or edit source code, and it
is compiled and then linked. If you do something that is wildly
breaking that norm, you are going to cause chaos to anyone maintaining
the code or working with it later - so it is not something to consider
without a /huge/ benefit. And you don't have a huge benefit - you've
got nothing more than the laziness of not wanting to edit a few files.
(I don't think combining these programs like this in the first place is
a great idea, but that's a different matter.)
 
> definition and then cleaning up the resultant compiler errors,
> but that's work that might introduce bugs. And you've to
> re-do it every time the library is upgraded.
 
You've got to re-do your Frankenstein program for every code change
anyway. This is one reason why it is a bad idea to mix the different
programs (especially when they are security-related programs). You are
far better off using the programs as separate programs, or using libraries.
 
Once you have done the renaming once, you have a patchset and a git
branch. For many small updates to the original programs, you merely
need to re-apply the patches.
 
> -- with the binary editors on one side, and the binary intacters
> on the other. Cultural clash. Within one lifetime it's unlikely
> either of us will defect.
 
It is not about reliability of tools - it's about traceability and
making a clear, maintainable build that takes source and results in a
binary.
 
"Binary editing" can have its place. I use it all the time in my own
work in embedded systems - it is standard practice that after my
programs are built, debugged and tested as elf files, I have objcopy to
generate binary images to be flashed into an embedded system. It is
quite common that the binary file is augmented after the objcopy, with
checksums, programming information, and the like.
 
But that is done in a /controlled/ manner, an /expected/ manner - it is
a natural part of the build process. It is not some weird hack done in
code you don't really understand, in a way you don't fully comprehend,
as a lazy alternative to better methods.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 30 12:25AM -0800

On Monday, January 30, 2023 at 7:19:14 AM UTC, David Brown wrote:
 
> The norm, however, is that programmers write or edit source code, and it
> is compiled and then linked.
 
 
Generally speaking, when a person encounters something that they've never encountered before, they might react with suspicion, or they might react with intrigue. This is very much down to the person's mind frame and inner stillness. In some communities it is pervasive to react with suspicion, and in some communities it is pervasive to react with intrigue.
 
There are words we use to describe things we haven't seen before; we call them 'new', or 'strange', or 'abnormal', or 'odd', or 'out of the ordinary', or 'out of the norm'.
 
This dichotomy between "what is old" and "what is new" is an important part of some people's decision-making processes. Some people, when they come up with an idea, ask themselves, "Is this what everyone else is doing?", and if the answer is no then they might discard their idea. Personally I look at my own ideas and try to judge them by their own merits, rather than considering how frequently other people are doing it.
 
The only argument you've been able to pose here is that what I'm doing is not frequently done. You literally have no other argument. And the reason why you have no other argument is that my solution is superior for multiple reasons. In fact, you are arguing to me that instead of adding three lines to a Makefile (in fact it's only two lines because the 2nd can be piped into the 3rd), you think it's preferable to individually seek out and every use of the symbol in all of the source and header files, and to alter them individually. And then you will do this every time the library is upgraded. The only way that a sane and rational person could side with you here is if they were to agree that editing object files is taboo.
 
 
> breaking that norm, you are going to cause chaos to anyone maintaining
> the code or working with it later - so it is not something to consider
> without a /huge/ benefit.
 
 
Breaking the norm is fine when the consequences are either minimal or non-existent.
 
 
> got nothing more than the laziness of not wanting to edit a few files.
> (I don't think combining these programs like this in the first place is
> a great idea, but that's a different matter.)
 
 
Seriously. There is a possibility for introducing bugs any time you edit any part of a program. Editing source and header files by yourself (i.e. by a human) will always be more error-prone and susceptible to bug introduction than using an automated tool. The 'objcopy' program doesn't make typos, and it doesn't forget what it was supposed to be doing because the phone rang.
If the possibility of introducing new bugs can be eradicated (or at least greatly diminished) by using an automated tool, then a sane and rational person would use such a tool.
 
 
> You've got to re-do your Frankenstein program for every code change
> anyway.
 
 
I just copy the new source and header files in. If the library has a new source file that it didn't have before, I don't even have to change the Makefile because it use a wilcard: find -iname "*.c"
 
 
> This is one reason why it is a bad idea to mix the different
> programs (especially when they are security-related programs). You are
> far better off using the programs as separate programs, or using libraries.
 
 
Before I embarked on this endeavour to combine the programs, I considered what the complications might be. For example one of the programs might make a process-wide change that could adversely affect the other programs (for example if they used 'setrlimit' with 'RLIMIT_NOFILE' to limit the number of open files), or if one of them overloaded 'operator new'. Of course the most simple problem would be a name collision at compile time, for example if they both had a function called "save_settings", but I've found an automated solution to that problem using 'objcopy'.
 
 
> Once you have done the renaming once, you have a patchset and a git
> branch. For many small updates to the original programs, you merely
> need to re-apply the patches.
 
 
In my last job I wrote firmware for embedded Linux cameras. When building the firmware, we built a few dozen opensource libraries and we had a directory containing patch files for the libraries. The Makefile applied the patches before building the libraries. When we upgraded any library, we almost never were able to build it straight away, 9 times out of 10 there would be a patch failure. So I would have to get the old library, examine the effect of the patch on the old source file, and then try to create a new patch file compatible with the newer version of the file. All the while I might be introducing new bugs.
 
 
> It is not about reliability of tools - it's about traceability and
> making a clear, maintainable build that takes source and results in a
> binary.
 
 
Two lines in a Makefile.
 
 
> a natural part of the build process. It is not some weird hack done in
> code you don't really understand, in a way you don't fully comprehend,
> as a lazy alternative to better methods.
 
 
In the list of words I gave above to describe something not frequently seen, I forgot 'weird'.
 
My idea of editing object files isn't just a little bit superior -- it's vastly superior. Also I account for 'weak symbols' which you really need to be careful with.
Paavo Helde <eesnimi@osa.pri.ee>: Jan 30 10:52AM +0200

30.01.2023 10:25 Frederick Virchanza Gotham kirjutas:
 
> In my last job I wrote firmware for embedded Linux cameras. When building the firmware, we built a few dozen opensource libraries and we had a directory containing patch files for the libraries. The Makefile applied the patches before building the libraries. When we upgraded any library, we almost never were able to build it straight away, 9 times out of 10 there would be a patch failure. So I would have to get the old library, examine the effect of the patch on the old source file, and then try to create a new patch file compatible with the newer version of the file. All the while I might be introducing new bugs.
 
Let me guess - you attempted to apply diff patches in blind, not the
3-way merges provided by a proper version control system.
 
BTW, a proper way to use an open-source program as a library is to split
it up into a library and a small executable part, and convince the
project managers to accept those changes in the original repo. No
merging problems anymore.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 30 12:56AM -0800

On Monday, January 30, 2023 at 8:52:46 AM UTC, Paavo Helde wrote:
 
> Let me guess - you attempted to apply diff patches in blind, not the
> 3-way merges provided by a proper version control system.
 
 
Sometimes the new version of the library had deleted a function whose body was patched, and replaced it with another function by another name.
 
 
> it up into a library and a small executable part, and convince the
> project managers to accept those changes in the original repo. No
> merging problems anymore.
 
 
Yeah I could have built busybox and badvpn both as dynamic shared libraries. That's still an option.
I want to be able to provide 'ssh' as a statically linked executable though, and also as a fat binary to run on nearly any system.
David Brown <david.brown@hesbynett.no>: Jan 30 10:39AM +0100

On 30/01/2023 09:25, Frederick Virchanza Gotham wrote:
 
> There are words we use to describe things we haven't seen before; we
> call them 'new', or 'strange', or 'abnormal', or 'odd', or 'out of
> the ordinary', or 'out of the norm'.
 
Of course people should be sceptical to something new and unusual in a
software build. I don't know how many C and C++ programmers there have
been for the last few decades, but it is a /lot/. When someone comes up
with a radical divergence from established practices, the /correct/
reaction is scepticism. That does not mean it should immediately be
dismissed as a bad idea - it means you should have good justifications
for going outside the norm.
 
You don't have good reasons, other than a quick-fix hack. Sometimes a
hack is all you need. Sometimes an unusual solution is useful in rare
and niche circumstances. But if you want your program to be taken
seriously and used by other people, you need to have something that
other people are comfortable with. A hack solution is not that. An
unmaintainable cyborg program is not that. Amateur messing around with
security-critical code is not that.
 
Your solution here might work as a quick hack. But you are missing the
big picture. If you have any ambition for the program to be used
outside of your own testing on your own computer, you have to play with
others - you have to have a solution that others are comfortable working
with and using.
 
You've been given a variety of good advice and suggestions for
alternative ways to handle the situation. You can take your pick, or
combine them, or find other ways. Or you can try to persuade the rest
of the world to change.
 
 
Just to be clear here, the idea of being able to conveniently set up a
proxy via an ssh link is quite nice - I can see it appealing to some
people. But no one will use it when it is made the way you are
suggesting. If you put together a bash or Python script that started
the relevant programs with the right parameters, it could easily be a
useful little tool that could make its way into common Linux
distributions. But building it with glued bits of different projects,
with post-compilation muddling of object files, it will /never/ be
acceptable by anyone who takes security, reliability or maintainability
seriously.
gazelle@shell.xmission.com (Kenny McCormack): Jan 30 10:58AM

In article <tr7r0v$36k7e$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>I /do/ have something against it - and it is not indoctrination.
 
I'm sure the Jonestown folks would state in all sincerity that they were
not "indoctrinated". No one ever thinks it could happen to them.
 
--
The motto of the GOP "base": You can't *be* a billionaire, but at least you
can vote like one.
Daniel <danielaparker@gmail.com>: Jan 29 04:23PM -0800

On Sunday, January 29, 2023 at 7:01:17 AM UTC-5, Kenny McCormack wrote:
 
> that other thread - the one about modifying object modules using
> established working tools. You guys (both of you) need to look up what
> "IMHO" means - and start liberally using it in your posts.
 
I've always thought that acronym was superfluous, if not the author's,
whose other opinion could it possibly be?
 
Daniel
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 30 01:14AM

>> "IMHO" means - and start liberally using it in your posts.
 
> I've always thought that acronym was superfluous, if not the author's,
> whose other opinion could it possibly be?
 
It's not used to indicate /whose/ opinion it is, it's used to emphasise
that what is being presented in now firmly in the domain of opinion and
not fact.
 
--
Ben.
David Brown <david.brown@hesbynett.no>: Jan 30 08:22AM +0100

On 29/01/2023 18:23, Adam H. Kerman wrote:
 
> Oh for god's sake. Surely you must have noticed by now that "Pluted Pup"
> is just a sockpuppet who has been trolling you. Would you PLEASE spit
> out the damn hook already and stop troll feeding?
 
I have no idea who is or is not a troll in news.admin.net-abuse.usenet.
His posts do not stand out as being any worse than most of those from
that group (yours included).
Andrey Tarasevich <andreytarasevich@hotmail.com>: Jan 29 06:33PM -0800

On 01/27/23 12:27 PM, Pawel Por wrote:
 
> 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.
 
What are you talking about? Where did you get thet idea that "argument
is still passed by lvalue reference"? What behavior made you to draw
that conclusion?
 
> ml.push_front
> T x = std::move( v ); (void) x;
> Dog::Dog(Dog&&)
 
Aaaaand...? What are we expected to see in this output?
 
> I think it is related to the concept of "universal references" coined by Scott Mayers
 
No
 
--
Best regards,
Andrey
Mr Flibble <flibble@reddwarf.jmc.corp>: Jan 30 12:49AM

Hi!
 
neolib::format implemented in terms of std::vformat to provide span
details of formatted parameters in result text.
 
auto result1 = neolib::format("{0}:{1}", "xyzzy", 42);
auto result2 = neolib::format("{{0}}:{1}", "xyzzy", 42);
auto result3 = neolib::format("{0}:{{1}}", "xyzzy", 42);
auto result4 = neolib::format("{0}:{0}:{1}", "xyzzy", 42);
 
assert((result1.text == "xyzzy:42"));
assert((result1.args == neolib::format_result::arg_list{ { 0, 0, 5 },
{ 1, 6, 8 } }));
assert((result1.arg_span(0) == "xyzzy"));
assert((result1.arg_span(1) == "42"));
assert((result2.text == "{{0}}:42"));
assert((result2.args == neolib::format_result::arg_list{ { 1, 6,
8 } }));
assert((result2.arg_span(1) == "42"));
assert((result3.text == "xyzzy:{{1}}"));
assert((result3.args == neolib::format_result::arg_list{ { 0, 0,
5 } }));
assert((result3.arg_span(0) == "xyzzy"));
assert((result4.text == "xyzzy:xyzzy:42"));
assert((result4.args == neolib::format_result::arg_list{ { 0, 0, 5 },
{ 0, 6, 11 }, { 1, 12, 14 } }));
assert((result4.arg_span(0) == "xyzzy"));
assert((result4.arg_span(1) == "42"));
 
/Flibble
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:

Sunday, January 29, 2023

Digest for comp.lang.c++@googlegroups.com - 15 updates in 3 topics

Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 28 03:28PM -0800


> You know the symbol names map on to functions and variables in the source
> right? How do you think debuggers work?
 
In the debugger, the symbol will be 'busybox_read_back_twice" instead of "read_back_twice".
 
> Well if you strip them then it doesn't matter. Most people don't.
 
I can't recall if I've ever been given a release executable with the symbols left inside. I don't think I ever have.
 
> ??????!!!!
> I'm lost for words.
 
Let's say you combine two programs together and you try to link and you get a multiple definition error for a symbol called 'options' -- just like I did when I tried to combine 'busybox' with 'openssh'. Let's say that this symbol is used 17 times in busybox, and 63 times in openssh. Are you going to do a 'Find & Replace in Files' to change all of them? And what about if you see the following in the code:
 
int options;
 
namespace UDP {
int options;
}
 
namespace TCP {
int options;
 
void Func(void)
{
using namespace UDP;
 
int j = options;
}
}
 
Will you meticulously check all 81 uses of 'options' in both programs to make sure you're replacing the correct one? Or will you just replace all of them, so that even local stack variables are affected?
 
And what about when the preprocessor is used to make a variable name? For example:
 
#define OPT(name) name ## _option
 
int OPT(global) = 7;
 
int main(void)
{
global_option = 7;
}
 
After you've gone over all the 81 uses, a few months goes by and a new version of the library comes out, so now you 76 instead of 81 uses, and they're in different places so you have to go over them all over again.
 
Are you seriously telling me that editing the C++ source files will be less susceptible to introducing bugs than if you were to simply compile the source files to object files and then follow three simple steps:
Step 1) Get a list of all the exported symbols in all the object files:
find -iname "*.o" | xargs -i -r -n1 nm "{}" | grep -Ev "( U )|( W )|( w )" | cut -d ' ' -f3 | sort | uniq > a.txt
Step 2) Make a list of command line options to give to 'objcopy' :
cat a.txt | awk '{print "--redefine-sym "$$s"=busybox_"$$s }' > b.txt
Step 3) Run 'objcopy' on all the object files:
find -iname "*.o" | while read line; do cat b.txt | xargs -r -n2 objcopy $$line; done
 
I've put these 3 steps into a Makefile, and so now in the future if I upgrade either 'busybox' or 'badvpn', I don't need to go sorting out name collisions all over again.
 
I think your main boggle with what I'm doing owes to a decades-old belief that object file shouldn't be meddled with. The two programs, 'objcopy' and 'patchelf' are well written, and they do their job properly. There's nothing proprietary or elusive about the format of object files. In my last job I used 'patchelf' in a Makefile to compensate for a bug in a 3rd proprietary driver that I only had machine code for.
 
Editing object files is safer and quicker than editing C++ source files.
Paavo Helde <eesnimi@osa.pri.ee>: Jan 29 10:19AM +0200

29.01.2023 01:28 Frederick Virchanza Gotham kirjutas:
> }
> }
 
> Will you meticulously check all 81 uses of 'options' in both programs to make sure you're replacing the correct one? Or will you just replace all of them, so that even local stack variables are affected?
 
Why on earth should you search for 'options'? If there is a conflicting
function name 'options', you search for 'options(' in the "match whole
word" mode. It is enough to change the declaration and the definition (2
places in normal source code). Then you recompile the project and fix
the error lines (in case of C, you might need to turn the corresponding
warning into an error first).
 
This is one-time activity and you get clean code as a result. For
updating git forks one is supposed to use git merge anyway, which will
cope with such changes, so there is no need to automate such things.
Without git merge, how else are you planning to keep your added no-lock
queue changes intact in the source code?
 
An alternative would be to compile the library as a shared .so with
hidden symbols, except of the one which you will call. I do not like
that approach very much because it requires a platform-specific compiler
option, but it's still better than a whole build step consisting of
platform-specific hacks.
 
When developing software, the aim is to make things simpler after each
alteration, not more complicated. Each time when you add a kludgy hack,
you make the code twice worse. Add 4 such hacks, and you have a program
which is 16 times more difficult to deal with, meaning that you are not
able to maintain it any more.
David Brown <david.brown@hesbynett.no>: Jan 29 11:46AM +0100

On 29/01/2023 00:28, Frederick Virchanza Gotham wrote:
 
> I can't recall if I've ever been given a release executable with the symbols left inside. I don't think I ever have.
 
>> ??????!!!!
>> I'm lost for words.
 
It is certainly one of the most bizarre hacks I have heard of for a while.
 
 
> Let's say that this symbol is used 17 times in busybox, and 63 times
> in openssh. Are you going to do a 'Find & Replace in Files' to change
> all of them? And what about if you see the following in the code:
Yes, going through the source code and making the changes in the right
places is /absolutely/ the thing you have to do. Hacking the generated
object code is insanity and a maintainer's worst nightmare.
 
But a simple search-and-replace is a clumsy way to handle it - you can
use better tools and get better results. A good IDE can figure out
every point in a project that references a particular symbol,
differentiating between local variables, functions, internal and
external linkage. Often it is just a matter of choosing the "refactor -
rename identifier" tool and the job is done.
 
Another good method is to rename the original variable at definition and
declaration. If the code is well-written, with a single declaration in
a single header, then a re-compile will show errors for all the
references. Fix the errors one by one, and you have re-named the
variable (or function, or whatever).
 
 
For a different kind of hack, that is IMHO significantly less bad that
hacking the object code, you could add gcc flags like :
 
-Doptions=BUSY_BOX_options
 
and
 
-Doptions=OPENSSH_options
 
to the different makefile parts. That will lead to a renaming of the
symbols.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 29 07:57AM -0800

Paavo Helde wrote:
> code twice worse. Add 4 such hacks, and you have a
> program which is 16 times more difficult to deal with,
> meaning that you are not able to maintain it any more.
 
David Brown wrote:
> It is certainly one of the most bizarre hacks I have
> heard of for a while.
 
Both of you are speaking from a viewpoint that's been
engendered and indoctrinated in you, rather than just
looking at my solution for what it is. If you consider the
editing of compiled files to be an abomination, then my
solution is an abomination. If you don't have any qualms
about editing object files, then I've given a few reasons
why my solution is superior to editing source files.
 
You have suggested just changing the declaration and
definition and then cleaning up the resultant compiler errors,
but that's work that might introduce bugs. And you've to
re-do it every time the library is upgraded.
 
This all boils down to one simple issue: Can we depend on
'objcopy' and 'patchelf' to do their job properly without
creating unforseen problems? I believe that we can, and so I
depend on them.
 
Let's not make this out to be a simple case of "I think my solution
is better than your solution". This is more of a cultural matter
-- with the binary editors on one side, and the binary intacters
on the other. Cultural clash. Within one lifetime it's unlikely
either of us will defect.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 29 02:44PM -0800

On Sunday, January 29, 2023 at 3:57:43 PM UTC, Frederick Virchanza Gotham wrote:
<snip>
 
Just now I got the 'ssh client' from 'openssh' to compile and link as a static executable, with both 'busybox_route' and 'badvpn_tun2socks' built in. I'm really looking forward to seeing how this turns out.
 
Here's what my final linker command looks like:
 
g++ -o ssh -static -std=c++23 ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o ssh-sk-client.o vpn/vpn-core.cpp.o vpn/vpn-linux-tun.o vpn/from_busybox_route/xconnect.c.o vpn/from_busybox_route/inet_common.c.o vpn/from_busybox_route/route.c.o vpn/from_busybox_route/xfuncs_printf.c.o vpn/from_busybox_route/perror_msg.c.o vpn/from_busybox_route/xfunc_die.c.o vpn/from_busybox_route/ptr_to_globals.c.o vpn/from_busybox_route/signals.c.o vpn/from_busybox_route/verror_msg.c.o vpn/from_busybox_route/read.c.o vpn/from_busybox_route/fflush_stdout_and_exit.c.o vpn/from_busybox_route/time.c.o vpn/from_busybox_route/messages.c.o vpn/from_busybox_route/wfopen.c.o vpn/from_busybox_route/xfuncs.c.o vpn/from_busybox_route/full_write.c.o vpn/from_busybox_route/default_error_retval.c.o vpn/from_busybox_route/xatonum.c.o vpn/from_busybox_route/sysconf.c.o vpn/from_busybox_route/copyfd.c.o vpn/from_busybox_route/bb_strtonum.c.o vpn/from_busybox_route/getopt32.c.o vpn/from_busybox_route/safe_write.c.o vpn/from_busybox_route/safe_strncpy.c.o vpn/from_busybox_route/llist.c.o vpn/from_busybox_route/appletlib_STRIPPED_DOWN.c.o vpn/from_badvpn_tun2socks/SingleStreamReceiver.c.o vpn/from_badvpn_tun2socks/BReactor_badvpn.c.o vpn/from_badvpn_tun2socks/ip6_addr.c.o vpn/from_badvpn_tun2socks/ip4.c.o vpn/from_badvpn_tun2socks/BLog.c.o vpn/from_badvpn_tun2socks/BufferWriter.c.o vpn/from_badvpn_tun2socks/StreamPacketSender.c.o vpn/from_badvpn_tun2socks/PacketPassConnector.c.o vpn/from_badvpn_tun2socks/BTap.c.o vpn/from_badvpn_tun2socks/ip6.c.o vpn/from_badvpn_tun2socks/BNetwork.c.o vpn/from_badvpn_tun2socks/SocksUdpClient.c.o vpn/from_badvpn_tun2socks/tcp_in.c.o vpn/from_badvpn_tun2socks/BTime.c.o vpn/from_badvpn_tun2socks/icmp.c.o vpn/from_badvpn_tun2socks/KeepaliveIO.c.o vpn/from_badvpn_tun2socks/SinglePacketSender.c.o vpn/from_badvpn_tun2socks/UdpGwClient.c.o vpn/from_badvpn_tun2socks/nd6.c.o vpn/from_badvpn_tun2socks/BProcess.c.o vpn/from_badvpn_tun2socks/mem.c.o vpn/from_badvpn_tun2socks/timeouts.c.o vpn/from_badvpn_tun2socks/pbuf.c.o vpn/from_badvpn_tun2socks/udp.c.o vpn/from_badvpn_tun2socks/def.c.o vpn/from_badvpn_tun2socks/ip4_addr.c.o vpn/from_badvpn_tun2socks/BInputProcess.c.o vpn/from_badvpn_tun2socks/icmp6.c.o vpn/from_badvpn_tun2socks/BDatagram_common.c.o vpn/from_badvpn_tun2socks/init.c.o vpn/from_badvpn_tun2socks/inet_chksum.c.o vpn/from_badvpn_tun2socks/PacketRecvBlocker.c.o vpn/from_badvpn_tun2socks/tcp_out.c.o vpn/from_badvpn_tun2socks/sys.c.o vpn/from_badvpn_tun2socks/RouteBuffer.c.o vpn/from_badvpn_tun2socks/PacketPassNotifier.c.o vpn/from_badvpn_tun2socks/BDatagram_unix.c.o vpn/from_badvpn_tun2socks/StreamPassConnector.c.o vpn/from_badvpn_tun2socks/netif.c.o vpn/from_badvpn_tun2socks/PacketPassPriorityQueue.c.o vpn/from_badvpn_tun2socks/BUnixSignal.c.o vpn/from_badvpn_tun2socks/BPending.c.o vpn/from_badvpn_tun2socks/memp.c.o vpn/from_badvpn_tun2socks/StreamRecvInterface.c.o vpn/from_badvpn_tun2socks/ip4_frag.c.o vpn/from_badvpn_tun2socks/PacketPassFairQueue.c.o vpn/from_badvpn_tun2socks/stats.c.o vpn/from_badvpn_tun2socks/BSignal.c.o vpn/from_badvpn_tun2socks/DebugObject.c.o vpn/from_badvpn_tun2socks/PacketProtoDecoder.c.o vpn/from_badvpn_tun2socks/BThreadSignal.c.o vpn/from_badvpn_tun2socks/BConnection_unix.c.o vpn/from_badvpn_tun2socks/PacketRecvConnector.c.o vpn/from_badvpn_tun2socks/PacketRecvInterface.c.o vpn/from_badvpn_tun2socks/ip6_frag.c.o vpn/from_badvpn_tun2socks/SinglePacketBuffer.c.o vpn/from_badvpn_tun2socks/BConnection_common.c.o vpn/from_badvpn_tun2socks/PacketPassFifoQueue.c.o vpn/from_badvpn_tun2socks/PacketPassInactivityMonitor.c.o vpn/from_badvpn_tun2socks/PacketProtoEncoder.c.o vpn/from_badvpn_tun2socks/SingleStreamSender.c.o vpn/from_badvpn_tun2socks/PacketStreamSender.c.o vpn/from_badvpn_tun2socks/PacketProtoFlow.c.o vpn/from_badvpn_tun2socks/ip.c.o vpn/from_badvpn_tun2socks/tcp.c.o vpn/from_badvpn_tun2socks/BSocksClient.c.o vpn/from_badvpn_tun2socks/LineBuffer.c.o vpn/from_badvpn_tun2socks/PacketPassInterface.c.o vpn/from_badvpn_tun2socks/StreamRecvConnector.c.o vpn/from_badvpn_tun2socks/BLog_syslog.c.o vpn/from_badvpn_tun2socks/PacketBuffer.c.o vpn/from_badvpn_tun2socks/PacketCopier.c.o vpn/from_badvpn_tun2socks/PacketRouter.c.o vpn/from_badvpn_tun2socks/StreamPassInterface.c.o vpn/from_badvpn_tun2socks/BLockReactor.c.o -L. -Lopenbsd-compat/ -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -pie -lssh -lopenbsd-compat -lcrypto -lz
Lynn McGuire <lynnmcguire5@gmail.com>: Jan 29 01:48PM -0600

On 1/26/2023 2:12 PM, Lynn McGuire wrote:
 
> and now it compiles.
 
> Sincerely,
> Lynn McGuire
 
I would like to put
 
int gettmp (integer *i, integer a, longint *s, longint temp [2][100],
integer *fin);
 
But apparently that is illegal in C++.
 
Thanks,
Lynn
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 29 08:30PM


> On 1/26/2023 2:12 PM, Lynn McGuire wrote:
>> On 1/25/2023 10:04 PM, Ben Bacarisse wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
<edited quotes>
 
> I would like to put
 
> int gettmp (integer *i, integer a, longint *s, longint temp [2][100], integer *fin);
 
> But apparently that is illegal in C++.
 
I don't think so, but it might not mean what you think it means. The
"first" dimension is simply ignored. longint temp[2][100] is (in a
parameter position) the same as your previous solution.
 
Can you post code that shows what the problem is?
 
But I am curious as to why you want to write that 2 in there. Do you
want to write just to help the reader? If so, no problem, but if you
want to pass the 2 so the function can, for example, know the size of
the array, they you are going to have to use a different type -- the
simplest being to pass a reference to the whole array:
 
int gettmp(..., longint (&temp)[2][100], ...);
 
I think it's worth pointing out (since I think this is from your Fortran
to C++ tool) that if the array dimensions might not always be
compile-time constants you will have to start using more sophisticated
C++ types. And if that is going to happen eventually, you would be
better off starting now.
 
--
Ben.
Pluted Pup <plutedpup@outlook.com>: Jan 28 07:28PM -0800

On Tue, 24 Jan 2023 05:20:19 -0800, David Brown wrote:
 
 
> If I attempt to follow-up the message in Thunderbird, the Thunderbird
> client sets the newsgroup to "rec.arts.books", the subject to "Re:
> Compute Unique Numbers in a Set" (i.e., from the pre-downloaded headers,
 
Here's your mistake:
 
> wrote:". The body of the quotation is the rambling essay. This is
> entirely consistent with Bonita's post - she replied to what she
> believed to be a message from Muttley.
 
Bonita hasn't replied in this thread, only what others
have said that she must have saw.
 
If I were to "quote" a message by "you" as:
 
On Tue, 30 Jan 2023 05:20:19 -0800 David Brown wrote:
> I am the easter bunny!
 
would that be proof that there was a server glitch
or would it more likely be me posting a "glitch"?
 
 
> It is quite clear that there has been a glitch on the
 
Likely there was no glitch, but possible.
 
Pluted Pup <plutedpup@outlook.com>: Jan 28 07:54PM -0800

On Tue, 24 Jan 2023 11:46:54 -0800, David Brown wrote:
 
> link, then I can happily email the screenshot. But it seems a quick and
> easy way to make a link to the screenshot.
 
> <https://paste.pics/b4149f38abb4e210da0a71886714d014>
 
That screen makes no sense and I would guess it to be a
Thunderbird problem. Thunderbird on mac has been broken
for me for many months and have quit trying to make it work.
A client problem, not a server problem.
 
So Thunderbird is broken or semi-broken depending on
Mac (broken), Windows (semi-broken), or Linux (somewhat
broken).
 
If Mozilla (Thunderbird) doesn't want to support newsgroups
anymore, they should stop pretending to. This is me jumping
to conclusions.
Pluted Pup <plutedpup@outlook.com>: Jan 28 08:20PM -0800

On Thu, 26 Jan 2023 00:44:32 -0800, David Brown wrote:
 
> up messages all over the place and draw all sorts of conclusions about
> people, articles, and servers - and yet none of them seems willing to
> take a look at the server that had the glitch?
 
That requires setting up an account. That didn't seem to
be necessary as the way you described the problem made it
seem like it was not a server problem.
 
> you "net-abuse" lot to do it (since you don't trust or believe /me/).
 
> If you don't want to do that, fair enough. But please stop asking how
> to verify my claims and then ignoring the answer.
 
You mis-explained in a way to lead others to misunderstand the
problem. The problem of Bonita's post and the second problem
of the server error, which apparently was coincidental. I'm sorry
to misunderstand about the server problem.
David Brown <david.brown@hesbynett.no>: Jan 29 12:00PM +0100

On 29/01/2023 05:20, Pluted Pup wrote:
 
> That requires setting up an account. That didn't seem to
> be necessary as the way you described the problem made it
> seem like it was not a server problem.
 
What? What part of "this is clearly a server glitch", "it is only
visible with news.eternal-september.org", and pretty much everything
else I wrote, could be interpreted as "not a server problem" ?
 
To be fair, the news.admin.net-abuse.usenet followers might not have
read from the start of the thread as seen on comp.lang.c++, and thus
missed some of the earlier posts. But everything I have written since
the cross-posting has been clearly about a server glitch and desperately
trying to persuade the Usenet experts to look for themselves on
news.eternal-september.org so that they can see the difference. Those
who /have/ now looked have been in no doubt - it was a server glitch.
 
I do appreciate that setting up an account on that server is an
inconvenience and effort, and people could have a wide range of good
reasons for not wanting to do that. I do not expect any particular
person to make an account and check it. All I expect is that people who
choose not to go to the source and look at the primary evidence, should
not profess an "expert opinion" on the matter.
 
> problem. The problem of Bonita's post and the second problem
> of the server error, which apparently was coincidental. I'm sorry
> to misunderstand about the server problem.
 
There were not two coincidental problems - there was /one/ problem. A
server glitch.
 
Bonita made a post in poor style - quoting an entire long message with a
single top-posted comment. Usenet is swamped with people who do that -
it is not some rare or unusual "problem", and if people complained to
admins about "abuse" for such posts, admins would see nothing else. You
can be sure that none of the regulars in comp.lang.c++ would bother
about it.
David Brown <david.brown@hesbynett.no>: Jan 29 12:04PM +0100

On 29/01/2023 04:54, Pluted Pup wrote:
> Thunderbird problem. Thunderbird on mac has been broken
> for me for many months and have quit trying to make it work.
> A client problem, not a server problem.
 
It's a screenshot from Pan, not Thunderbird. (You realise this is
Usenet, don't you? It is not personal email - you are allowed to read
replies I have made to other people. Indeed, it's a good idea, and
saves repetition.)
 
It makes no sense because it shows a /server/ problem - the /server/
returned nonsense for that post.
 
 
> If Mozilla (Thunderbird) doesn't want to support newsgroups
> anymore, they should stop pretending to. This is me jumping
> to conclusions.
 
I've found Thunderbird to work fine on Linux (I also use it on Windows,
but not for Usenet). It's not perfect, but I've found few programs that
/are/ perfect. And it shows the same glitch here as Pan does, because
it is a /server/ glitch, not a client issue.
David Brown <david.brown@hesbynett.no>: Jan 29 12:36PM +0100

On 29/01/2023 04:28, Pluted Pup wrote:
>> I am the easter bunny!
 
> would that be proof that there was a server glitch
> or would it more likely be me posting a "glitch"?
 
It would be proof that you haven't bothered looking at the information I
have given in countless posts here.
 
Again - if you don't want to look at the information, or read the posts,
that's okay. But then you are not qualified to give an opinion on the
issue. Please do not join in the thread unless you have something
useful to say.
 
I must say I am, on the whole, very disappointed about the quality of
the so-called "experts" in news.admin.net-abuse.usenet. There have been
some that have been helpful, and at least one who has realised he was
wrong and had jumped to unwarranted conclusions (and I am grateful and
impressed by that admission).
 
But for the most part, the posters from that group come across as
arrogant, dismissive, judgemental and patronising. It is clear that
they want to help people, which is obviously good - but it is all based
on their pre-conceived assumptions about the issue. Again and again I
am told it is a troll post, a client issue, a user issue. Again and
again I present evidence showing it is a server glitch, only to have the
evidence ignored. I and an n.a.n-a.u poster refer to the posting of the
news.eternal-september.org admin who says there was a server glitch, and
that gets ignored. I post a screenshot, as asked, and it barely gets a
glance before being condemned as a client issue (for the wrong program).
Several posters from n.a.n-a.u show that they have not bothered to
read any of the the descriptions I have given, or the posts made by
their colleagues - and barely any have made the effort to actually look
at the server that had the problem. And yet they are supremely
confident in their judgement and assessment of the issue, with not an
ounce of humility.
 
Have you any idea how frustrating this is from my point of view? I feel
I am being accused of lying, or inventing things, or of being unable to
admit that I have been "trolled". The information I give is dismissed
without consideration. The "experts" can't possibly be wrong - I am
just an amateur that is mistaken and misunderstanding things.
 
 
You are late to the party here. It has already been established that it
is a server glitch (something I - the amateur - figured out within a day
of it occurring). At least one expert from n.a.n-a.u has checked the
bad server, duplicated the issue, and seen that it was a server glitch.
 
I am hoping this will be a wake-up call to the n.a.n-a.u posters who
have been jumping to conclusions from their ivory towers. Sometimes you
are wrong.
 
 
I apologise to those in n.a.n-a.u who feel this characterisation is
wrong. I don't know the group, and cannot judge it - and I certainly
cannot judge individuals. What I am doing here is giving feedback on my
impression from this thread. I assume that the impression I got is not
the way you want to appear, and does not give a fair picture of a group
of people who are genuinely trying to help others with their problems.
But it /is/ the impression I got here. And I'd rather tell you that
honestly, because I believe it will be helpful to you.
 
 
 
>> It is quite clear that there has been a glitch on the
 
> Likely there was no glitch, but possible.
 
I hope you'll now read some of the other posts.
gazelle@shell.xmission.com (Kenny McCormack): Jan 29 12:01PM

In article <tr5jjk$2npbg$3@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>person to make an account and check it. All I expect is that people who
>choose not to go to the source and look at the primary evidence, should
>not profess an "expert opinion" on the matter.
 
But that's what these newsgroups are all about. Not letting not knowing
anything stop you from giving advice.
 
Just look at all the nonsense you (and that other poster) have spewed in
that other thread - the one about modifying object modules using
established working tools. You guys (both of you) need to look up what
"IMHO" means - and start liberally using it in your posts.
 
--
People often ask what is the difference between liberals and conservatives.
It is this. Libs see the government helping them and are OK with the government
also helping other people. Cons see the government screwing them and are OK with
that as long as the government is also screwing other people.
"Adam H. Kerman" <ahk@chinet.com>: Jan 29 05:23PM

>that's okay. But then you are not qualified to give an opinion on the
>issue. Please do not join in the thread unless you have something
>useful to say. . . .
 
Oh for god's sake. Surely you must have noticed by now that "Pluted Pup"
is just a sockpuppet who has been trolling you. Would you PLEASE spit
out the damn hook already and stop troll feeding?
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:

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:
Subscribe to: Posts (Atom)