• @[email protected]
    link
    fedilink
    41 year ago

    Basically every program that deals with some form of user input will come across strings. Be it to print something to the screen, write something to a file, read something from a file, read something from the user interface (even if it’s stdin). Even most non-user-facing tools (daemons, drivers, etc) have to deal with strings often enough, even if “just” for something like writing log or debug entries.

    For me it’s hard to come up with any application where I don’t need strings sooner or later. Typically sooner than later.

    • @INeedMana
      link
      11 year ago

      But this is high level. You shouldn’t rely on strings or user input down in the mission critical part of the program

      • @[email protected]
        link
        fedilink
        11 year ago

        Do you separate that? I mean if the idea is to use C only outside of user interaction, then maybe. But is this a realistic scenario? If I write my whole application/library in C, user interaction is part of the application nonetheless. Maybe not what you consider “mission critical” from a program-reliability standpoint. But still mission critical from a user-experience standpoint. Because the whole application is worthless, if it cannot be used.

        • @INeedMana
          link
          21 year ago

          If I write my whole application/library in C, user interaction is part of the application nonetheless

          That’s my point. Human facing interface needs a lot of code that does not really do much, only needs to be there to cover all the edge cases of mixed parameters, cancel buttons, trying to click “next” without filling important textbox… And writing all this in C (I mean the actual user-end program interface, not the general GUI library, like GTK for example) only makes it worse to debug and maintain. You most often don’t get any gain from manual memory management. If an operation is taking too long maybe it’s time to put it inside the backend library. But if you’re optimizing that operation you’ve already moved away from comparing strings inside - it’s the first one to go when a loop takes too long. And once we are speaking about more than one program that we want to have consistent behavior across that might need to change in the future - C is only slowing you down.
          Do you really need to reference the “Cancel” button via pointer when checking if the user should be allowed to go back?

          Write a general backend library for your important stuff and optimizations in C, so you can easily load it in other languages. And then use something higher level for the interpreter/GUI where sanitizing user input is 5 lines of different libraries from the language (I mean like re or zip in Python - these are not external, these are Python’s STL), instead of 50 lines of juggling pointers, which in C you would be doing even if the input was all ints.

          You don’t care about stack height and jumping to previous frame after being in a procedure (assembler level of looking at the code) - that’s what C does for you
          So why care about the pointers and structs when resizing a GUI? - Let some higher level language manage that for you