- Aggregate initialization of base class sub-object, what? - 3 Updates
- Clever or tidy code snippets - 9 Updates
- two's complement idea - 1 Update
- Hardware advice - 3 Updates
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 06 02:27AM +0100 Why does this compile as C++17 with MinGW g++ 9.2 and Visual C++ 2019? #include <string> struct Top { friend void g() {} }; struct Blah: Top { int a = 1; int b = a; }; auto main() -> int { Blah b{ {}, 3, 42 }; (void) b; return b.b; } Result: exit code 42. - Alf |
| Ian Collins <ian-news@hotmail.com>: Mar 07 10:40AM +1300 On 06/03/2020 14:27, Alf P. Steinbach wrote: > (void) b; > return b.b; > } Wasn't the aggregate initialisation of base class sub-object introduced in C++17? -- Ian. |
| Vir Campestris <vir.campestris@invalid.invalid>: Mar 06 09:43PM On 06/03/2020 01:27, Alf P. Steinbach wrote: > } > Result: exit code 42. > - Alf OK with GCC 7.4.0 too. Where there's no need for the friend, the initialiser values in Blah, or the (void)b. But I'm not sure I see the problem. Unless you're asking why it _only_ compiles with 17, and not with 11 - in which case I'm confused too. Andy |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 06 03:12AM -0800 On Wednesday, March 4, 2020 at 6:00:50 PM UTC, Öö Tiib wrote: > > nullptr != fgets(buffer.data(), buffer.size(), pipe.get()) > > could get evaluated. > Uh, I don't follow. Sometimes misinformation is a little too perfect to be accidental. |
| cdalten@gmail.com: Mar 06 05:55AM -0800 On Friday, March 6, 2020 at 3:12:15 AM UTC-8, Frederick Gotham wrote: > > > could get evaluated. > > Uh, I don't follow. > Sometimes misinformation is a little too perfect to be accidental. If nullptr is on the left hand side, it evaluates to a value, and thus, the entire expression will evaluate right away. However, if nullptr is on the right hand side, it might not evaluate right away. Thus the former can lead to a subtle bug. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 06 09:02AM -0500 On 3/6/20 6:12 AM, Frederick Gotham wrote: >>> could get evaluated. >> Uh, I don't follow. > Sometimes misinformation is a little too perfect to be accidental. You might be right. But that message was posted using Chad's e-mail address, so I think that amazing amounts of confusion, possibly fueled by substance abuse, is also a plausible explanation. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 06 06:28AM -0800 > > > Uh, I don't follow. > > Sometimes misinformation is a little too perfect to be accidental. > If nullptr is on the left hand side, it evaluates to a value, and thus, the entire expression will evaluate right away. However, if nullptr is on the right hand side, it might not evaluate right away. Thus the former can lead to a subtle bug. And what consequence do you think evaluation of nullptr will have that could cause this bug? Keep in mind that evaluation of nullptr does not (in this context) mean anything different from evaluation of NULL or 0 or (char*)0. That evaluation doesn't actually do anything that could interfere with anything else. 123456789012345678901234567890123456789012345678901234567890123456789012 The evaluation of the left operand of a comparison operator is indeterminately sequenced with respect to evaluation of the right operand, and there's no sequence point separating them. Therefore, if expression1 != expression2 is a problem because it allows the two expressions to be evaluated in a problematic order, then expression2 != expression1 is just as much as problem, because an implementation is allowed to evaluate them in the same problematic order with either version of that expression. But I still have no idea why you think it's a problem. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 06 09:29AM -0500 > > > Uh, I don't follow. > > Sometimes misinformation is a little too perfect to be accidental. > If nullptr is on the left hand side, it evaluates to a value, and thus, the entire expression will evaluate right away. However, if nullptr is on the right hand side, it might not evaluate right away. Thus the former can lead to a subtle bug. And what consequence do you think evaluation of nullptr will have that could cause this bug? Keep in mind that evaluation of nullptr does not (in this context) mean anything different from evaluation of NULL or 0 or (char*)0. That evaluation doesn't actually do anything that could interfere with anything else. The evaluation of the left operand of a comparison operator is indeterminately sequenced with respect to evaluation of the right operand, and there's no sequence point separating them. Therefore, if expression1 != expression2 is a problem because it allows the two expressions to be evaluated in a problematic order, then expression2 != expression1 is just as much as problem, because an implementation is allowed to evaluate them in the same problematic order with either version of that expression. But I still have no idea why you think it's a problem. |
| David Brown <david.brown@hesbynett.no>: Mar 06 04:16PM +0100 > thus, the entire expression will evaluate right away. However, if > nullptr is on the right hand side, it might not evaluate right away. > Thus the former can lead to a subtle bug. In order to clear up your confusion, please tell us what it is you don't understand about C++ here: 1. The != operator, like every binary operator other than the comma operator, && and ||, requires that both sides are always evaluated before the operator is applied. 2. For the != operator, like all binary operators except the three mentioned above, the order of evaluation is unspecified. Given "A != B", the compiler can choose to evaluate A first, then B, or B first then A, or to intermingle the evaluation of A and B. But both A and B must be fully evaluated before comparing their values. 3. "nullptr" is a keyword in C++. It does not need evaluating as such, any more than the literal 0 needs evaluating - it certainly has no side-effects. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 06 10:21AM -0800 Let me expand on what I said earlier. The line of code in question is while ( nullptr != fgets(buffer.data(), buffer.size(), pipe.get()) ) The != operator is symmetric, and evaluations of the the operands of != are unsequenced (4.6p17) (I earlier said they were indeterminately sequenced, but that was a mistake), so the set of permitted behaviors is the same whether you write it that way or fgets(buffer.data(), buffer.size(), pipe.get()) != nullptr. Given that it's being compared with a pointer, nullptr plays no role in this expression that is any different from any other null pointer constant (7.11). Therefore, any problems that might exist in this expression would also be present if nullptr were replaced with NULL or 0. In a context such as this, any null pointer constant gets implicitly converted to a null pointer of the same pointer type as the other operand, in this case char*. Therefore, whatever problems this expression might have would be unchanged if you replace nullptr with (char*)0. A null pointer compares equal to all other null pointers, and unequal to any other pointers (8.10p2). An expression which appears as a condition in a while statement gets contextually converted to bool (9p4). The result of converting a null pointer to bool is false, and any other pointer value converts to true (7.14p1), so while(nullptr != fgets(buffer.data(), buffer.size(), pipe.get())) has the same exact behavior as while( fgets(buffer.data(), buffer.size(), pipe.get()). Therefore, if there's any problem with the original form of this code, there should still be a problem that form. Could you please identify what you think that problem might be? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 06 12:18PM -0800 On 3/6/2020 6:28 AM, James Kuyper wrote: > allowed to evaluate them in the same problematic order with either > version of that expression. > But I still have no idea why you think it's a problem. Neither do I. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 06 12:18PM -0800 >>> Uh, I don't follow. >> Sometimes misinformation is a little too perfect to be accidental. > If nullptr is on the left hand side, it evaluates to a value, and thus, the entire expression will evaluate right away. However, if nullptr is on the right hand side, it might not evaluate right away. Thus the former can lead to a subtle bug. Why? |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 06 10:18AM +0200 On 15.02.2020 16:44, Tim Rentsch wrote: >> Yes, must be personal... > I meant only that I am representing only my own viewpoint. > Did you think I meant something else? No, I also just meant a personal viewpoint. To be honest, I'm not sure any more which version I dislike more. > creturn funky(); > where 'creturn' means first run any pending destructors, and only > after they finish execute the (implied) return statement. This would mess up the lifetime rules of automatic variables, meaning that their lifetime would not match the visual scope any more. I'm sure this would do more harm than good. Also, such 'creturn' would not solve the initial problems, at least not in cases I have had. Effectively, what is needed is to release a mutex lock temporarily in some circumstances, do something out of the mutex lock, then enter the lock again. Logically this is a task for a single function, any 'return' or 'creturn' would split this task into two functions, which is a bit convoluted, which I think you already mentioned above. > apparent "tail call" be a true tail call, and so could be optimized > to reuse the stack frame. What other kinds of constructs might make > your troublesome mutex uses more tractable? What would help in my case would be a command like 'retry' or 'restart' which would destroy all automatic variables in the function and restart the function again. It would be equivalent to a 'goto' to a label in the start of the function, with the only benefit that the jump destination is more fixed than with a regular goto. Not sure if this would be worth it, especially when considering that in some other closely related scenarios one might want to keep some variables intact. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Mar 06 05:25AM > that's overdoing it since I'm still looking for some > external users. I could still get a 16 core chip > with the AM4 socket. Why do you need 16 core? You program in Python? You can saturate bandwidth with single core, and 4 cores are overkill for most C++ uses ;) I know as I am C++ network programmer ;) -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 06 07:02AM On Fri, 2020-03-06, Melzzzzz wrote: > You can saturate bandwidth with single core, and > 4 cores are overkill for most C++ uses ;) > I know as I am C++ network programmer ;) He's writing something like a compiler. It's not clear to me that the problem is I/O bound. Personally I would start with an old used PC and make plans for replacing it if needed: it's not clear that he needs sixteen cores, either. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Christian Gollwitzer <auriocus@gmx.de>: Mar 06 09:08AM +0100 Am 05.03.20 um 23:52 schrieb Mr Flibble: >> Search for the name T and you'll know him. > Do you not recognize how searching for "T" might be problematic? I > suspect you do and you are simply shitposting. What else did you expect from a real troll? I don't understand why people answer him at all. Christian |
| 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