- OOD idea of C++ and class coding guide lines - 3 Updates
- I need a CPU core exclusively for one thread - 13 Updates
| wij <wyniijj5@gmail.com>: Jul 10 09:54AM -0700 On Monday, July 10, 2023 at 1:50:58 AM UTC+8, wij wrote: > 1. Error report itself has to be error free. > 2. Efficiency. Many of such error reports may happen and happen frequently. > No one like to do the heavy decoding job everywhere. A passage is added to the appendix Losing Context, of which mostly had shown. Also, the followings are for review: -------------------- In a metaphor, throwing error is like using the thread local errno to propagate the error report with the enforcement that the stack will unwind if the function in the stack frame did not check the errno. So, in the general case, caller function has no way to know which function in the unwound path is responsible for the errno. ---------------- The following is the appendix for C++ programmers not used to this "disguised C++ of C" programming guidelines. +---------------------------------------------------+ | Appendix B: Possible doubt of StdC++ library user | +---------------------------------------------------+ .Program is difficult to read: The author believes, mixed style may be the major issue. Programmers are more often in the code review process for correctness than exhibiting the codes. Terseness that hides details that need to guess, and scattered source may be more of the problem to concern. .'Less human language': The semantics of C++ language is defined ultimately by the target assembly and recognized by CPU, not any one, no magic in this regard. Far too human language and ideal consume effort and creates illusion difficult to debug. Although it is possible the high level language can lead to the invention of a new machine, but, so far, no machine can be beyond TM. If the language wants so, do it directly. As the author understood, parallel (muli-cpu) machine is likely still a TM or a TM with an additional random bit source. Again, no fancy things there (Of course, proving these statement wrong is very welcome to all, e.g. Artificial Neural Network. This is just what libwy should say). --------------------------------------------------------- Finally, the author (me) thinks he is probably not able to do much more to make libwy mature, help is needed from different person. Join the project to modify it (or, if you can do similar things by your own, notify me the project. Or, spread the message). |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 10 11:56AM -0700 On 6/28/2023 1:36 AM, wij wrote: > ask for suggestions to refine in the way because one reason is that recently > the many questions I saw in this forum are actually rooted in class design > problems (or problems of being too expressive, arbitrary). [...] Here are some coding guidelines for ya: https://www.stroustrup.com/JSF-AV-rules.pdf ;^) |
| wij <wyniijj5@gmail.com>: Jul 10 02:13PM -0700 On Tuesday, July 11, 2023 at 2:56:19 AM UTC+8, Chris M. Thomasson wrote: > Here are some coding guidelines for ya: > https://www.stroustrup.com/JSF-AV-rules.pdf > ;^) Thanks, it looks my class member rule win! (I can provide stronger restriction). This is one thousand bill [$1000千圓], keep the change. |
| David Brown <david.brown@hesbynett.no>: Jul 10 08:57AM +0200 On 10/07/2023 01:09, Keith Thompson wrote: >> they are different kinds of register. > [...] > In the gcc documentation, RTL means "Register Transfer Language". Thanks for the correction. GCC's RTL is the internal language / notation / data structure at the register transfer level. In either case, we are talking about registers, and transfer of data into and out of them - the same name, and related concepts, but major differences nonetheless when talking about the inner workings of compilers, and digital hardware designs. They are close enough for potential confusion, and I hope I've made things a little clearer for folks here unfamiliar with hardware design languages. |
| Muttley@dastardlyhq.com: Jul 10 08:29AM On Sun, 09 Jul 2023 15:37:28 GMT >hypervisor skunkwork (1998/1999) at SGI, so I was, at the time, quite familiar >with the NTOS portions of windows (which were strikingly similar to the >VAX VMS internals that I worked with in the early 80's). Though the differences I suspect were crucial given that VMS could literally run for years without an issue whereas NT4 was doing well if it managed a few weeks without requiring a reboot. |
| "Fred. Zwarts" <F.Zwarts@HetNet.nl>: Jul 10 12:15PM +0200 > Though the differences I suspect were crucial given that VMS could literally > run for years without an issue whereas NT4 was doing well if it managed a > few weeks without requiring a reboot. I suspect that those differences were less in the system kernel and more in the drivers. A lot of cheap hardware producers created insufficiently tested drivers for Windows NT, but there were very little third party drivers for VMS. (But I loved VMS.) |
| David Brown <david.brown@hesbynett.no>: Jul 10 12:47PM +0200 > Though the differences I suspect were crucial given that VMS could literally > run for years without an issue whereas NT4 was doing well if it managed a > few weeks without requiring a reboot. We had an NT 4 file server that ran pretty much continuously (certainly months at a time). I don't remember it ever crashing or needing rebooted. The trick was letting it do the one job, and not trying anything fancy. I also remember NT 4.0 workstation as quite a stable version of Windows. (After heavy use over many years, however, my system emptied it's start menu and replaced it with a single entry labelled "Eject PC", complete with appropriate icon. And it started asking me to close the door on drive c:. But it still worked fine otherwise.) I doubt if anyone would compare NT 4.0 favourably with VMS for solidity or uptime, but it was not bad for Windows. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 10 02:10PM +0200 Am 10.07.2023 um 12:47 schrieb David Brown: > door on drive c:. But it still worked fine otherwise.) > I doubt if anyone would compare NT 4.0 favourably with VMS for solidity > or uptime, but it was not bad for Windows. His assumptions are felt competence. |
| Muttley@dastardlyhq.com: Jul 10 03:16PM On Mon, 10 Jul 2023 12:15:15 +0200 >in the drivers. A lot of cheap hardware producers created insufficiently >tested drivers for Windows NT, but there were very little third party >drivers for VMS. They couldn't all have been bad. The company I worked for at the time went big time for NT4 and came to regret it. Most of the time it ran like the CPU was a Z80 and then - usually at awkward times - would bluescreen. |
| Muttley@dastardlyhq.com: Jul 10 03:19PM On Mon, 10 Jul 2023 12:47:42 +0200 >months at a time). I don't remember it ever crashing or needing >rebooted. The trick was letting it do the one job, and not trying >anything fancy. Except MS sold it as a *nix replacement. However it was clearly was nowhere near ready for 5 nines uptime doing any serious work. eg running any kind of corporation scale RDBMS on it was risking your business. >I doubt if anyone would compare NT 4.0 favourably with VMS for solidity >or uptime, but it was not bad for Windows. Hardly a recommendation. Windows didn't become close to reliable until W2K. |
| Muttley@dastardlyhq.com: Jul 10 03:20PM On Mon, 10 Jul 2023 14:10:26 +0200 >> I doubt if anyone would compare NT 4.0 favourably with VMS for solidity >> or uptime, but it was not bad for Windows. >His assumptions are felt competence. And again in english? |
| David Brown <david.brown@hesbynett.no>: Jul 10 05:52PM +0200 > Except MS sold it as a *nix replacement. However it was clearly was nowhere > near ready for 5 nines uptime doing any serious work. eg running any kind of > corporation scale RDBMS on it was risking your business. I think it was more NT 3.5 that was aimed/marketed as a *nix alternative. NT 4.0 was more useable for a wider range of people, especially on the desktop (rather than just a server), but it did this by compromising stability and security. In particular, many drivers - especially graphics drivers - were poor quality third-party code yet ran with kernel permissions for efficiency. (Our NT 4.0 server ran as a file server, but not a database server.) >> I doubt if anyone would compare NT 4.0 favourably with VMS for solidity >> or uptime, but it was not bad for Windows. > Hardly a recommendation. Windows didn't become close to reliable until W2K. W2K was also good, but I did find NT4.0sp3 quite solid. Once the Win9x line died out, Windows stability became a lot better - it all depends on what you do with it. |
| "Fred. Zwarts" <F.Zwarts@HetNet.nl>: Jul 10 06:23PM +0200 >> tested drivers for Windows NT, but there were very little third party >> drivers for VMS. > They couldn't all have been bad. There is a reason why Microsoft started with Microsoft certified drivers. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 10 06:52PM +0200 >>> or uptime, but it was not bad for Windows. >> His assumptions are felt competence. > And again in english? You say things you don't know but that you feel. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 09:16PM +0100 On 08/07/2023 15:19, Bonita Montero wrote: >> all so far beyond you that the Dunning Kruger effect has taken over. > His reasoning is really 180 degrees opposite of mine, > to an extent that is easily recognizable as fantasy. Bonita, once upon a time for a year I worked on graphics processor validation. (The company shut the office after a year, and no I don't think it was anything to do with me). This is ten years ago, and the processors were much simpler then. Even so I was writing code to run on server farms. The fastest computers we could get. All linked together with high speed networking. And even so the simulations took _days_ to run. What he has described is entirely consistent with my experience. If you happen to be anywhere near Cambridge, UK I'm pretty sure I can get you a face to face meeting over a beer with some people I know. I am certain that they are running server farms for their validation too. Andy |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 09:21PM +0100 On 10/07/2023 11:15, Fred. Zwarts wrote: > tested drivers for Windows NT, but there were very little third party > drivers for VMS. > (But I loved VMS.) Microsoft were aware of the problem, and taking steps to address it. I have a glass in front of me labelled "IRP-OPOLOOZA" which is a souvenir of when I spent time in Redmond for interop tests. Andy |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment