Monday, July 3, 2023

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

"R.Wieser" <address@is.invalid>: Jul 03 09:12AM +0200

Christian,
 
> You should read the answer, not the question.
 
Can you tell me what the first line of that answer was ? Was it something
like
 
[quote]
The filter function, called before initscr, tells curses to use a single
line (rather than the whole screen).
[/quote]
 
?
 
Yeah, no. I have been quite clear I can't use cooked input, and it still
messes with the screen.
 
Luckily Pavel was a bit more forthcoming than you, and made it clear that
there was a bit of a trick involved. Which ofcourse was not mentioned
there.
 
But if it actually does grab a screenline (and displays any output and/or
restores that screenline after exiting the call) while allowing me to grab
keystrokes (does the callback have a "ignore this keystroke" return value ?
I have not looked yet) than I again can't use it.
 
Bottom line : Yes, I ready that answer. To me it looks that you didn't.
Or perhaps just ignored the "side effects" of that method, because they do
not matter to you.
 
If I'm wrong and that method actually doesn't mess with the screen *at all*
than you're welcome to point out how thats been done.
 
Regards,
Rudy Wieser
"R.Wieser" <address@is.invalid>: Jul 03 10:59AM +0200

James,
 
> "comp.os.linux.answers" appears to be a fairly active linux oriented
> group
 
Thank you for that suggestion. Alas, ethernal september (my newsgroup host)
doesn't seem to carry it. :-\
 
> I would still suggest that <https://www.linux.org/forums/>
 
Thank you again for that suggestion. Alas, I'm quite reluctant to sign up
to anything just to get a single answer.
 
Also, when I try to have a peek at what they are offering I 1) get an
"insecure connection". When I than bypass the certificate problem I 2) end
up on a cloudflare server which returns a "403 Forbidden". It also
doesn't help that 3) it demands JS to be enabled, which I keep disabled.
 
> As I indicated, I have been using almost exclusively Linux for 30 years
> now. I also don't know how to solve your problem to your satisfaction.
 
*Thank you* for saying that. It means that I can stop trying to search
for it (and just use whatever I already came up with myself).
 
>> Actually, someone has already proven you wrong in that regard.
 
> Oh - who? The only response you've received that you haven't denigrated
> yet was the one suggesting that you use readline(),
 
I rejected it the first time, as I have no use for cooked input. It was
Pavel who clarified it and showed that I could possibly use its callback to
get what I wanted.
 
... though a more recent post seems to indicate that that call still grabs
part of the the screen, which again/still makes it (way) less usable to me.
 
As for "denigrated" ? Think (read) again. I'm not known for just saying
"no" to something, I tend to describe why there is a mismatch between the
offered solution and what I am after. If you can't handle a "thats not
quite it and {this} is the reason why" than thats your problem, not mine.
 
> I very clearly distinguished Unix and Linux in the part of my message
> that you chose to snip - how could you derive from that the conclusion
> that I was confusing them?
 
By trying to push my Linux related question into a Unix related newsgroup.
Are you daft or something ? Or just suffering from dementia ?
 
> No, I think you'll get answers of varying quality,
 
Which is another "water is wet" kind of thing. Skipped.
 
> That's less likely to be the case in a newsgroup devoted to Linux.
 
I recently asked a RPi platform-specific hardware and Linux OS specific
question in an RPi specific newsgroup. For some reason people there where,
for whatever reason, coming up with all kinds of Non-RPi references. You
where saying ?
 
IOW, that pendulum swings both ways.
 
But granted, there is a distinct possibility, and I'm open to suggestions.
Just not bogus ones. :-(
 
>> level of linux expertise here is 100%.
 
> That seems incredibly unlikely to me. I've seen the levels of Linux
> expertise displayed both here and in comp.UNIX.programmer
 
:-) Thats the problem with grabbing the correct interpretation of what
you're reading. As I tried to explain as reponse to your "less than a 100%"
and "minimum is 0" blurbs.
 
Knowledge-wise you /cannot/ go under zero, just as your "significantly less
than 100%" /cannot/ be anything than being less than that 100% (besides what
"significantly" might actually be).
 
