Re: [dev] Coding style: why /* */ and not //?
One is enough. As it should have been for loop constructs. -- Sylvain
Re: [dev] Yet another "sane alternatives" thread
Hi, My _OPINION_ on those tradeoffs, compilation speed/optimization/speed of execution/execution context, where "usually" I draw my red lines: Use of makefiles: the main rational of makefiles is to re/compile/re/link only what is needed to generate the final products and that in order to generate those very final products faster than if it was done in a dumb sequence. If the final products need some optimization due to their presumed execution contexts, if the optimizing toolchain is too slow to re/generate the final products, use of makefiles is appropriate, but if this is fast enough (true on nearly all small projects), use of makefiles is overkill. Namely an idotic sh script which compiles/links everything in a sequence is enough. You can have a middle ground where you have a shell with job control which can do some dumb // compilation/linking, which is sensible nowadays with our multi-core cpus. Moreover, often, in the case of a dumb sh build script, with a programmer editor, you can easily comment out/in what's needed in blocks, that even on fairly big project in order to reach the "fast enough" use case. If the final products will run fast enough in the presumed execution contexts, a non optimizing toolchain may be enough. If so, the final products re/generation with a dumb script may be enough on fairly bigger projects. We are talking order of magnitude bigger projects, that due to the speed of compilation/linking between different toolchains being "orders of magnitude" different. The real pb here, is that "optimizing toolchains", with optimization turned off, are still "orders of magnitude" slower than dumb toolchains (maybe it got better with the latest gcc). Nowadays, high level script engines are often "fast enough" in all presumed execution contexts, BUT there are tons of them, all figthing to become the only one. This is a cancer in the open source world as many critical runtime/sdk components now require _SEVERAL_, very expensive, high level script engines. If I was microsoft/apple/oracle/_insert your fav silicon valley gangsta here_, I would sabotage the open source world with c++ and similar, and tons of high level script engines (mh). Now, GNU makefiles have features which help in "project configuration". It was very true at the time when they were TONS OF F*CK*NG CLOSE SOURCE UNIXES (God bless gnu/linux). Now, a directory tree of idiotic and simple scripts with some options shall be enough... if there are too many options, usually it means the project should be broken down (divide and conquier), and certainly not use one of the massive SDK systems out there. Unfortunately, linux build system is a user of GNU makefile extensions, due to its massive configuration space and its size. I would not mind a linux build system boostraped with an simple and idiotic build system toolchain (kconfig and kbuild), as it doesn't actually need the heavy weight GNU make. "SDK portability", nobody should dev on a closed source OS. Cross-compilation is meant for that. So all the ruby/python/perl/js/etc SDKs can go to hell since it makes more pertinent to dev on some closed source OSes, which is a definitive no-no for open source OS supporters. The goal being going from closed source OSes torward open source OSes, and certainly not to help, with an additional technical burden, the other way around. Ok, it is far from a perfect explanation, but it gives some clues on my way of seeing things. The main guidelines are roughly speaking, "the less the better", "divide and conquier", "small is beautiful", "and NO, comfort/portability brought by high level and very expensive script engines does not justify anything". -- Sylvain
Re: [dev] Coding style: why /* */ and not //?
On Wed, Dec 26, 2018 at 3:57 AM Martin Tournoij wrote: > > The coding style says: > > > Use /* */ for comments, not // > > Don't want to start a discussion about it, but I'm curious why // is > disallowed? AFAIK all compilers accept // these days, and have for a > long time? My understanding is that everything in C is block based. You can take all groups of whitespace and replace each with a single space and everything still works (except string literals). Using // for comments adds a line based element. That is why the style guide calls for /**/ over //.
Re: [dev] Coding style: why /* */ and not //?
[2018-12-27 08:01] Cág > Silvan Jegen wrote: > > > I also prefer // (mostly because to insert those I can just do a block > > insert in vim/vis). The only downside of //-style comments that I can > > see is that they are only allowed since C99[0]. > > > > Maybe I am missing something too though. > > I use vi[0] and have this in my .exrc: > map q 0i/* ^[$a */^[hh > > (Those are literal escapes) > > You press "q", and the line is commented out. Ah, it's definitely (macro-)scriptable but I am just too lazy to do it :P I thought I may be missing some other disadvantage of using //-style comments... Thanks for the input in any case! Cheers, Silvan
Re: [dev] Coding style: why /* */ and not //?
That is a rather bold sentiment. At uni the attitude is opposite - I actually saw home assignments stating "remember to use many comments to make the code more readable". I actually agree with you; there is much less clutter if the comments don't duplicate that which is already communicated through good naming, and the code is more readable when good naming makes comments superfluous. On Wed, 26 Dec 2018 at 21:57, Bobby Powers wrote: > > On Wed, Dec 26, 2018 at 10:44 AM wrote: > > Preprocessor. I guess having 2 ways to define comments is not significant, > > then better stick to one and the historical one. > > Better than one way is zero ways -- comments are not semantically > significant, so rather than argue about which standards-defined > comment style to use it would better to ban them all. >
Re: [dev] Coding style: why /* */ and not //?
Silvan Jegen wrote: I also prefer // (mostly because to insert those I can just do a block insert in vim/vis). The only downside of //-style comments that I can see is that they are only allowed since C99[0]. Maybe I am missing something too though. I use vi[0] and have this in my .exrc: map q 0i/* ^[$a */^[hh (Those are literal escapes) You press "q", and the line is commented out. [0]: https://github.com/n-t-roff/heirloom-ex-vi -- caóc
Re: [dev] Yet another "sane alternatives" thread
> On Dec 27, 2018, at 12:36 AM, Martin Tournoij wrote: > I am disappointed to see that clang compilation speeds are a lot slower > than what they used to be. The disadvantage of tcc is that it does > almost no optimisations, so even simple programs will run slower. My > solution is to use tcc as the default, and gcc when installing stuff. > After hearing you guys use tcc I went back on a hunt and found the live branch, it is fast! I see it’s more active than pcc on development which is good but optimizations would be great just to replace gcc on a more perm basis. How suckles is adding optimizations to tcc? Would that turn it into a mess like gcc or is it something that either hasn’t been a priority yet or isn’t within the scope of the project? Thinking out loud here but most things can be scripted, perhaps even a makefile conversion to avoid make? A conversion would be even better for someone who maintains their own distro since packages could be converted in advance and not need to run the script at compile time. Altho some packages are fairly complex, a conversion script likely wouldn’t be a simple task but I would imagine still simpler than a new make and an investment in moving away from it. ~Stephen
Re: [dev] Coding style: why /* */ and not //?
Hi [2018-12-27 17:27] Martin Tournoij > > On Thu, Dec 27, 2018, at 08:46, Hiltjo Posthuma wrote: > > // is not ANSI. > > Is there a good reason for sticking with ANSI C? It's my understanding > that even most small/minimal compilers support C99 (or most of it)? > > The coding style document even endorses it: "Use C99 without extensions > (ISO/IEC 9899:1999)" > > (Again, just curious, don't want to argue anything one way or the other. > It's just something I've wondered for a while). The strict aliasing rule enforcement[0] could be a reason? This rule was only enforced in C99. Not sure that makes it worth it to stick to C89, especially because there are ways around this rule. Cheers, Silvan [0] https://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
Re: [dev] Coding style: why /* */ and not //?
Hi [2018-12-27 00:56] Martin Tournoij > The coding style says: > > > Use /* */ for comments, not // > > Don't want to start a discussion about it, but I'm curious why // is > disallowed? AFAIK all compilers accept // these days, and have for a > long time? > > I've always preferred // since they can nest (you can comment out a > function with //-style comments, but not with /* */-style comments), but > maybe I'm missing a downside of //-style comments? I also prefer // (mostly because to insert those I can just do a block insert in vim/vis). The only downside of //-style comments that I can see is that they are only allowed since C99[0]. Maybe I am missing something too though. Cheers, Silvan [0] https://en.wikipedia.org/wiki/Comment_(computer_programming)#C
