- Injected class name - 7 Updates
- No, C is not a simple language - 8 Updates
- Geodetic Development Tool - 1 Update
- Geodätische Funktionssammlung - 2 Updates
- Equivalent halting definitions (identical set) - 3 Updates
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 20 06:06PM -0700 On 4/19/2021 2:21 PM, Andrey Tarasevich wrote: > class A *p; > }; > which apparently simply ignores access restrictions. Scratch that. This appears to be a bug in GCC. Neither Clang nor MSVC allow that. -- Best regards, Andrey Tarasevich |
| "Christian Hanné" <the.hanne@gmail.com>: Apr 21 03:35AM +0200 >> which apparently simply ignores access restrictions. > Scratch that. This appears to be a bug in GCC. Neither Clang nor MSVC > allow that. No, that's perfectly legal code ! |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 21 06:29AM -0700 On 4/20/2021 6:35 PM, Christian Hanné wrote: >> Scratch that. This appears to be a bug in GCC. Neither Clang nor MSVC >> allow that. > No, that's perfectly legal code ! Sorry, but a mere "that's perfectly legal code" will not fly here with me. If you claim that a private name `A` should be accessible here through elaborated type specifier `class A` (and that Clang and MSVC are wrong in rejecting this code), you need to explain in detail what makes you think so. You need to quote the C++ standard. -- Best regards, Andrey Tarasevich |
| Richard Damon <Richard@Damon-Family.org>: Apr 21 09:54AM -0400 On 4/21/21 9:29 AM, Andrey Tarasevich wrote: > elaborated type specifier `class A` (and that Clang and MSVC are wrong > in rejecting this code), you need to explain in detail what makes you > think so. You need to quote the C++ standard. I would need to dig hard through the standard to figure out which is right, but the name A does get into class C by two different paths. One is that it is a global name, the other is that it is a private base of a base class. A basic rule is accessibility does not affect visibility, so if the visibility via base class has priority of the global visibility, it will hide it without scoping, and then be not accessible. Apparently there is a difference in how it was read by two compiler writers, (or at least implemented) and a careful study would be needed to see which is right. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 21 07:35AM -0700 On 4/21/2021 6:54 AM, Richard Damon wrote: >>>> allow that. >>> No, that's perfectly legal code ! >> Sorry, but a mere "that's perfectly legal code" will not fly here with me. > Apparently there is a difference in how it was read by two compiler > writers, (or at least implemented) and a careful study would be needed > to see which is right. Simple experiments show that no, there isn't. Firstly, GCC will issue a proper error message if one uses a plain type name `A` instead of elaborated type specifier `class A`. So, this is not just about name `A`, it is specifically about how an *elaborated type specifier* is treated. This is much more specific, supposedly easier to research, and I don't see anything in the standard that would provide special treatment to this situation. Secondly, here's a slightly different experiment class A { struct X {}; }; class B : A { class X x; }; This example also compiles fine in GCC. Note that this time there's no "open" access path to `A::X` from *anywhere*. Regardless of which side you approach it from, `A::X` is private, private and private. It is hopelessly inaccessible, no matter how you slice it. Yet GCC manages to ignore access protection in this example. (Again, for elaborated type specifier only.) This is almost certainly a bag-o-feature of GCC. It could have been done deliberately (although `-pedantic` doesn't help), but there seems to be nothing in the standard about this kind of special treatment. -- Best regards, Andrey Tarasevich |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 21 07:48AM -0700 On 4/21/2021 7:35 AM, Andrey Tarasevich wrote: > class X x; > }; > This example also compiles fine in GCC. The difference in class-key is unintentional. Use `class X` in all cases for consistency. > This is almost certainly a bag-o-feature of GCC. I meant to say "bug-o-feature" :) -- Best regards, Andrey Tarasevich |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 21 03:45PM -0700 On 4/19/2021 8:16 AM, Andrey Tarasevich wrote: > What exactly does it find? Where is it described in the standard? Is it > something as simple as "base class list is also searched during > unqualified name lookup"? A long time ago, when I was first learning C++, I would do something like: struct A { int m_A_foo; }; struct B : A { int m_B_foo; }; ;^) |
| Juha Nieminen <nospam@thanks.invalid>: Apr 21 04:37AM > See above. In small spaces GC is not that good. But we were talking > about a TEXT EDITOR for learning C, so that is probably a PC environment > where GC SHINES! If that's the case, then just use a language like Java or Python. Or, you know, C++. At least you won't be needing to use non-standard third-party extensions. |
| wij <wyniijj@gmail.com>: Apr 20 10:02PM -0700 On Wednesday, 21 April 2021 at 12:37:31 UTC+8, Juha Nieminen wrote: > If that's the case, then just use a language like Java or Python. > Or, you know, C++. > At least you won't be needing to use non-standard third-party extensions. If that's the case, why you learn C/C++? I feel your logic is similar to olcott's, maybe a bit worse. |
| wij <wyniijj@gmail.com>: Apr 20 10:35PM -0700 On Wednesday, 21 April 2021 at 13:02:31 UTC+8, wij wrote: > > At least you won't be needing to use non-standard third-party extensions. > If that's the case, why you learn C/C++? > I feel your logic is similar to olcott's, maybe a bit worse. By the way, I do not use most "standard" stuff, that enables me to gain more functionality from "C", and much less unnecessary "standard" burdens. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 21 06:30PM +0100 On Tue, 20 Apr 2021 04:02:30 +0000 (UTC) > > Luckily, Linus Torvalds was not fooled as most C++ beginners were. > Almost nothing of what Linux wrote in that idiotic rant was true even back > when it was written, much less now. I would say it has about the same validity as your own arguments about C and how much easier C++ is for beginners (you came up with a similar set of arguments about a year or so ago). Both languages are difficult for beginners and require a high degree of skill to use well. On balance I suspect C++ has a few more 'gotchas' because it is a more complex language and does more things for you implicitly. For what it is worth, Linus has now accepted Rust into the linux kernel for certain (at present limited) purposes, principally I think because of its linear/affine type system. |
| scott@slp53.sl.home (Scott Lurndal): Apr 21 06:33PM >For what it is worth, Linus has now accepted Rust into the linux kernel >for certain (at present limited) purposes, principally I think because >of its linear/affine type system. And linux aside, I've personally written two commercial operating systems and two hypervisors in C++ since 1989. It works just fine for operating systems _if you don't use the C++ library crap_. Don't use vectors, don't use maps, don't use exceptions, don't use dynamic allocation. (use placement new or pool-based page/slab/slub allocators). You still get the benefits of data hiding/encapsulation, and compiler support for what linux calls "ops vectors" (which are basically vtables). I do think Linus is off base. However, it's a moot point as nobody will ever rewrite linux in a new language. He does have a point about the odd need for some C++ programmers to show off their expertise by using every odd or unusual C++ feature. class fs_vectors_t { /* pure virtual (abstract) file system op vectors; e.g. lookup, create, open, close, delete, read, write */ } class ext4_fs : public fs_vectors_t { ... } class btrfs : public fs_vectors_t { ... } |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 21 09:14PM +0100 On Wed, 21 Apr 2021 18:33:54 GMT > will ever rewrite linux in a new language. He does have a point about > the odd need for some C++ programmers to show off their expertise by using > every odd or unusual C++ feature. [snip] I go along with pretty much all of that. I suppose the calculation for a putative kernel lead (here, Linus) is (i) whether, if you have started out in C, it is worth moving to C++ (IOW, are the limited additional features of C++ over C that you would be prepared to accept in the kernel worth the change) and (ii) whether you trust open source contributors to stick to that limited set without opening up potential aggravation later. That might be easier in a closed-source environment such as the one I presume you were working in. The fact is that C is now a vastly smaller language than, say, C++20. Of course, similar issues arise for including Rust in the kernel. It will be interesting to see how it works out. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 21 03:26PM -0700 On 4/20/2021 9:37 PM, Juha Nieminen wrote: > If that's the case, then just use a language like Java or Python. > Or, you know, C++. > At least you won't be needing to use non-standard third-party extensions. Fwiw, using an "extension" in C is nothing new. Want to create a server, better learn how to use sockets. If you want to go deep, create your own TCP stack. Is creating a driver in C to use a 3d party device "cheating" by using third-party extensions? third-party API's? Luckily for me a lot of my recent work is 100% workable with pure C and graphics. Pure C generating a PPM image is absolutely perfect. 100% portable and no 3d party code used in any way, shape or form. :^) If the user wants to view the result of my C code, they can choose any PPM viewer they want to. There, pure C code generating fractals, vector fields, abstract art, ect. ;^) Way back in the day I would be forced to use "extensions" to C. Things like POSIX, Pthreads, my own externally assembled atomic's libs for various archs using MASM and GAS, ect... I still have a bunch of code that uses the good ol' Pthreads for win32 lib here: https://sourceware.org/pthreads-win32 When C/C++ 11 made atomic's and threading standard, it was really nice, but made me want to port all of my older code from Pthreads and assembly language to the new stuff. Here is a result of some of my C code generating a single file for another program, PovRay, to raytrace for me: https://youtu.be/skGUAXAx6eg https://youtu.be/R0v_1EBAOr4 |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 21 03:37PM -0700 On 4/21/2021 11:33 AM, Scott Lurndal wrote: > _if you don't use the C++ library crap_. Don't use vectors, don't use maps, > don't use exceptions, don't use dynamic allocation. (use placement new > or pool-based page/slab/slub allocators). Agreed! |
| Fred Killet <killet@killetsoft.de>: Apr 21 05:43PM +0200 Dear software developers, here I post a hint for people who develop programs with geodetic functionality like coordinate transformations, datum shifts or distance calculations. For this you can easily include ready for use geodetic functions from my Geodetic Development Tool GeoDLL. The Dynamic Link Library can be used with almost all modern programming languages like C, C++, C#, Basic, Delphi, Pascal, Java, Fortran, xSharp, MS-Office and so on. Examples and interfaces are available for many programming languages. GeoDLL is a professional Geodetic Development Tool or Geodetic Function Library for worldwide 2D and 3D coordinate transformations and datum shifts with highest accuracy. Also: Helmert and Molodensky parameters, NTv2, HARN, INSPIRE, EPSG, elevation model (DEM), distance and time zone calculation, meridian convergence and much more. GeoDLL is available as 32bit and 64bit DLL and as C / C++ source code. The DLL is very fast, secure and compact thanks to the consistent development in C / C++ with Microsoft Visual Studio. The geodetic functions are available in 32bit and 64bit architecture. All functions are prepared for multithreading and server operating. You find a free downloadable test version on https://www.killetsoft.de/p_gdla_e.htm Notes about the NTv2 support can be found here: https://www.killetsoft.de/t_ntv2_e.htm Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm Best regards and stay healthy! Fred Email: https://www.killetsoft.de/email.htm?lan=e&btr=News |
| Fred Killet <killet@killetsoft.de>: Apr 21 05:13PM +0200 Guten Tag liebe Softwareentwickler, hier poste ich einen Hinweis für Leute, die Programme mit geodätischer Funktionalität wie z.B. Koordinatentransformationen, Datumswechsel oder Entfernungsberechnungen entwickeln. Dafür können ganz einfach fertige geodätische Funktionen aus meinem Geodetic Development Tool GeoDLL eingebunden werden. Die Dynamic Link Library kann mit fast allen modernen Programmiersprachen wie z.B. C, C++, C#, Basic, Delphi, Pascal, Java, Fortran, xSharp, MS-Office usw. verwendet werden. Für viele Programmiersprachen sind Beispiele und Schnittstellen vorhanden. GeoDLL ist ein professionelles Geodetic Development Tool bzw. eine Geodätische Funktionssammlung für weltweite 2D- und 3D-Koordinatentransformationen und Datumswechsel mit höchster Genauigkeit. Außerdem: Helmert- und Molodensky-Parameter, NTv2, HARN, INSPIRE, EPSG, Höhenmodell (DEM), Entfernungs- und Zeitzonenberechnung, Meridian-Konvergenz und vieles mehr. GeoDLL ist als 32Bit und 64Bit DLL und als C / C++ Quelltext verfügbar. Die DLL ist durch die konsequente Entwicklung in C / C++ unter Microsoft Visual Studio sehr schnell, sicher und kompakt. Die geodätischen Funktionen stehen in 32Bit- und 64Bit-Architektur zur Verfügung. Alle Funktionen sind multithreadingfähig und auf den Serverbetrieb zugeschnitten. Eine kostenlose Testversion zum Herunterladen findet ihr hier: https://www.killetsoft.de/p_gdla_d.htm Hinweise zur NTv2-Unterstützung sind hier zu finden: https://www.killetsoft.de/t_ntv2_d.htm Bericht zur Qualität der Koordinatentransformationen: https://www.killetsoft.de/t_1705_d.htm Liebe Grüße und bleiben Sie gesund! Fred Email: https://www.killetsoft.de/email.htm?lan=d&btr=News |
| Fred Killet <killet@killetsoft.de>: Apr 21 05:42PM +0200 Sorry, the hind should be sent in English language! |
| olcott <NoOne@NoWhere.com>: Apr 20 07:03PM -0500 On 4/20/2021 5:09 PM, Kaz Kylheku wrote: >> has infinite execution because (a) and (b) > Yeah yeah; whether or not an integer must be incremented by one > to make it divisible by two <is> equivalent to whether it is odd. You know that I am correct about this that is why you removed the context. I am going to keep bugging you again and again on this until you give it an accurate critique Try and find the differing element: Whether or not a simulated input must have its simulation aborted to prevent its infinite execution <is> equivalent to deciding that an input has infinite execution because (a) and (b) (a) Every input having infinite execution would have to have its simulation aborted to prevent its otherwise infinite execution. (b) Every input not having infinite execution need not have its simulation aborted to prevent infinite execution. Thus the set of inputs that must be aborted to prevent their infinite execution is the exact same set of inputs that have infinite execution. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Richard Damon <Richard@Damon-Family.org>: Apr 20 09:52PM -0400 On 4/20/21 6:02 PM, olcott wrote: > simulation aborted to prevent infinite execution. > Thus the set of inputs that must be aborted to prevent their infinite > execution is the exact same set of inputs that have infinite execution. H_Hat, by the fact that when run as an independent machine (assuming Halts behaves as defined) will be a Halting Computation (yes, it halts because the Halts it used to emulate a H_Hat terminated that emulation and returned a non-halting answer), and thus fall into category (b). By YOUR definition, you claim that Halts needed to abort it to prevent its otherwise infinite execution, so you put it in category (a). (b) != (a) so we have a difference. That, or your function Halts doesn't meet the requirements it needs to in order to be called a Halt Decider. |
| olcott <NoOne@NoWhere.com>: Apr 20 09:57PM -0500 On 4/20/2021 8:52 PM, Richard Damon wrote: >> Thus the set of inputs that must be aborted to prevent their infinite >> execution is the exact same set of inputs that have infinite execution. > H_Hat, by the fact Is an off topic dodge of this point: Computations that only halted because the halt decider correctly decided that their simulation must be aborted to prevent their otherwise infinite execution define the exact same set of elements as the set of non-halting computations. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| 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