IOW, just like your "minimum is 0" blurb, the maximum is 100%. And water is
wet. But while the minimum might actually be reached by just having a
single nincompoop in the group, I grant you that the opposite will be much
harder to reach - even for just a single person.
 
Regards,
Rudy Wieser.
"R.Wieser" <address@is.invalid>: Jul 03 10:12AM +0200

Keith,
 
>> Ah yes, about that : Are you aware that Linux != Unix ?
...
> Yes, I'm aware.
 
Than why did you try to push me to that newsgroup. It makes zero sense.
 
> At least the first part of your original question was
> not specific to Linux.
 
You mean the part above the "second question" ? If so, what *didn't* you
understand about
 
[quote=me, initial message]
I was wondering if this perhaps is already part of Linux ...
[/quote]
 
?
 
Also, thruout the thread there are multiple mentionings of Linux specific
usage, some of which I acknowledged to having found them myself. If
nothing than that should have given you a clue to what OS I was working on.
 
You complain abut me not reading everything and thus missing stuff ? I
suggest you take a long, hard look in the mirror.
 
> You mentioned the "console", apparently referring to the Linux virtual
> console
 
I have no idea, as my "/please/ tell me the difference between them"
requests have never been answered. Which, by the way, feels to me like
nobody here actually knows the distinction themselves.
 
... and you have now introduced yet another phrase to that list, bringing it
up to ... six?
 
But looking at the "virtual" part of it, isn't that not something that can
only be true when you use a GUI ? In that case I think you might also have
missed my mentioning (in my second post) of "my "bullseye lite"
installation".
 
... Which also should have been a clue-by-four that I was indeed using
Linux.
 
> I'm not the only person who has suggested that comp.unix.programmer
> would be a better place for your question.
 
True. You're one of exactly two who said that. And that makes it better
... how exactly ? How many people are there in this newsgroup ?
 
