- All function declarations/defintions and variable declaration/defintions one one line - 2 Updates
- Order of designated initializers in C++20 - 1 Update
- Static_assert in 2017 C++ - 2 Updates
- ""Rust is the future of systems programming, C is the new Assembly": Intel principal engineer, Josh Triplett" - 1 Update
| Vir Campestris <vir.campestris@invalid.invalid>: Sep 02 09:39PM +0100 On 02/09/2019 11:30, Frederick Gotham wrote: > (double x); > I've tried a few different code beautifiers and none of them can turn this into a one-liner. > Anyone got a tool for this? You're right, it's horrible. But don't change it. If you do everyone from now on looking at the file's history in the source control system to find out what idiot wrote that stupid function declaration will find the author is one fgotham... Andy |
| Keith Thompson <kst-u@mib.org>: Sep 02 03:06PM -0700 > I've tried a few different code beautifiers and none of them can turn > this into a one-liner. > Anyone got a tool for this? Are most or all function declarations in the project like that? Is it part of the style guide for the project? If so, consider leaving it alone. I've seen styles that require function names to be at the beginning of the line. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Richard Damon <Richard@Damon-Family.org>: Sep 02 05:48PM -0400 On 9/2/19 5:44 AM, Juha Nieminen wrote: > initializers are not in the same order as in the declaration of the struct, > but at least clang seems to simply evaluate the values in the same order > as the latter, so it doesn't seem to be a problem. My first guess is that they found that the fact that initializer lists in constructors allowed things to be specified out of order caused enough problems (but was allowed from the beginning so too much code did it) that they didn't want to repeat the mistake. I am not familiar with how C++ will implement this, but if the initializers are going to be run time expressions, and thus able to reference other members of the struct (like initializer lists can) then the problem is real. |
| David Brown <david.brown@hesbynett.no>: Sep 02 10:02PM +0200 On 02/09/2019 15:55, Bonita Montero wrote: >> No, you won't. You will just be ignored. > That's your hope because you want this to be sanctioned. > But this won't fulfill. My hope is that you will understand the point of following the conventions of whatever type of discussion group, forum, etc., you are in - and start using proper Usenet quotations and attributions. It would be better for you, better for the group, and better for the threads you engage in. It won't make me agree with much of what you write, but it would make the threads more pleasant. |
| Richard Damon <Richard@Damon-Family.org>: Sep 02 05:40PM -0400 >> text space in the file and virtually zero processing time during >> compilation. Treat it as file documentation for the requirements of the >> system, and make it readable. The one purpose of IEC559 in the message is that that is what the language calls it, so including it in the message might be useful. My main thought is why work hard to coming up with a minimal message when there is NO run time cost to the fuller message. The string shouldn't even be included in the image, as static_assert generates no code. Yes, the message may be never seen, but if it IS seen, it would seem best to make it clear. The expected output (but I don't think required) is printing the message, and maybe the condition that was false as part of the error message. My preference would be that the message be fairly self explanatory by itself. Yes, they can go to the source code to read a comment near by, and maybe even that happens somewhat automatically if they are building in an IDE, but the less you assume about the environment, the better for the user. If the message is clear, the user might realize without needing to dig into the code, that they need to invoke the build with a flag to use IEC559. It would be nice if in the vicinity of the static_assert was some comments explaining WHY you have such a statement in the code, in case someone on a machine that doesn't support it tries to use it, so they can figure out if they want to try to remove the assumptions in the code or if they need to try to find another package. |
| Richard Damon <Richard@Damon-Family.org>: Sep 02 05:16PM -0400 On 9/2/19 1:33 PM, Bonita Montero wrote: > Have you considered the part of such an I/O-operation that might fail > is the kernel-call that has a higher processing-overhead than the error > -handling itself? Kernel, what kernel. From my experience, most of the truly real time systems have nothing remotely like a *nix or Windows kernel anywhere in them. They are running on machines much smaller than your typical X86 processor which is focused on a particular job. I/O operations are quick an efficient, and there isn't the heavy security isolation of a large monolithic operating system. People whose world is all monolithic OS machines, with heavy isolation between processes and high costs of context switches to do many things may have trouble understanding the very different world of the smallish processor running much closer to bare metal to get the job done quickly, efficiently, and ON TIME. Different problems need different sorts of solutions which have different types of environments that they run under. |
| 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