Re: [dev] Coding style: why /* */ and not //?
Those guys are amazing. How much more toxic can they be?? I am really suspicious of their "sponsorship" with the linux fondation. I don't think they did grant a exFAT/FAT64 free patent use for all linux users... (event though on most digital cameras, the 'official' file system of SDCards is exFAT/FAT64). I would be able to use a kernel based file system driver than fuse crap: exFAT/FAT64 is simple and well understood enough to be in the kernel, which is not the case of the ntfs reversed engineered fuse driver (ntfs-3g). Back on PDF 2.0: as a binary vector format for printing, the 2.0 does complement/cleanup some color space stuff which is a good thing, but... they added a huge amount of cr*p with the html-ish forms. I don't recall they put the html-ish form cr*p in an optional annex this time. As for the web, the pb is mainly at the w3c and at the web developer level. I am getting a lawer and I am going to start to deal with this issue first with the french administration. Noscript browser devs may have to team up in order to get something in official html standard, which is "edited" by M$ and gogol ppl. A noscript/light browser profile, something like that. -- Sylvain
Re: [dev] Coding style: why /* */ and not //?
On Thu, Jan 10, 2019 at 08:11:57PM +, sylvain.bertr...@gmail.com wrote: > Expect POSIX to add significant technical cost over time, like ISO, ANSI, > the most monstruous being the w3c. You ever try to write POSIX utilities according to the standard? Believe me, POSIX of all standards doesn't need to add anything to incur significant technical cost. Just say "cat -u". I mean, -v is considered harmful, but what about -u? Considered useless? system() is supposed to return 127 if the command interpreter could not be launched. That's mighty specific. cp -i is a thing. Etc. pp. However, for ISO C it is actually pretty easy to spot MS contributions. In this case, look at Annex K. C89 contained a lot of badly designed interfaces in Clause 7, so C95 added a few better designed alternatives (or bodges on the original design, depending on your view). And then M$ came along and added Annex K, where they added _s to a lot of functions and said "Use these henceforth. Just go through your code with a find-and-replace and then sin no more." And nobody, absolutely nobody bought it. These functions are also badly designed, but for other reasons than the C89 functions. Thankfully that whole nonsense is confined to an optional annex of the standard, that next to nobody implements. M$ does of course, but Visual Studio is not really relevant when it comes to C implementations. They still only implement C95, with cherry-picked features from C99, mostly ones that are also in C++. Ciao, Markus
Re: [dev] Coding style: why /* */ and not //?
On Wed, 26 Dec 2018 at 03:56, Martin Tournoij wrote: > 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? Consistency, -- we only want one way of comments in code, as with everything else. Following the one way approach, leads to better consistency and less complexity. Besides this, /**/ is the more traditional style. The longer something is in place, the likelier it will be existent even longer ;) Thanks, Anselm
Re: [dev] Coding style: why /* */ and not //?
A big warning: a "standard" is not anymore sufficient. Look at the microsoft xml document format at ISO. It means the corporations which have an interest at making file formats complex in order to kill any light software implementation alternative _will go through standard bodies_. Look at what did microsoft with pdf 2.0 at ISO too. Expect POSIX to add significant technical cost over time, like ISO, ANSI, the most monstruous being the w3c. -- Sylvain
Re: [dev] Coding style: why /* */ and not //?
Hello Martin, > 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 guess you're talking about suckless coding style guide. Coding style guide is for published code. For your temporary testing code, you're free to comment lines with // if you want to, this will bother nobody else. We're talking about published code, so most of the arguments in favor of using // (like nesting comments) don't apply. Using /* */ is about commenting, not commenting out, and is more visible.
Re: [dev] Coding style: why /* */ and not //?
> > The only issue I see with c99 code is that some of the compilers > > appear to be behind the times on c. Any reason why we wouldn???t want > > to use a newer c feature other than compatibility? > > it's always about weighing convenience against freedom. Modern language > standards have picked up pace, comparable to web standards. By > voluntarily staying with a relatively simple, older version (like C99) > you don't "invest" into a new language that might turn out to be a > tough dependency in the long run. Do we really want to solely depend on > GCC And LLVM/Clang by using C11? C11 is not POSIX. Posix only recognice the tool c99. Older versions of the standard, c89. If you use cc, gcc ot c89 in current POSIX systems your code is not portable. If you don't agree, you can send a request to the POSIX commitee. Until that point, you will continue using c99 and following the POSIX standard. Best regards,
Re: [dev] Coding style: why /* */ and not //?
On Thu, 10 Jan 2019 08:46:51 -0500 stephen Turner wrote: Dear Stephen, > The only issue I see with c99 code is that some of the compilers > appear to be behind the times on c. Any reason why we wouldn’t want > to use a newer c feature other than compatibility? it's always about weighing convenience against freedom. Modern language standards have picked up pace, comparable to web standards. By voluntarily staying with a relatively simple, older version (like C99) you don't "invest" into a new language that might turn out to be a tough dependency in the long run. Do we really want to solely depend on GCC And LLVM/Clang by using C11? Using C99, it's possible to use independent compilers (e.g. scc), because it doesn't take 5000 man hours to implement it. But language choice is only one aspect, the other being avoiding GNU extensions. Does this have tradeoffs? Of course! But it often makes you rethink your algorithms and approaches, and come up with more elegant solutions. With best regards Laslo -- Laslo Hunhold pgp1j4G6YrIh3.pgp Description: PGP signature
Re: [dev] Coding style: why /* */ and not //?
The only issue I see with c99 code is that some of the compilers appear to be behind the times on c. Any reason why we wouldn’t want to use a newer c feature other than compatibility? Thanks, Stephen On Jan 10, 2019, at 4:27 AM, David Demelier wrote: Le 27/12/2018 à 11:10, Silvan Jegen a écrit : > The only downside of //-style comments that I can > see is that they are only allowed since C99[0]. Yes, but C99 was released 20 years ago. Perhaps it's okay to use it nowadays :) Regards, -- David
Re: [dev] Coding style: why /* */ and not //?
Le 27/12/2018 à 11:10, Silvan Jegen a écrit : The only downside of //-style comments that I can see is that they are only allowed since C99[0]. Yes, but C99 was released 20 years ago. Perhaps it's okay to use it nowadays :) Regards, -- David
Re: [dev] Coding style: why /* */ and not //?
One is enough. As it should have been for loop constructs. -- 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] 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
Re: [dev] Coding style: why /* */ and not //?
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).
Re: [dev] Coding style: why /* */ and not //?
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 //?
On Thu, Dec 27, 2018 at 12:56:29AM +1300, 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? > > 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? > > Thanks, > Martin > // is not ANSI. I use /* */ and #if 0 for large blocks containing nested /* */ myself. -- # Kind regards,
Re: [dev] Coding style: why /* */ and not //?
On Thu, Dec 27, 2018 at 12:56:29AM +1300, Martin Tournoij wrote: > ... AFAIK all compilers accept // these days ... Preprocessor. I guess having 2 ways to define comments is not significant, then better stick to one and the historical one. -- Sylvain
