Do header files really serve a useful purpose?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • E. Robert Tisdale

    #16
    Re: Do header files really serve a useful purpose?

    Hattuari wrote:
    [color=blue]
    > So in that sense, I will ask what good header files really are.[/color]

    When properly constructed,
    they serve the same purpose as modules
    or module interfaces in other languages.

    Comment

    • Julie J.

      #17
      Re: Do header files really serve a useful purpose?

      Interchanging would be a piece of cake -- there are plenty of methods out there
      for centralized databases to a remote client.

      Merges would go the way of the west as well...

      Gary wrote:[color=blue]
      >
      > "Julie J." <unlisted@.> wrote in message news:403E7A78.C 0F60D24@....[color=green]
      > > Header files (and in fact source! files) are a complete waste and 100% the
      > > wrong way to write code.
      > >
      > > File-based source is an artifact (unfortunately long-lasting) from the[/color]
      > 50's and[color=green]
      > > 60's, and was a step up from punch cards.
      > >
      > > 40+ years later, we are still using this IMMENSELY outdated mode of[/color]
      > writing[color=green]
      > > code.
      > >
      > > The truth of the matter is that there should be *NO* files, but code[/color]
      > should be[color=green]
      > > just written in an editor, and stored in an abstract container (such as a
      > > database). The (header) definition/declaration model is a holdover from[/color]
      > the[color=green]
      > > ancient past of functional C.[/color]
      >
      > True, in many respects, but also adds the requirement that to do any editing
      > or compiling would require the action of a database engine.
      > Maybe not a bad thing since many of us use rather large IDE's for
      > development, but interchanging programs with other developers might become a
      > burden. Either they have to have the same engine or we have to export/import
      > all the time. Sending plain text cpp files still seems easier.
      >
      > Look at all the export, scan, import, scan, intermediate files, and
      > interpreters needed to use the "modern" way of interchanging data: XML.
      > Would it be the same with database C++ system? Probably.
      > --
      > Gary[/color]

      Comment

      • Julie J.

        #18
        Re: Do header files really serve a useful purpose?

        > No offense, but discussions of this nature rank right up there with "there[color=blue]
        > should be peace on earth", "every day should be a Saturday", and "William
        > Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but pure
        > flights of fancy.[/color]

        Says you.

        I'm sure that the punch-carders felt the same way that you do about new-fangled
        text files. You are entitled to your opinion, but that doesn't obviate the
        need for a better solution to code development and management than text files.

        Claudio Puviani wrote:[color=blue]
        >
        > "Julie J." <unlisted@.> wrote[color=green]
        > > Header files (and in fact source! files) are a complete waste and 100% the
        > > wrong way to write code.
        > >
        > > File-based source is an artifact (unfortunately long-lasting) from the 50's[/color]
        > and[color=green]
        > > 60's, and was a step up from punch cards.
        > >
        > > 40+ years later, we are still using this IMMENSELY outdated mode of writing
        > > code.
        > >
        > > The truth of the matter is that there should be *NO* files, but code should be
        > > just written in an editor, and stored in an abstract container (such as a
        > > database). The (header) definition/declaration model is a holdover from the
        > > ancient past of functional C.
        > >
        > > Long compiles would be a thing of the past, immediate access to symbols,[/color]
        > types,[color=green]
        > > functions, classe, etc. would be available in the editor. Everything could be
        > > optimized for the compile/build, and could occur incrementally as code is
        > > written and committed.
        > >
        > > I'm amazed that new language after new language continues to use the bad old
        > > plain old regular text file and the basis for code entry and maintenance. I
        > > thought that IBM was working on some database-based model back in the early
        > > 90's, but I guess it never materialized.
        > >
        > > Too bad -- writing code can be more of an exercise of managing files (and and
        > > inclusions), than actually *writing* the code...[/color]
        >
        > I, for one, would avoid a "language" that forced me to store my code in a
        > database that's hidden behind some GUI. Anyone who's worked with such tools as
        > Rational Rose or systems like Actor can tell you how frustratingly constraining
        > that approach can be.
        >
        > Being able to manage the code as plain text files is a strength, once you're
        > used to it, not a weakness. You not only have access to hundreds of utilities to
        > do just about everything, but you get to choose which ones you want to use. With
        > database approach, you're stuck with whatever the compiler vendor provides. Even
        > if a common set of tools eventually surfaced, it would take years for such tools
        > to approach the versatility of things like Perl or your favorite
        > (non-database-enabled) editor, and even then, you'd only have limited
        > functionality.
        >
        > As to the C++ model being obsolete, that may well fuel hours of theoretical
        > discussions, but the reality is that C++ does what it purports to do
        > spectacularly well and it's highly doubtful that many people would migrate from
        > C++ to some hypothetical pretty replacement just because it would satisfy some
        > abstract esthetics. There are already quite a few languages out there that "fix"
        > these esthetic irritants, yet I'm not seeing a mass exodus toward them.
        >
        > No offense, but discussions of this nature rank right up there with "there
        > should be peace on earth", "every day should be a Saturday", and "William
        > Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but pure
        > flights of fancy.
        >
        > Claudio Puviani[/color]

        Comment

        • Chris Mantoulidis

          #19
          Re: Do header files really serve a useful purpose?

          "Gary" <glabowitz@comc ast.net> wrote in message news:<FZGdnUQkY _6Mt6PdRVn-tw@comcast.com> ...[color=blue]
          > "Chris Mantoulidis" <cmad_x@yahoo.c om> wrote in message
          > news:a8587dd9.0 402260853.5d41c 56d@posting.goo gle.com...[color=green]
          > > Oh I sence a little flame :P[/color]
          > <<snip>>[color=green]
          > > Pascal's synonym for "header file" is "unit". Java's synonym for
          > > "header file" is something I can't remember atm :P (but you include it
          > > in your code with import NAME). C's "header files" synonym is "header
          > > files".[/color]
          >
          > Just a nit. Java has nothing like #include. The import statement is not the
          > Java equivalent of #include.[/color]

          I'm sorry, I don't really know Java; just seen code parts :) But you
          get the central idea :)

          Comment

          • Claudio Puviani

            #20
            Re: Do header files really serve a useful purpose?

            "Julie J." <unlisted@.> wrote[color=blue][color=green]
            > > No offense, but discussions of this nature rank right up there with "there
            > > should be peace on earth", "every day should be a Saturday", and "William
            > > Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but[/color][/color]
            pure[color=blue][color=green]
            > > flights of fancy.[/color]
            >
            > Says you.
            >
            > I'm sure that the punch-carders felt the same way that you do about[/color]
            new-fangled[color=blue]
            > text files. You are entitled to your opinion, but that doesn't obviate the
            > need for a better solution to code development and management than text files.[/color]

            My point is that such "improvemen ts" -- and the term is very subjective -- have
            nothing to do with C++ and discussing them in the context of C++ is irrelevant.
            I'm sure that you can't possibly have illusions that C++ will some day become
            repository-based to the exclusion of files. Can some future language do that?
            Sure. Along with many other niceties that theoretical linguists out there yearn
            for. Wishing for C++ to become that language is, as I've said before, pure
            flight of fancy.

            As to your recurring comparison with punched cards, that's a total non sequitur.
            Punched cards weren't a way to structure code. They were just an archaic way to
            represent -- you guessed it -- files and streams. A slightly more appropriate
            comparison would be the move from command-line interfaces to GUIs. For years,
            the residents of the proverbial ivory tower predicted the demise of CLI's
            because they were "obsolete", "too complicated", "not elegant enough". Yet, even
            the knights protector of GUI -- Windows and the Macintosh -- still offers a CLI
            because GUIs simply can't offer the same versatility and fine-grained control.

            Claudio Puviani


            Comment

            • Julie J.

              #21
              Re: Do header files really serve a useful purpose?

              > the knights protector of GUI -- Windows and the Macintosh -- still offers a CLI[color=blue]
              > because GUIs simply can't offer the same versatility and fine-grained control.[/color]

              CLIs exist because of the need for automated/scripted/remote builds, not
              because they offer more control than the GUI interface.

              Claudio Puviani wrote:[color=blue]
              >
              > "Julie J." <unlisted@.> wrote[color=green][color=darkred]
              > > > No offense, but discussions of this nature rank right up there with "there
              > > > should be peace on earth", "every day should be a Saturday", and "William
              > > > Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but[/color][/color]
              > pure[color=green][color=darkred]
              > > > flights of fancy.[/color]
              > >
              > > Says you.
              > >
              > > I'm sure that the punch-carders felt the same way that you do about[/color]
              > new-fangled[color=green]
              > > text files. You are entitled to your opinion, but that doesn't obviate the
              > > need for a better solution to code development and management than text files.[/color]
              >
              > My point is that such "improvemen ts" -- and the term is very subjective -- have
              > nothing to do with C++ and discussing them in the context of C++ is irrelevant.
              > I'm sure that you can't possibly have illusions that C++ will some day become
              > repository-based to the exclusion of files. Can some future language do that?
              > Sure. Along with many other niceties that theoretical linguists out there yearn
              > for. Wishing for C++ to become that language is, as I've said before, pure
              > flight of fancy.
              >
              > As to your recurring comparison with punched cards, that's a total non sequitur.
              > Punched cards weren't a way to structure code. They were just an archaic way to
              > represent -- you guessed it -- files and streams. A slightly more appropriate
              > comparison would be the move from command-line interfaces to GUIs. For years,
              > the residents of the proverbial ivory tower predicted the demise of CLI's
              > because they were "obsolete", "too complicated", "not elegant enough". Yet, even
              > the knights protector of GUI -- Windows and the Macintosh -- still offers a CLI
              > because GUIs simply can't offer the same versatility and fine-grained control.
              >
              > Claudio Puviani[/color]

              Comment

              • Claudio Puviani

                #22
                Re: Do header files really serve a useful purpose?

                "Julie J." <unlisted@.> wrote[color=blue][color=green]
                > > the knights protector of GUI -- Windows and the Macintosh -- still offers a[/color][/color]
                CLI[color=blue][color=green]
                > > because GUIs simply can't offer the same versatility and fine-grained[/color][/color]
                control.[color=blue]
                >
                > CLIs exist because of the need for automated/scripted/remote builds, not
                > because they offer more control than the GUI interface.[/color]

                Doh. Automated/scripted/remote -- not to mention chained and parametrised --
                tasks (not just builds) are precisely the kind of versatility and control that
                you don't get from a GUI. Given your arguments, I'm beginning to question how
                long you've been using development tools and on how many platforms.

                Claudio Puviani


                Comment

                Working...