On 24.09.2017 23:03, Branko Čibej wrote:
> On 24.09.2017 22:05, Daniel Shahaf wrote:
>> Branko Čibej wrote on Sun, 24 Sep 2017 21:56 +0200:
>>> What /I/ don't understand is why we're even having a discussion about
>>> using // comments. Is it really that hard to type two extra chars per
>>> comment, especially since any sane programming editor will add the
>>> delimiters in for you anyway?
>>>
>>> If the discussion were about more interesting features such as
>>> *restrict*ed pointers or mixed statements and variable declaration or
>>> *for*-scope variable declarations, that'd make some sense. But talking
>>> about just "C90 + //" is, IMO, a waste of time.
>> About //-comments specifically, my thinking was that if we supported such
>> comments we wouldn't run into "//-comments v. /**/-comments" conflicts
>> when updating our embedded utf8proc.
>
> Given what that merge looked like, the // comments were a minor issue :D
> The whole discussion grew out of all proportion because I thought I
> could leave the comments in and instead tell compilers to be smart about
> them.
>
>
>> But to your wider point, I agree, //-comments aren't _the_ most
>> pressing C99 feature we might wish to adopt. I was just trying to take
>> a "one step at a time" approach. So, can we switch from C89 to C89 +
>> any single C99 feature? E.g., C89 + <one of the features you just named>.
>
> The problem with the feature cherry-picking approach is that we don't
> have a reliable way for compilers to warn about when /other/ features
> except the blessed ones appear in the code.
>
> If we want to take the Great Leap Forward, I'd prefer to just move to
> C99 lock, stock and barrel instead. That would likely cause problems to
> some of our downstream users, however.
I fully agree with Brane on this.
Another thing that has popped up in the past and that I, personally,
would love to see happening is supporting C++ inside our libs. I think
that would have it made easier to me, using wrapper classes / templates
with appropriate operator overloading, to migrate code from one API /
data structure to another.
However, that move too, would create all sorts of compatibility issues
with rules to address them and all for a limited increase in coding
convenience.
-- Stefan^2.
Received on 2017-10-01 11:17:25 CEST