Besides ofcourse that you tried to dump me into a non-Linux newsgroup. :-(
 
> Apparently you'd rather stay here and argue with people who are
> trying to help you.
 
The people who wanted to help me already did. You and james are just
keeping on claiming I should not be here. Other than some "because I say
so" I have not gotten any clarification of that.
 
> I was suggesting that you read Thomas Dickey's *answer*.
 
I refer you to my reply to 'Christian', just before my reply to you.
 
> Don't expect any more help from me.
 
Like you trying to set me up to fail by suggesting I (re)post in a Unix
related group ? Yeah, I surely could do without such shennigans.
 
But, thank you for your (initial) attempts to come up with something
workable. Alas, as I've mentioned, something with a "side" effect of
touching the screen is unusable to me.
 
Regards,
Rudy Wieser
David Brown <david.brown@hesbynett.no>: Jul 03 11:38AM +0200

On 01/07/2023 10:30, R.Wieser wrote:
 
> But thank you for the warning.
 
> And for the record, if I would have had that other newsgroup in my shortlist
> I would have posted there.
 
It's also important to note that /using/ Linux is not the same as
/programming/ for Linux. (For example, most of /my/ C++ programming is
done /on/ Linux, but not /for/ Linux.) And the great majority of people
who write code for Linux would have no need for such raw keyboard
handling. And if a library for handling all your needs is available, it
will almost certainly be in C, not C++.
 
All in all, your only real hope in posting here would be from one of the
old regulars who have been coding for *nix systems since the beginning
of time. And you seem to have insulted or annoyed most of them.
 
If your original post had been asking how to turn a horrible huge C
switch into something more elegant and maintainable in C++, you'd be in
the right place here.
 
I don't know of any newsgroups where you would be able to get the help
you want. It would have to be somewhere that covered such terminal
access that is probably common to all POSIX systems, but the group could
not mention UNIX, BSD or anything other than Linux because you believe
them to be completely different. The members should be happy to help a
poster despite sarcasm and insults. They should accept a total
disregard for conventions and group standards. The existing members of
the group should be proud to search the web and group archives for you,
so that you would not be exposed to any unpleasant adverts or posts.
No, sorry, I don't know of any such Usenet groups or other forums.
"R.Wieser" <address@is.invalid>: Jul 03 01:04PM +0200

David,
 
> All in all, your only real hope in posting here would be from one of the
> old regulars who have been coding for *nix systems since the beginning of
> time.
 
And the reason you think that a library written for Unix (or a very old
version of Linux) will be usable under a nowerdays version of Linux is ... ?
 
> And you seem to have insulted or annoyed most of them.
 
I think they are thankfull that I have not dumped a question in their
newsgroup that has absolutily zero to do with the OS their newsgroup is for.
 
> If your original post had been asking how to turn a horrible huge C switch
> into something more elegant and maintainable in C++, you'd be in the right
> place here.
 
Too bad that that wasn't a question I wanted to ask.
 
> I don't know of any newsgroups where you would be able to get the help you
> want.
 
Shucks. And the question was such an easy one ! Does something like it
already exist in Linux, and if so where can I find it. I shrudder about
what the result would be for a really complex question ...
 
> It would have to be somewhere that covered such terminal access
 
You misread. I did not ask about terminal access. I asked if the parsing of
such input would possibly already exist. Nothing more.
 
> The members should be happy to help a poster despite sarcasm and insults.
 
That some people here have not been able to comprehend my, rather simple,
question is one thing.
 
However, if they than start to demand that I take their resulting crap as
the answer and refuse to accept my explanation to why it isn't and than keep
pressing it nonetheless than they deserve my ire.
 
Try thinking of our situation in reverse : how long would it take for you to
be fed up with such behaviour ? My guess is, not much longer than it took
me.
 
Than again, most people would than just stop responding. I've not quite
gotten the hang of that yet. :-\
 
Regards,
Rudy Wieser
David Brown <david.brown@hesbynett.no>: Jul 03 03:11PM +0200

On 03/07/2023 13:04, R.Wieser wrote:
 
> Than again, most people would than just stop responding. I've not quite
> gotten the hang of that yet. :-\
 
Try harder. We are all cheering for you.
scott@slp53.sl.home (Scott Lurndal): Jul 03 01:28PM

>...
>> Yes, I'm aware.
 
>Than why did you try to push me to that newsgroup. It makes zero sense.
 
It makes total sense to everyone but you, which is your problem, not ours.
scott@slp53.sl.home (Scott Lurndal): Jul 03 01:34PM

>> group
 
>Thank you for that suggestion. Alas, ethernal september (my newsgroup host)
>doesn't seem to carry it. :-\
 
 
Ah, so sad. You must be aware that Google Groups does provide
an interface that would allow you to participate in that usenet
newsgroup.
 
It's sad that you don't seem to be able to find the information
yourself, which prior to the internet, was the standard way to learn
something. Go to the library and read a book. Go to the community
college and take a class. Read publically shared code written by others
to get ideas.
 
But continuing your current pointless arguments with the long-time denizens
of this C++ language group expecting them to write your program for you
is the definition of insanity.
Muttley@dastardlyhq.com: Jul 03 03:41PM

On Sun, 2 Jul 2023 11:03:42 +0200
 
>> You could post a single message on this thread saying that
>> you're going to continue the discussion in comp.unix.programmer.
 
>Ah yes, about that : Are you aware that Linux != Unix ? I might well be
 
The distinction vanished long ago from a programming POV. The vast majority
of unix development these days is done on Linux. I've posted linux specific
questions on that group and no one complained.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 03 12:20PM -0400

On 7/3/23 04:59, R.Wieser wrote:
>> group
 
> Thank you for that suggestion. Alas, ethernal september (my newsgroup host)
> doesn't seem to carry it. :-\
 
I should have checked that before posting, but it supports many other
members of the comp.os.linux hierarchy. If nothing else,
comp.os.linux.misc should, by definition, cover it.
 
..
>> that I was confusing them?
 
> By trying to push my Linux related question into a Unix related newsgroup.
> Are you daft or something ? Or just suffering from dementia ?
 
What is Linux-specific about your question - other than the fact that
you have specified that you want a linux solution? How would a Unix
solution that was, therefore, also a linux soluction, be either
impossible or not useful to you?
 
> question in an RPi specific newsgroup. For some reason people there where,
> for whatever reason, coming up with all kinds of Non-RPi references. You
> where saying ?
 
I said "less likely" - I didn't say "impossible".
 
 
> Knowledge-wise you /cannot/ go under zero, just as your "significantly less
> than 100%" /cannot/ be anything than being less than that 100% (besides what
> "significantly" might actually be).
 
