why does this crash?

This is a discussion on why does this crash? within the C++ Programming forums, part of the General Programming Boards category; Fair enough, let's leave the actual applications out of this Command line may be faster, but the GUI certainly isn't ...

  1. #46
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,182
    Fair enough, let's leave the actual applications out of this
    Command line may be faster, but the GUI certainly isn't slow either...
    How about... you have a folder of image files named year-month-day.jpg (2008-05-22.jpg) that is a snapshot of your aquarium on that day.
    Then you realized that every year in May, all fishes are sleeping, and there is no point keeping those snapshots, so you want to delete all the files in May. How would you do that?
    I would do
    Code:
    rm *-05-*
    Sure, but it took time to develop the rm command when it first was created.
    Yes, and it was >20 years ago, and GUI programs haven't caught up to that kind of flexibility yet.

    They're all lazy bastards and don't realize the the gain of doing this :|
    That is a very noble undertaking. Very courageous of you, Elysia. =)

    Pretty solution, though? Hardly. I think not.
    Of course there is a limit to how complex a script gets. For anything more complicated, we need C++, too. On the other hand, what phantomotap described is certainly doable in CLI, can you say the same for GUI?

    what if you wanted to display the error in german and not english, which the app was written in?
    CLI is not God, there is a limit to what it can do, too =).

    btw, bed time for me =) I will come back tmr. In case you are wondering, I am a high school kid and need to go to school at 8 everyday =).

  2. #47
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    what if you wanted to display the error in german and not english
    Where's the difference between localization in CLI and GUI apps?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #48
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    Of course there is a limit to how complex a script gets.
    No, believe me, there really isn't. I have a good variant of a Bash installed with a supporting cast of about 300 CLI tools. I can redirect input and output to arbitrary named pipes. I can script keyboard and mouse input for a GUI. I can read arbitrary pixels and examine it for any text. I can even script in an interpreted form of C++ if I want.

    Oh, and Elysia, as you try to figure out how a GUI should best emulate the abilities of a CLI tool, consider this: even if you manage a GUI that isn't bloated from the attempt at visually associating all the available options of the CLI tool if you haven't completely emulated the CLI interface I lose flexibility precisely because I can no longer use the tool in scripts.

    Soma

  4. #49
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,545
    Quote Originally Posted by CornedBee View Post
    Where's the difference between localization in CLI and GUI apps?
    If the CLI tool was localized in english and the app that uses it is localized in german, for example, then you don't want the CLI tool to pop up an english dialog with an error - you want the program that uses the tool to do that.

    Quote Originally Posted by phantomotap View Post
    Oh, and Elysia, as you try to figure out how a GUI should best emulate the abilities of a CLI tool, consider this: even if you manage a GUI that isn't bloated from the attempt at visually associating all the available options of the CLI tool if you haven't completely emulated the CLI interface I lose flexibility precisely because I can no longer use the tool in scripts.
    There are solutions to that too... DLL interfaces or using compatible apps to create scripts.
    Or how about just a CLI wrapper tool for the DLL interfaces?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #50
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    You can say so. But it makes us wonder about you ...


    If the CLI tool was localized in english and the app that uses it is localized in german, for example, then you don't want the CLI tool to pop up an english dialog with an error - you want the program that uses the tool to do that.
    Aside from CLI tools not popping up dialogs ...
    So basically you need consistently localized programs or you get a mixture of languages in messages. Well, big deal. That's what you get for having inconsistently localized programs. What do you think happens if I add a non-localized shell extension to a German Explorer? What happens if I add a non-localized add-on to a French Firefox?

    Stop blaming general software development issues on CLIs.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #51
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,545
    Quote Originally Posted by CornedBee View Post
    Stop blaming general software development issues on CLIs.
    I'm not blaming the CLI - it's about how the tool should not prompt, but the program.
    A utility function should (preferably) not display any prompts. It should return an error and the main function should do the prompt.
    That is what I mean. Keep is consistent. There's nothing worse than having a program in one language and get a half-assed translation and dialogs or text appearing in non-localized.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #52
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    There are solutions to that too... DLL interfaces or using compatible apps to create scripts.
    O_o

    If the tool wasn't scriptable, how would a tool to script the other tool exist? (The existence of tools to create a script doesn't alleviate the burden of making the GUI scriptable.)

    No. A shared library is not a solution. A shared library doesn't let me script behavior by virtue of being a shared library. A shared library is simply a way to store an implementation. The implementation must still exist, and if the interface doesn't support the usual scripting methods then it isn't as flexible as the CLI tool might be.

    Or how about just a CLI wrapper tool for the DLL interfaces?
    ^_^

    That would allow the scripting... and I love that you said that; especially after these gems:

    They are good for simple nothings; nothing more.
    CLI intefaces are poor, poor, poor, poor. DLL interfaces are far more flexible.
    Soma

  8. #53
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,545
    Quote Originally Posted by phantomotap View Post
    If the tool wasn't scriptable, how would a tool to script the other tool exist? (The existence of tools to create a script doesn't alleviate the burden of making the GUI scriptable.)

    No. A shared library is not a solution. A shared library doesn't let me script behavior by virtue of being a shared library. A shared library is simply a way to store an implementation. The implementation must still exist, and if the interface doesn't support the usual scripting methods then it isn't as flexible as the CLI tool might be.
    But say the script is in XX format, then a function within a library could allow to "execute" that script, see? Or a program, or whatever. So long as it works.

    ^_^
    That would allow the scripting... and I love that you said that; especially after these gems:
    Hence the "wrapper" part
    It's not by any means the real way to do it - just as a means to make those script makers happy.
    Use it as your own discretion... you're going to miss out on a lot.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #54
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,231
    But say the script is in XX format, then a function within a library could allow to "execute" that script, see? Or a program, or whatever. So long as it works.
    Not quite; by providing only a function that executes a script in scripting language XX you burden me with scripting language XX. If I don't know XX your shared library is useless.

    Again, the beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together. I can use literally hundreds of different languages as glue; regardless of language I bring my knowledge of the tool itself to the table.

    For comparison, my choice of languages is limited with a tool only provided as a shared library. If the shared library is written in C++ with C++ as the interface language, and this is a C++ forum, my choice is extremely limited. I have one option: use the exact compiler version as the distributer. (Before you think to deny this, as I'm sure you want to, research what happened when G++ 3.2 was first released into the wild.)

    t's not by any means the real way to do it - just as a means to make those script makers happy.
    Use it as your own discretion... you're going to miss out on a lot.
    It isn't the way to write a user experience application like a browser. It is the correct approach for user or administrator tools. If a tool can't be scripted with what the user knows its useless. An administrator, even in the Windows world, will not use a tool if he knows that he has to actually be present at the computer to use a GUI every single time the tool is needed.

    We like to script, so we don't have to do repetitive tasks. Computers are alarmingly good at repetitive so give me an interface that lets me make use of this ability.

    Soma

  10. #55
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,182
    No, believe me, there really isn't. I have a good variant of a Bash installed with a supporting cast of about 300 CLI tools. I can redirect input and output to arbitrary named pipes. I can script keyboard and mouse input for a GUI. I can read arbitrary pixels and examine it for any text. I can even script in an interpreted form of C++ if I want.
    Sorry for my ignorance. Linux newbie here =) (~3 years).

  11. #56
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,545
    Quote Originally Posted by phantomotap View Post
    Not quite; by providing only a function that executes a script in scripting language XX you burden me with scripting language XX. If I don't know XX your shared library is useless.

    Again, the beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together. I can use literally hundreds of different languages as glue; regardless of language I bring my knowledge of the tool itself to the table.

    For comparison, my choice of languages is limited with a tool only provided as a shared library. If the shared library is written in C++ with C++ as the interface language, and this is a C++ forum, my choice is extremely limited. I have one option: use the exact compiler version as the distributer. (Before you think to deny this, as I'm sure you want to, research what happened when G++ 3.2 was first released into the wild.)

    It isn't the way to write a user experience application like a browser. It is the correct approach for user or administrator tools. If a tool can't be scripted with what the user knows its useless. An administrator, even in the Windows world, will not use a tool if he knows that he has to actually be present at the computer to use a GUI every single time the tool is needed.

    We like to script, so we don't have to do repetitive tasks. Computers are alarmingly good at repetitive so give me an interface that lets me make use of this ability.

    Soma
    Ah well, what can I say?
    I'll just let CLI win (for now ).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 4 of 4 FirstFirst 1234
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Hooking Crash?
    By Elysia in forum Windows Programming
    Replies: 9
    Last Post: 03-15-2008, 01:13 PM
  2. Can not debug a crash
    By hannibar in forum Windows Programming
    Replies: 2
    Last Post: 06-30-2007, 10:02 AM
  3. Dynamic array sizing causes crash
    By Mithoric in forum C++ Programming
    Replies: 3
    Last Post: 12-30-2003, 06:46 AM
  4. FYI: asctime(gmtime(&mytime)) = crash!
    By anonytmouse in forum C Programming
    Replies: 2
    Last Post: 09-29-2003, 02:24 AM
  5. Crash after crash!
    By Dual-Catfish in forum C++ Programming
    Replies: 1
    Last Post: 03-31-2002, 08:32 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21