- Injected class name - 3 Updates
- No, C is not a simple language (PLO) - 7 Updates
- Infinite recursion detection criteria (agreement check) - 1 Update
- Infinite recursion detection criteria (Please correct me if I am wrong) - 1 Update
| Bo Persson <bo@bo-persson.se>: Apr 19 08:05PM +0200 On 2021-04-19 at 17:16, 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"? Yes. :-) My compiler says: 'A' not accessible because 'B' uses 'private' to inherit from 'A' So in B the base class is visible, and accessible as a private part. In C it is visible, but not accessible - as it is a private member of B. You can change that by making the inheritance public: class B : public A { }; Or you can change C to refer to the global name A, instead of to the private base. class C : B { ::A *p; }; |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 19 11:34AM -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"? Ugh... A stupid question with an obvious answer: the injected class name is a _public_ member of its class. So the injected `A::A` is a public member of `A`. It is naturally accessible in `B`. Nothing unusual or remarkable there. The fact that `B` inherits from `A` privately does not interfere with that at all. -- Best regards, Andrey Tarasevich |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 19 02:21PM -0700 On 4/19/2021 11:05 AM, Bo Persson wrote: > Yes. :-) In both cases the injected name is referenced. In the first case it is accessible, in the second - not, in accordance with normal everyday access rules. I just had a brainfart and somehow saw a problem where there was none. > { > ::A *p; > }; ... or one I use an elaborated type specifier class C : B { class A *p; }; which apparently simply ignores access restrictions. -- Best regards, Andrey Tarasevich |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 07:05PM +0200 Le 19/04/2021 à 16:50, olcott a écrit : > I read it into a std::vector that has its capacity set to the file size. char *FileToRam(FILE *input) { fseek(f,0,SEEK_END); long size = ftell(f); fseek(f,0,SEEK_SET); char *result = malloc(1+size)); if (result) { fread(result,1,size,f); result[size]=0; } return result; } No error checking, it is not very difficult to add it. Another interface: char *FileToRam(char *filename) { FILE *f = fopen(filename,"rb"); if (!f) return NULL; fseek(f,0,SEEK_END); long size = ftell(f); fseek(f,0,SEEK_SET); char *result = malloc(1+size)); if (result) { fread(result,1,size,f); result[size]=0; } return result; } Is C unreadable? Too complicated? I guess not! |
| olcott <NoOne@NoWhere.com>: Apr 19 12:23PM -0500 On 4/19/2021 12:05 PM, jacobnavia wrote: > return result; > } > Is C unreadable? Too complicated? I guess not! If you read the input a std::vector that has had its size set to the file size then you can forget about the dynamic allocation of memory and there will never be any memory leaks. This single fact makes C++ simpler than C. In the decades that I have been a C++ programmer I only use the standard template library and C++ classes and studiously ignore all of the rest of C++. Self-contained classes eliminate scads of side-effects making them impossible, thus greatly reducing the time that it take for ongoing maintenance of a system, and greatly reducing overall system costs. Linus Torvalds issues with C++ can be eliminated by coding standards that make the otherwise hidden execution time costs of OOP utterly visible. If we simply consider C++ as C with classes and a stanard template library (the way that I do) his objections go away. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| scott@slp53.sl.home (Scott Lurndal): Apr 19 06:02PM > return result; >} >No error checking, it is not very difficult to add it. mmap is even easier since you don't need to allocate memory. |
| Bo Persson <bo@bo-persson.se>: Apr 19 08:19PM +0200 On 2021-04-19 at 15:43, wij wrote: >> from the C standard library.) > Once upon a time, C++ claimed being a superior system programming language. > Luckily, Linus Torvalds was not fooled as most C++ beginners were. That was more of a self-fullfilling prophecy on Linus' side. Unfortunately for Linus, he was apparently presented with some C++ code from these C++ beginners. And he saw that it was bad. And the blamed it on the language. And not in a nice way either. To quote http://harmful.cat-v.org/software/c++/linus "*YOU* are full of bullshit. C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C. In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with." And so he *did* piss of all competent C++ users, who didn't care to show him what their good code looks like. |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 09:03PM +0200 Le 19/04/2021 à 19:05, jacobnavia a écrit : > return result; > } > Is C unreadable? Too complicated? I guess not! Mmmmmm I am ashamed to acknowledge that I did not close the file in the second example. I saw it after posting. Sorry |
| wij <wyniijj@gmail.com>: Apr 19 01:04PM -0700 On Tuesday, 20 April 2021 at 02:19:23 UTC+8, Bo Persson wrote: > be in C++ over C is likely a programmer that I really *would* prefer to > piss off, so that he doesn't come and screw up any project I'm involved > with." To add more from the link: ------------------------------ In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap. ------------------------------ I read (just impression in my head, I am not a English speaker) another reason Linus Torvalds complained about C++ was something about 'interface' issues, difficult to unite codes from different groups (guess: each has their owe smart idea, back then). |
| olcott <NoOne@NoWhere.com>: Apr 19 03:14PM -0500 On 4/19/2021 2:03 PM, jacobnavia wrote: >> Is C unreadable? Too complicated? I guess not! > Mmmmmm I am ashamed to acknowledge that I did not close the file in the > second example. I saw it after posting. Sorry In the above example using a C++ std::vector that is resized to the size of the input file does make memory leaks utterly impossible. Making memory leaks utterly impossible is a substantially more reliable paradigm than allowing possible memory leaks to exist. It is possible to gain this one single benefit of C++ and totally ignore every other aspect of C++ by simply writing programs using the same C style, yet compile them as c++ programs with a ".cpp" suffix. Many C programmers do not switch to c++ because of the learning curve. By focusing on a tiny subset of c++ (a) the standard template library and (b) encapsulating data and functions together in classes, 90% of the benefit of c++ can be achieved with a tiny little learning curve cost. I started programming in C when K&R was the only standard. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Kaz Kylheku <563-365-8930@kylheku.com>: Apr 19 04:59PM ["Followup-To:" header set to comp.lang.c.] > (2) With the same parameters to X(). > (3) With no conditional branch or indexed jump instructions in Y(). > (4) With no function call returns from X(). These conditions imply runaway recursion. Since X was called with certain arguments, and that resulted in Y being called, such that X can be called again with those same arguments, it means that X doesn't stop the recursion. (I wouldn't say infinite recursion, since we are talking about a conrete implementation with concepts like "machine address". It is actually infinite if X and Y tail call each other, otherwise it is runaway recursion that will exhaust the stack.) > When X() simulates the machine language of Y() and examines resulting > execution trace If X has access to accumulated instruction traces from a prior invocation of X, then it is not a function. It is an imperative procedure with side effects. To be a function, X must instantiate a new trace context each time it is called, which contains no prior traces. If you'd like to discuss an imperative procedure in the context of computability theoiry, it behooves you to convert it to an equivalent function. This is easily doable: you identify all of the state which the procedure mutates, and turn that into a pure calculation, mapping the prior state to the new state. Then you make the old state a function parameter, and the new state part of the return value. If you'd like X to have access to past execution traces, they must be bundled in an argument, which Y passes to X. X can re turn the newly updated execution traces back to Y, which can pass them to X again. However, then we see that (2) is violated "with the same parameters to X". If Y passes two different states to X with different execution trace contents, (2) does not hold. That's the point of the exercise! By insisting on pure functions, we flush out errors of reasoning of this sort, whereby there are "invisible" inputs that we re not taking into account. Because all imperative procedures can be refactored into functions, every theoretical result that we prove about functions holds for imperative procedures. We do not lose any generality; rather, we gain analytic ability. |
| olcott <NoOne@NoWhere.com>: Apr 19 11:50AM -0500 On 4/19/2021 11:12 AM, wij wrote: > supported by physical machines, no one can refute. > Publish it in some way is enough (like astronomers spot a comet or found some > strange physic phenomena). I need to confirm that there are no gaps in my reasoning where an execution trace meets the above criteria and is not infinitely recursive. -- 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