Syntax for union parameter

Discussion in 'C Programming' started by Rick C. Hodgin, Jan 29, 2014.

  1. Rick C. Hodgin

    BartC Guest

    No. The forward declarations, /in C as it is now/, seem to like being at the
    beginning. In C as it could be, they are not really needed (actually I'm not
    sure why they are needed now, for functions within the same file).

    OK. Forget everything that's been said so far.

    Is is possible to tweak C so that function declarations, separate from
    definitions, can be eliminated? That is, so that a programmer writes just
    the definition, and that's it?

    I'm not sure if you're saying yes or no. Obviously no as C now is, but I'm
    saying it's possible and so was Rick.
     
    BartC, Jan 29, 2014
    #81
    1. Advertisements

  2. Rick C. Hodgin

    BartC Guest

    That's the same claim I'm trying to make (and not really succeeding). But
    I've also done it. My approach however is not to eliminate the conventional
    declarations that are needed, but to generate them automatically. You get
    the same advantage in only having to write the definition.
    Yes, it's necessary to first compile the file that contains the functions
    that will be used in another, but so what? They must be compiled at some
    point! Although the bodies can initially be empty. But that is only my
    approach, there are many ways to do this.

    And if you have a file A that is using some functions in file B, and the two
    are remote, written by different people, etc, then file B needs to be
    compiled, or have something done to it, to yield the information needed by A
    (as I do it, the special processing yields the file B.h that can be
    distributed to the owner of A; the source remains private.)

    The important thing is that it works; I've hardly written a separate
    declaration, in real code, since about 2012.
     
    BartC, Jan 29, 2014
    #82
    1. Advertisements

  3. I'll go for that.
    I'm saying no. Not that there is no conceivable language that does not
    have them, but that anything that is to fit the same sort of niche as C
    needs something like it. In such a language, if you want to use an
    external function whose code is not available, something is needed to
    tell the implementation how to type-check the call.

    Languages like B and BCPL get away without these "typed declarations"
    simply because they have no type checking. Some languages with run-time
    types get away with it for a similar reason but they can be type-safe
    none the less. A language that is at all C-like (no run-time types, but
    with a useful amount of type checking) needs something to work with.
     
    Ben Bacarisse, Jan 30, 2014
    #83
  4. Rick C. Hodgin

    BartC Guest

    (I spent 25 years doing this! Striving to keep duplicate declarations of
    thousands of functions up to date with each other. There must be a better
    way.)

    Yes, it's crazy.
    Now you're getting it. I've been using such tools of my own for the last
    year and a half, and they work great. (The tools also tweak the syntax, but
    that's just my preference.)
    You mean, sorting 700 functions in a file according to their calling
    hierarchy? Yes, sure! If people have clever IDEs that can take care of those
    details, that's fine, but then everyone is in reality using the their own
    ad-hoc extensions, rather than evolving the base language in useful ways.
     
    BartC, Jan 30, 2014
    #84
  5. Rick C. Hodgin

    BartC Guest

    My reply to James (29/01/2014 23:58, but that might be GMT) explains a
    different way how I try and do it, and still provide full type-checking.
     
    BartC, Jan 30, 2014
    #85
  6. Yes. My code was in a .cpp file, so it was passed over by the compiler.
    My mistake.
    My point is that *I'M* doing this work, rather than the compiler
    generating any such files for me.
    That is what had happened for some time (months).
    I did follow the convention, but the Visual C++ compiler compiling
    my code does not reconcile mismatched function declarations in .h
    and .cpp files.
    This seems to only be true in a .c file. I tested this when I got home
    writing these two files:

    -----tst.h-----
    #include <stdio.h>
    #include <stdlib.h>

    int foo(int a);
    ------end------

    -----tst.c-----
    #include "tst.h"

    int main(int argc, char* argv[])
    {
    printf("Hi, mom!\n");
    return(0);
    }

    int foo(float a)
    {
    printf("%f\n", a);
    }
    ------end------

    Using "gcc tst.c" it reported these errors:
    tst.c:9:5: error: conflicting types for 'foo'
    In file included from tst.c:1:0:
    tst.h:6:5: note: previous declaration of 'foo' was here

    Using the same source files, but renaming tst.c to tst.cpp, and
    using "g++ tst.cpp" it compiles without error.

    I again apologize for my ignorance with regards to what is C and
    what is C++, or what is a C standard, and what is an extension
    as per Microsoft's extensions in Visual C++.

    Best regards,
    Rick C. Hodgin
     
    Rick C. Hodgin, Jan 30, 2014
    #86
  7. Rick C. Hodgin

    Ian Collins Guest

    Well if you will insist on using a C++ compiler, you can't complain
    about deficiencies in C...
    That wouldn't have happened if you'd written tests first!
    Because it's using the C++ rules for function overloading.

    If you are going to be compiling with a C++ compiler, you really should
    become familiar with the differences between the two languages.
    Double check with a C compiler in conforming mode, or read the standards!
     
    Ian Collins, Jan 30, 2014
    #87
  8. On the contrary ... I can most certainly complain about deficiencies
    in C ... just not for those reasons. :)
    It also wouldn't have happened if there were no need for forward
    prototypes.
    Agreed. :)
    I don't care to learn such things. It's a bunch of learning about...
    whatever... and with RDC I am taking features I like from both and
    bringing them together ... so it would be counter-productive.
    No thanks. Too much work for nothing valuable in return. I can simply
    write code and let the compiler authors worry about such things. When
    I encounter a problem, then I can correct it, code around it, or do a
    search at that time to figure out the cause. :)

    Not having forward prototypes still would've prevented this problem.

    Best regards,
    Rick C. Hodgin
     
    Rick C. Hodgin, Jan 30, 2014
    #88
  9. Is it possible? I suppose so.

    Within a single source file, a compiler could perform two passes over
    the source, collecting function declarations on the first pass and
    doing normal compilation on the second (or some variant of that).
    Just as a feasibility demonstration, the first pass could generate
    function declarations, write them to a temporary file, and then
    copy the source to the end of the temporary file; the second pass
    could be an ordinary C compiler applied to the temporary file.
    No doubt there are more efficient ways to do the same thing.

    The problem is separate compilation. Suppose I want to use a
    function defined in some library, say mpz_init() (which happens to be
    part of the GNU multiprecision arithmetic library). The definition
    of mpz_init is in some source file. You suggest not having a
    separate declaration anywhere.

    Currently, if I want to write code that calls mpz_init(), all I
    need are the library that implements it (say, libgmp.so or libgmp.a)
    and the header file that declares it (say, /usr/include/gmp.h).

    In your scheme, how does the compiler know how the function
    is declared? Do I have to have a copy of the full source file?
    C is carefully designed to avoid that need. (In the case of GMP,
    it's merely a convenience; in the case of non-free / non-open-source
    software, it's potentially critical.)

    And if the declaration defining the interface to the function exists
    only in the source file that defines it, and I update some minor
    detail of the implementation, how will my build system know that
    the interface hasn't actually changed and all my client code doesn't
    need to be recompiled? I suppose that *could* be done by some tool
    that keeps track of whether a given change to the source file changed
    the interface in some significant way, but keeping declarations and
    definitions in separate files is a much easier way to manage that.
     
    Keith Thompson, Jan 30, 2014
    #89
  10. Well there's your problem. .cpp is the conventional suffix for a C++
    source file, not a C source file. (If you're interested, comp.lang.c++
    is down the hall on the left, just past the water cooler.)

    [...]
    That's to be expected.

    In C, these functions:
    int foo(int a);
    and
    int foo(float a);
    cannot coexist in the same program (unless they're static).

    In C++, they can simply be two distinct functions. It's called
    overloading. In C++, it's not a mismatch.

    If you had followed the conventions I described earlier *and compiled
    your C source code as C*, then the compiler would have diagnosed the
    mismatch.

    (Just curious: if you're trying to write C code, why would you give the
    source file a .cpp suffix?)
     
    Keith Thompson, Jan 30, 2014
    #90
  11. When I began this project (writing Visual FreePro) in 2009, it was in C++.
    I later decided to switch back to C because I wanted to pursue my goals of
    the RDC toolchain as part of that project. From 2009 through 2012 I was
    planning on C++. After that I have been planning on RDC.

    RDC will have some aspect of C++, including some aspects of the class.
    But it will not be fully C++. It will be much more C-like using some
    C++ syntax.

    Best regards,
    Rick C. Hodgin
     
    Rick C. Hodgin, Jan 30, 2014
    #91
  12. Rick C. Hodgin

    James Kuyper Guest

    Nothing stops you from complaining about anything you want; but
    complaining about non-existent problem with C that's due to the fact
    that you actually compiled the code with a correctly working C++
    compiler makes you look ridiculous.

    C, C++, and RDC are three different languages. When what you're saying
    is really about C, it's fine to post it here. But if you're actually
    talking about C++, the more appropriate place is comp.lang.c++ (or for a
    better signal-to-noise ratio, comp.lang.c++.moderated). Someone else has
    already told you the appropriate location for discussing RDC.

    ....
    Learning more about particular languages - well-established and popular
    languages - that you are deliberately borrowing features from while
    creating you own language - would be counter-productive? I think you're
    measuring your productivity incorrectly.
     
    James Kuyper, Jan 30, 2014
    #92
  13. Rick C. Hodgin

    James Kuyper Guest

    Putting 700 functions in a single file was probably a mistake; even
    putting 700 lines in a single file is often a mistake. When you only
    define a reasonable number of functions per file, sorting them by their
    calling hierarchy is no big deal.
     
    James Kuyper, Jan 30, 2014
    #93
  14. Rick C. Hodgin

    Geoff Guest

    It's really great that you are building a compiler that's a little
    like C and a little like C++ and you have no real understanding of the
    formal specifications of either of those languages and that you can
    base all your knowledge of "C and C++" on Visual Studio, a compiler
    that is deliberately stuck at C'89 and nowhere near C++'11. I'm sure
    your compiler will benefit from it.
     
    Geoff, Jan 30, 2014
    #94
  15. Rick C. Hodgin

    Kaz Kylheku Guest

    Why would I use this RDC, when its author is willfully ignorant about workign
    out the difference between C and C++, or what is dialect and what is standard?
    What does that even mean, "let the compiler authors worry about such things"?

    Are you planning on sending your code to the compiler authors to fix?

    A sentence in the form "let person X worry about Y" generally indicates
    that the speaker is passing responsibility to X; X is expected to take
    some action, to resolve problems related to Y.

    What is it that the compiler writers worry about, and how does it help you,
    if you don't care to look at the documents that their work is based on?
    I mean, whether they do something right, or wrong, by their design or
    by the spec, you can't possibly care, because you choose not to know.
    You choose not to know whether something you coded works by design or accident.

    Now, a compiler author is what you're trying to be, with this RDC, right?

    Aren't you going to have a an accurate, complete reference manual for RDC that
    is kept up to date with every public release?

    Or will you expect your users to program by trial-and-error, as you do,
    and to "port" their programs to each release of RDC by trial-and-error?

    When someone reports a behavior (in particular, a change in behavior), by what
    method will you determine whether it is a bug, or whether it is an invalid
    report?

    Not having a precise, standard-like document will let you just wave your hands
    and say, "well, that was never written down anywhere, too bad for you!"

    Or maybe the user really is wrong, but to provide good support, you will just
    cave in and make the stupid behavior work again, not being able to point to the
    any precise requirement spec which makes it right or wrong.

    Are you sure you can do a good job specifying a programming language, if you
    don't bother reading such documents written by others? And where will the
    motivation come from to write specs, if you don't read such twaddle?
     
    Kaz Kylheku, Jan 30, 2014
    #95
  16. Rick C. Hodgin

    Kaz Kylheku Guest

    Pop quiz.

    Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.

    After the execution of a = a[i++], what should be the values in a[]?

    Why?
     
    Kaz Kylheku, Jan 30, 2014
    #96
  17. Well, that is what lint was supposed to do. If you ran it often
    enough, it would find all those bugs. Of course no-one ran it
    quite often enough.
    Being used to Fortran 66 before C, I wasn't surprised at all.
    Yes they do make some bugs harder. Still, I remember when they were
    new, and I added them to my program, at which point it failed.

    I believe related to function arguments of type float.
    Maybe for programs that are less than 10 lines long.

    -- glen
     
    glen herrmannsfeldt, Jan 30, 2014
    #97
  18. Rick C. Hodgin

    BartC Guest

    No, I'm suggesting not having to sit down and write the separate declaration
    yourself; it would be automatic.
    Sure; for a system which is very close to C, or which is implemented on top
    of current C (C99, C11 etc) the header file would still exist, it's just
    that *no-one has to manually create it*.

    I mean, it can't be the most difficult programming task to scan a .c source
    file, pick up the function declarations that are exported (the ones without
    a static attribute), and write out those declarations to a .h file, but
    sticking a ";" at the end of each instead of having "{" there.
    Because gmp.h will be distributed by the writers/maintainers of the library.
    If the source changes, then they provide a new gmp.h, and a new binary. Of
    course, since it is an external library, you will have no knowledge of
    exactly how that gmp.h file came into existence, and will not care. (And for
    all you know, perhaps various tools have already been used to put it
    together.)

    (A scheme as I've suggested works best where source modules have a simple
    dependency tree, as happens when you have external libraries which are not
    going to directly call your code. It doesn't work well when module A calls
    functions in B, and module B calls functions in A.

    Also, if there are changes to many modules at the same time, then you might
    need to be careful in which order they are compiled, although this can be
    also be automated. So there are some difficulties, but as I said elsewhere,
    since I implemented my scheme in 2012, I can hardly remember having to worry
    about prototypes in headers.)
    When you recompile a module, it updates the associated header file.
    No, it isn't. Easier to implement perhaps, but then the onus is on somebody
    (you or me) to make sure the declarations correctly track any changes in the
    definition file.
     
    BartC, Jan 30, 2014
    #98
  19. Rick C. Hodgin

    BartC Guest

    OK, not 700, but it could be any number. Looking at some of my code, one
    file has 276 functions (because it depends heavily on inlining), although
    they rarely call each other.

    Another has 80, most with names that start with the same three letters. And
    when I'm editing one function, I have no idea where it is located in
    relation to any of the others. And I shouldn't need to know (C is supposed
    to free-format).

    I could write a better editor, but wouldn't it be better to just fix the
    language? Certainly, there is no reason in 2014 for separate local function
    forward prototype declarations (just to make it clear what I mean!) to be
    necessary.
     
    BartC, Jan 30, 2014
    #99
  20. Rick C. Hodgin

    BartC Guest

    Probably a good thing. I read that writing a C++ compiler requires ten
    man-years of effort (and an Ada one apparently fifty years(!)).
     
    BartC, Jan 30, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.