I have no idea why you think those comments are relevant to my
statements. Nothing I said was so vacuous as to be equivalent to
pointing out that those are the lower and upper limits.
 
To make it concrete, if we were to imagine that it was possible to
objectively rate Linux expertise on a simple linear scale from 0 to 100,
then my experience is that a large fraction of those posting to
comp.lang.c++ have a rating less than 1, while those that do have a
higher rating have an average rating around 50. In contrast, very few of
the people posting to comp.unix.programmer have a rating less than 1,
and those that do have a higher rating have an average rating around 80.
I freely acknowledge that you have no obligation to believe me about
that. I certainly don't have any hard numbers, just subjective
assessments. However, if my assessments were correct, why would you want
to post a Linux-related question to comp.lang.c++ in preference to
comp.unix.programmer?
James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 03 12:43PM -0400

On 7/3/23 04:12, R.Wieser wrote:
> ...
>> Yes, I'm aware.
 
> Than why did you try to push me to that newsgroup. It makes zero sense.
 
Because Linux tends to comply with the requirements of the POSIX
standard. As long as what you're talking about doesn't involve any
linux-specific features (I might have missed something, but this issue
doesn't seem to involve any such features), it's at least as good a
place to go as a Linux-specific forum, and possibly better, because the
answer might be portable to other POSIX-conformant platforms.
 
...
> I was wondering if this perhaps is already part of Linux ...
> [/quote]
 
> ?
 
Sorry, I made the mistake of assuming that you would be interested in a
POSIX solution that worked on Linux, even if that solution doesn't
involve any features specific to linux.
 
>> would be a better place for your question.
 
> True. You're one of exactly two who said that. And that makes it better
> ... how exactly ? How many people are there in this newsgroup ?
 
Because there's lots of Unix experts in that newsgroup, most of whom are
also Linux experts, who might be able to find a Unix solution to your
problem that works under Linux.
 
...
>> I was suggesting that you read Thomas Dickey's *answer*.
 
> I refer you to my reply to 'Christian', just before my reply to you.
 
 
You mean the answer that said "If you're clever, you can turn off echo,
and (since filter suppresses the screen erasure), pretend that it
updates nothing at all."?
Richard Harnden <richard.nospam@gmail.com>: Jul 03 06:02PM +0100

On 03/07/2023 17:20, James Kuyper wrote:
 
> assessments. However, if my assessments were correct, why would you want
> to post a Linux-related question to comp.lang.c++ in preference to
> comp.unix.programmer?
 
Normally you (or Keith, or anyone) would write a summary-so-far, x-post
to c.u.p and set f/ups.
 
Why not this time? Because Rudy is rude and/or too stubborn?
 
He doesn't have a question about c++, he has a question about posix -
and c.u.p is exactly where he should be asking.
Christian Gollwitzer <auriocus@gmx.de>: Jul 03 08:35PM +0200

Am 03.07.23 um 13:04 schrieb R.Wieser:
>> time.
 
> And the reason you think that a library written for Unix (or a very old
> version of Linux) will be usable under a nowerdays version of Linux is ... ?
 
At this point, I believe you must be trolling.
 
Christian
gazelle@shell.xmission.com (Kenny McCormack): Jul 03 07:16PM

In article <u7v4de$3ov02$1@dont-email.me>,
 
>> And the reason you think that a library written for Unix (or a very old
>> version of Linux) will be usable under a nowerdays version of Linux is ... ?
 
>At this point, I believe you must be trolling.
 
Not so much trolling, per se, but on a quixotic hope that people (the kind
of people who inhabit CLC and CLC++) will change, evolve and grow.
 
It won't happen, but one can always hope.
 
--
People who want to share their religious views with you
almost never want you to share yours with them. -- Dave Barry
"R.Wieser" <address@is.invalid>: Jul 03 10:55PM +0200

Christian,
 
> At this point, I believe you must be trolling.
 
As I must believe that (some of) you guys are doing, as not understanding a
simple
question for so long takes a lot of effort.
 
Regards,
Rudy Wieser
"R.Wieser" <address@is.invalid>: Jul 03 10:50PM +0200

James,
 
>> Thank you for that suggestion. Alas, ethernal september (my newsgroup
>> host) doesn't seem to carry it. :-\
 
> I should have checked that before posting,
 
I disagree. Its not your task to be aware of everyones newsgroup providers
and different newsgroups those offer.
 
> but it supports many other members of the comp.os.linux hierarchy.
 
Ah. That gives a much shorter list. Thanks.
 
> If nothing else, comp.os.linux.misc should, by definition, cover it.
 
And it seems to be active too. :-)
 
