Re: Any plans to remove obsolescent features?


"Wojtek Lerch" <wojtek_l@xxxxxxxx> wrote in message
news:7mh98oF3ho6jcU1@xxxxxxxxxxxxxxxxxxxxx
"BGB / cr88192" <cr88192@xxxxxxxxxxx> wrote in message
news:hdv5ri$49d$1@xxxxxxxxxxxxxxxxxxxx

"Wojtek Lerch" <wojtek_l@xxxxxxxx> wrote in message
news:7mgbo7Fq00suU1@xxxxxxxxxxxxxxxxxxxxx
"Flash Gordon" <smap@xxxxxxxxxxxxxxxxx> wrote in message
news:0c7bt6x0ei.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxx
I think it is about time to remove some of the things which were
deprecated in 1989 at least. I agree with the poster who suggested
making an empty parameter list mean no parameters (void) rather than an
unspecified number of parameters.

I think it would be wiser to do it in two steps -- make it a syntax
error first, and then re-introduce it with the new meaning in the next
version of the standard. This would give compilers a few years of
freedom to choose whether to support the old semantics or the new as an
extension.


I disagree...

since, as I see it, "()" has 2 meanings at the same time:
"()" as an empty list (implicit, but common);

Do you mean common outside of C, or commonly misinterpreted in C?


it is "implicitly valid" as a grace of what it does mean:
a function can be declared with "()";
a function can be called with "()";
the compliler does what is expected.


"()" as an arbitrary number (official, but uncommon).

I remember it being fairly common. Before ANSI C it was the only way to
declare a fuction in C.


not now.
anymore, if a person types "()", almost invariably they mean an empty list.


there is a very large amount of code which uses the former definition,
but

Again, in C??? Or in C++, Java, etc?


in C...

one does not have to look far and wide to find it, it is infact far more
common in the code I have seen than the use of "(void)".


almost no code I have seen which (intentionally) uses the latter
(although, programmers may sometimes stumble across it on accident, and
then end up assuming it to be some kind of compiler bug...).

What do you call people who actually understand the tools that they're
using? "Professional programmers", as opposed to just "programmers"? ;-)


programmers are programmers, some know some of this trivia, some don't know
but this does not hinder them from "getting the job done", some know and
don't care, ...


the former case is implicitly contained in the latter, where the former
is the common understanding and usage, and the latter is what is
officially in the standard.

Well my experience of what is "common" seems to differ from yours.


probably, may depend some on which code and which communities one is exposed
to.

checking around in random code from random projects, it seems it is not as
clear-cut as I had thought:
I encountered several projects using '(void)', some using '()', and a few
using K&R style declarations (actually, I had seen code alternative between
K&R and more modern style as well).

I guess I was slightly off, as it does appear for pure C codebases (and not
mixed C and C++ codebases), '(void)' would seem to hold a majority position,
but both styles would seem to be in use in general.



so, FWIW, it would be more a matter of deprecating a "bug" than of
introducing (conceptually) new semantics.

Apparently my definition of "bug" differs from yours as well.


it may resemble a bug, if it happens unexpectedly, granted it is not
technically a bug as such.


if compilers were to make "()" a syntax error, OTOH, a rather large
amount of code would break, so much so that likely almost no compiler
project/vendor would likely consider doing so (it is worth noting that
the general adoption of the "(void)" convention has been rather sparse
IME, and personally I don't feel it to be the right direction either,
...).

I didn't say that compilers would have to reject "()" as a syntax error;
on the contrary, I did talk about letting them interpret "()" either the
old way or the new way, as an extension. Just like compilers can still
support implicit int even though it was removed in C99. A lot of
extensions look like syntax errors to the standard; many of them (like
"long long" or "for (int i=0;;)") become part of another version of the
standard.


yes, ok.


my compiler interprets "()" as an empty list, as well as failing to parse
implicit int or K&R style syntax. among other issues, it is not strictly
standards-conformant, but it works well enough for my uses at present
(granted, "making it ready for prime time" would probably require a bit of
fixing up in the edge cases...).

sadly, my projects as a whole have gotten larger than I can really manage
effectively, and so it is difficult to prevent "rust", and often bugs are
not fixed unless I start beating head-first into them.

(doesn't help here that I am the only developer here...).

sadly, resolving this issue would probably require cutting off a lot of code
and persuing more agressive "anti-bloat" practices, but even this would
require a lot of time and effort resources.

for now though, it all just continues as-is...


it is not all bad though, as it helps give one a better perspective on "the
industry" in general, and helps one learn how to utilize their coding
efforts a little more efficiently (getting bigger effects with less code,
such as how to get by with generalizing or re-purposing existing code and
facilities to support new tasks, rather than always writing new code, ...).

but, alas, still much more new code ends up written, ... so, really, I don't
know what the eventual outcome of all this will be.



.

Relevant Pages

  • Re: Segmentation Fault....
    ... actual applicable standard, but not until then. ... Under windows several compilers are available. ... The missing features in C++ implementations tend to be common across the ... actually find out there: C90. ...
    (comp.lang.c)
  • Re: If you were inventing CoBOL...
    ... *because* the Standard *requires* that a continued ... can cause serious problems for many Windows and Unix compilers. ... Which is most common - I would think ... > and my mainframe experience is over 25 years out-of-date. ...
    (comp.lang.cobol)
  • Re: Any plans to remove obsolescent features?
    ... and then re-introduce it with the new meaning in the next version of the standard. ... This would give compilers a few years of freedom to choose whether to support the old semantics or the new as an extension. ... I remember it being fairly common. ...
    (comp.std.c)
  • Re: Common --- question
    ... Been a while since I've used common much though. ... But compilers have to handle at least all the legal ... Aligning "everything" on 8-byte boundaries isn't going to work ... them to do common according to the standard or with decent performance. ...
    (comp.lang.fortran)
  • Re: In answer to RW - again (was: Sorts (revised)
    ... >> All communication requires the sender and receiver to share a common ... > - some environments ... work the same on compilers I'm likely to encounter -- Micro Focus, IBM, Fujitsu ... works the same on MF, IBM and Fujitsu, that's a universal truth in my universe. ...
    (comp.lang.cobol)