> What is Linux-specific about your question other than the fact that
> you have specified that you want a linux solution?
 
Because I'm running Linux, and have no use for a support thats available
under Unix, but not Linux.
 
> I have no idea why you think those comments are relevant to my
> statements. Nothing I said was so vacuous as to be equivalent to
> pointing out that those are the lower and upper limits.
 
Thats the whole thing : you made it sound as if those two numbers where
somehow of any importance, but in fact all they are the limits of the range.
You cannot come up with a number above 100% or below the 0. Therefore
naming them as you did had zero meaning to me. Yet, you did.
 
> then my experience is that a large fraction of those posting to
> comp.lang.c++ have a rating less than 1, while those that do have a
> higher rating have an average rating around 50.
 
Wow. I'm going to assume you think that you are one of the 50 percenters,
here and as such you cannot really stand this newsgroup - because of all the
nitwits ... ehhh ... 1 percenters in it.
 
> a rating less than 1, and those that do have a higher rating have an
> average
> rating around 80.
 
Sounds good.
 
> I freely acknowledge that you have no obligation to believe me about
> that.
 
I think you think you are saying the truth and that its relevant.
 
I however have my doubts that what you measured (software knowledge) was
relevent to my question (availablility of something in Linux).
 
As my teacher said it "Measuring is knowing - if you know what you are
measuring".
 
> However, if my assessments were correct, why would you want
> to post a Linux-related question to comp.lang.c++ in preference to
> comp.unix.programmer?
 
Absolutily.
 
But as said, even though I do not doubt your assessment, I do doubt its
releveance.
 
Regards,
Rudy Wieser
"R.Wieser" <address@is.invalid>: Jul 03 09:32PM +0200

Muttly,
 
> I've posted linux specific questions on that group and no
> one complained.
 
Thanks for that.
 
Though mine is not a programing question, but /an availability/ of something
in Linux. There, AFAICT, the the distinction matters.
 
To me it feels like asking a Fort dealer about something thats going to be
used in an Audi.
 
Regards,
Rudy Wieser
gazelle@shell.xmission.com (Kenny McCormack): Jul 03 09:06PM


>Thanks for that.
 
>Though mine is not a programing question, but /an availability/ of something
>in Linux. There, AFAICT, the the distinction matters.
 
I've been following this thread since the beginning - I've read all the
posts, and already commented once or twice. I've also often wished for an
off-the-shell solution to this problem - the closest does indeed seem to be
ncurses - but that's less than optimal for all the reasons that we've all
seen listed here.
 
That all said, this is really what I'd call a "software" problem. I.e.,
if I were laying out a newsgroup hierarchy, the ideal group for this
question would be something like: comp.linux.software (or maybe comp.unix.software)
(I have no idea if a group of that name already exists).
 
The idea is that you want to know if software already exists to do what you
want. Note, BTW, that many of us have in fact already implemented some
homespun version of this (at least, you, me, and one other poster here),
and the thing we all have in common is a feeling of annoyance at having had
to do so. There really *should* be an off-the-shell solution.
 
BTW, doing it in full generality is nowhere near as easy or straightforward
as some here have been making it out to be. I may, in a future post, share
some details of my solution - you'll be amazed at how many special cases
there are.
 
--
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.
 
H. L. Mencken
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jul 03 03:42AM -0700

I'm writing a network analysis program, and just today I've found out that it's too slow and missing packets.
 
Ideally, I want the thread that reads from the network card to have exclusive use of one of the CPU cores.
 
I'm looking at the following two functions:
sched_setaffinity
pthread_setaffinity_np
 
And I note the following in the Linux manual:
"For example, by dedicating one CPU to a particular process (i.e., setting the affinity mask of that process to specify a single CPU, and setting the affinity mask of all other processes to exclude that CPU), it is possible to ensure maximum execution speed for that process"
 
I can find lots and lots of code examples to set the affinity for one thread or for one process -- however I cannot find one code example showing me how to exclude all other threads.
 
There's absolutely no point in me restricting my thread to the 1st CPU core if other threads can run on that core too -- in fact that will make my program _slower_ because my thread can't be scheduled on the other cores. Every code sample I can find online seems to just restrict the thread in question without placing any restriction on other threads.
 
Anyone know how this is supposed to work?
David Brown <david.brown@hesbynett.no>: Jul 03 03:09PM +0200

On 03/07/2023 12:42, Frederick Virchanza Gotham wrote:
 
> I can find lots and lots of code examples to set the affinity for one thread or for one process -- however I cannot find one code example showing me how to exclude all other threads.
 
> There's absolutely no point in me restricting my thread to the 1st CPU core if other threads can run on that core too -- in fact that will make my program _slower_ because my thread can't be scheduled on the other cores. Every code sample I can find online seems to just restrict the thread in question without placing any restriction on other threads.
 
> Anyone know how this is supposed to work?
 
"cpu isolation" is, I believe, the term you want to look for on Google.
I don't know if this can only be set from boot parameters or configured
at run-time. You could also search for real-time linux, as that is
where these features are often used.
 
You will probably also want to disable some or all power-down modes and
clock speed switching, as these can give significant variations in
latencies. And you may need to pin the network card interrupts to a
processor core too.
scott@slp53.sl.home (Scott Lurndal): Jul 03 01:38PM


>I'm looking at the following two functions:
> sched_setaffinity
> pthread_setaffinity_np
 
This is A C++ group. A simple google search should be more productive,
and the answer will be dependent upon which operating system you are
targetting.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 03 11:48AM -0700

On 7/3/2023 3:42 AM, Frederick Virchanza Gotham wrote:
 
> And I note the following in the Linux manual:
> "For example, by dedicating one CPU to a particular process (i.e., setting the affinity mask of that process to specify a single CPU, and setting the affinity mask of all other processes to exclude that CPU), it is possible to ensure maximum execution speed for that process"
 
> I can find lots and lots of code examples to set the affinity for one thread or for one process -- however I cannot find one code example showing me how to exclude all other threads.
 
Not sure you can do that. The OS can do whatever it wants. It can pin
your thread to a CPU, but that does not mean it cannot use said CPU for
other programs threads...
 
 
Jivanmukta <jivanmukta@poczta.onet.pl>: Jul 03 06:51PM +0200

W dniu 2.07.2023 o 09:11, Paavo Helde pisze:
 
> You are hitting the file descriptor limit in a single process.
 
> As your function is recursive, the most obvious suspect is infinite
> recursion.
 
I solved the problem by adding
&& (except_subdir_path_no_prefix == L"" ||
str2wstr(iter->path().string()).find(except_subdir_path_no_prefix) ==
wstring::npos)
to the IF is_regular_file and by using fs::recursive_directory_iterator.
There was no infinite recursion but tested direcotries structure was
very large.
 
wstrvector get_filepaths(fs::path path, string extensions, wstring
except_subdir_path, wstring prefix_dir) {
if (path.string().find("vendor") != string::npos &&
except_subdir_path.find(L"kohana-multi-site") != string::npos) {
path = path;
}
wstring except_subdir_path_no_prefix = except_subdir_path;
if (starts_with(except_subdir_path, prefix_dir)) {
except_subdir_path_no_prefix =
except_subdir_path.substr(prefix_dir.length());
}
string p = path.string();
p = wstr2str(normalize_path(str2wstr(p), wstr2str(dir_separator)[0]));
path = fs::path(p);
wstrvector filepaths;
if (exists(p)) {
/*
if (ends_with(p, wstr2str(dir_separator + L".")) ||
ends_with(p, wstr2str(dir_separator + L"." + dir_separator))) {
*/
const fs::directory_iterator end {};
for (fs::directory_iterator iter {path}; iter != end; ++iter) {
string e = iter->path().extension().string();
if (safe_substr(e, 0, 1) == ".") {
e = safe_substr(e, 1);
}
if (is_regular_file(iter->path()) && (extensions == "" ||
index_of_string(explode(",", extensions), e) >= 0)) {
filepaths.push_back(str2wstr(iter->path().string()));
} else if (is_directory(iter->path()) &&
(except_subdir_path_no_prefix == L"" ||
str2wstr(iter->path().string()).find(except_subdir_path_no_prefix) ==
wstring::npos)) {
wstrvector subfiles = get_filepaths(iter->path(),
extensions, except_subdir_path, prefix_dir); // recursion
filepaths.insert(filepaths.end(), subfiles.begin(),
subfiles.end());
}
}
}
return filepaths;
}
wij <wyniijj5@gmail.com>: Jul 03 09:32AM -0700

The following is the updated guideline (file ClassGuideLines.txt), posted for
review. Subtleness is there, don't be fooled by simplicity.
 
----- ClassGuideLines.txt
 
This file updates the class guideline in Rationale.txt
The guideline focuses on the OO way of class (concept) design, and is made to
ensure that the class (concept) design is provably consistent.
 
+----------------------------------------------------------+
| Sequence of acquisition incident: Object life cycle view |
+----------------------------------------------------------+
1. Name binding
(there might be anonymous object)
2. Size binding
Information to allocate memory
3. Address binding
Object in this stage is called in random state.
4. Semantics binding
Object is in responsible state of the occupied space and contents.
(external resource may be associated in the semantics)
5. Reversal is the object destruct process

Note: Class of objects whose destructor can be runtime ignored is referred
to as discardable in this library. Often, such class has no user
defined destructor and such objects can be overwritten.

----Result of the life cycle view is the basic rule of class members
 
Constructor(..):
Constructor forms are in basic the Cartesian product view of problem domain
in tupple. IOW, the class (concept) is defined by the arguments of ctor.
Constructor brings an object in random state to responsible state.
 
Destructor:
The destructed object is no longer considered existing in the C++ language
(ref. [12.4.14]). Since destructing an object the second time results to
undefined behavior, destructor must make sure destructing it once is enough.
In another word, destructor must succeed to the language. Object destruction
actually magnifies the effect of common ignorance of the implicitly created
rollback function (or a design).... The program execution from return/throw/
exit.. to its caller(e.g. main, init..) shall succeed.
 
Note: C++ language had enforced the semantics that 'destructor must succeed'.
 
const member functions:
Const members define the property of the class. Normally, these 'property'
members should be in O(1) complexity. If properties of two objects are equal,
the objects should behave the same.
These members provide the basic proofs that the class is properly designed.
 
Reset(..) members:
Reset members brings the object from responsible state back to random state
and then does whatever the argument corresponding constructor does.
Therefore, If a reset member exists then the argument(s) corresponding
constructor also exists.

Construct/destruct/reset are implemented as composite operations of object
initialization process of the life cycle view (and the symmetrical reverse).
Implementation can optimize the theoretical sequence.
 
Since this library adopts an implicit rule that object has to be in a 'valid'
state (no good in class like Array), the reset() postcondition is thus
required to be default. Default state is among the easiest check points to
ensure object constructed, in whatever valid state, can always be
successfully destructed. Note that reset members normally exist but not
necessary. For instance, if the class contains const or reference data
members, then the reset would be difficult to implement.
 
Move Constructor:
The motivation of devising is from the need to avoid costly and unnecessary
copy operations found in classes that contain allocated resources and the
objects movement in a dynamic array. It has been practiced that such
motivation basically just need a *move constructor*. This library uses
"enum ByMove_t { ByMove }" as the signature denoting a move constructor (for
the moment), which is defined to move the source referenced object to 'this'
pointed address (source object is treated non-existent). The reason is that
such an operation is conceptually elementary, thus, it can enable the
definition of a no-throw swap function template (note: implementation needs
a buffer type, e.g. type_store<T>, but this is a different issue).
 
Many other libraries do not contain the move constructor. Bit-wise copy
(memcpy) may mostly do the job, e.g. QString of Qt library, so far. Just
make sure that destructor of the moved object won't be called.
 
Note: C++11 introduced rv-reference and defined another name 'std::move',
a constructor taking a rv-reference argument is therefore called a move
constructor. This library decided to continue the development using this now
standard-confusing move constructor. Simply because ByMove is relatively
more elementary. Many reasons can eventually be translated to being light
weight, which in a way means it can transform easier. Again, This library's
guide "No room should be left for lower-level implement". Another reason is
the ratio of gain vs. cost does not appear good for the author to use it,
hopefully this library can survive.
 
-------- Class member rules
The general rule: Class members should be able to conduct self-check for
correctness, except not possible.
 
Let T denote a given class of this library. The following member names
and associated functionality are defined.
 
T() Default constructor. The object thus construted is referred
to as in default state and so the default object.
 
Postcondition of throw: object does not exist.
 
Note: If object can mean 'no real contents', the default object is
better thus designed, at least to be safely destructable.
 
T(const T&) Construct *this to the state as the source object.
(nothing more to say from general practice)
T(T&, ByMove_t) Move the source object to 'this' pointed address.
This member is not really a constructor since nothing is created.
 
Errno reset(...)
Reconstruct the object to the state as constructed by the arguments
corresponding constructor.
 
Ex: reset members should ideally function identical to the following
example:
Errno T::reset(Type1 a, Type2 b) try {
T obj(a,b);
swap(*this,obj);
return Ok;
}
catch(const Errno& e) {
return e;
};
 
Note: This rule is important. Real practice may want do things
slightly different in some cases, but no. Hidden and hard to
find bugs may exist (maybe the concept or interface of the
class design should be reconsidered).
Note: For reset() (no argument), object return (and Reply) state is
always default regardless of the Errno, if exists, returned.
 
~T Destruct object
 
Postcondition: object does not exist
 
bool is_default() const
return true iff object is equivalent to the default constructed
object (i.e a.is_default() <==> a==T(), if operator== is defined).
 
bool operator==(const T& rhs) const
This function returns true iff *this and rhs are not distinguishable
by using any non-private member on the same condition unless
otherwise explicitly specified.
 
Note: Object equivalence does not include equivalence of SLI and
address of its own.
 
T& operator=(const T&)
Reconstruct object to the state as the copy constructor constructed
(same as reset(const T&) except the return type and throwing error).
 
void swap(&T)
Exchange object state of *this and the argument indicated object.
 
Take 'a.swap(b)' (commutative) for instance, the state of a is set
to the state of b. The previous state of a becomes the state of b.
The same applies for b
 
Note: No construct and destruct semantics is involved
 
Reply
Class specific throw class inheriting Errno.
 
_.. prefix for system-specific members or candidate, or restricted..etc.
 
wy_.. prefix for internal members (for testing, etc.).
 
------
David Brown <david.brown@hesbynett.no>: Jul 03 02:58PM +0200

On 29/06/2023 17:44, Bonita Montero wrote:
> This is an enhanced version:
 
Do you always use "enhanced" as a euphemism for "fewer bugs" ?
 
You make a lot of claims about how "elegant" your style is, and even
claim "I don't make errors at this level". Yet it is rare for you to
post code without then following up shortly afterwards with corrections
and fixes.
 
If you want people to judge your code fairly, please try to test and
debug your code before posting it. No one wants to have to read through
multiple different versions with minor changes, and your
self-corrections make it clear that your code is /not/ "elegant",
"beautiful", "perfect" or however you describe it. It is, in fact, a
rough draft that even the author finds hard to understand and correct.
If that's not the impression you want to give us, then don't post it
until you are sure it is correct. (But please do keep posting the code.)
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)