Printable View
this compiles but crashes! i cant find my mistake (this is the entire code so far)
ps: it gives no error code, just opens and close instantlyCode:#include <iostream>
#include <vector>
using namespace std;
int main(){
vector<int> list;
int counter,temp;
do{
cout<<"Please enter a list of number, -1 to quit"<<endl;
cin>>temp;
list.push_back(temp);
}while(temp!=-1);
return 0;
}
Probably because you're not entering -1, so the loop quits. Once the loop quits, the program then quits since there is nothing left to do but return 0. There is no crashing. It's just ending because you didn't write your loop condition proplery.
but isnt it suppose do to the cout statements at least once? Is that the point of using a do... while?
Actually, I misread that. I must be a little blind tonight. The code looks relatively fine, outside of poor indention.
I even ran it myself, and it appears to work.... I don't know what your problem is. Sorry.
Aside from going into an infinite loop on entering a non-number, the code is fine. Are you sure that's exactly what you're compiling?
This isn't your problem here, but avoid "using namespace std", especially when declaring variable names that are type names in the standard namespace (e.g. list). It's a bad habit to get into.
I dont know works perfect to me try using a different compiler
Yes, the problem is my compiler, if i save a file, i must not have a space in the filename eg. project 1.cpp will cause my program to flash
I'm sure the compiler will cope with spaces in the filename, but you may need to quote the filename, e.g.Quote:
Originally Posted by MarlonDean
If you use:Code:
gcc "my file.c"
the compiler will try to compile "my" and "file.c" which will not do the right thing for you if you have a file called "my file.c".Code:gcc my file.c
If you use an IDE that doesn't cope with spaces in filenames, that's a bug in the IDE.
Finally, I would say it's a BAD idea to use filenames (or directories) with spaces for programming projects. It tends to lead to all sorts of interesting effects.
--
Mats
On a side note, Visual Studio seems to handle spaces in files fine. MFC sometimes tends to generate files with spaces inside. I can't vouch for other IDEs/compilers.Quote:
Originally Posted by matsp
Welcome to the future, manav. The future where IDEs compile our files for us so we don't need to use scripts or command line.
Both have their benefits. There are some really powerful solutions using command-line tools. Other things are much easier and better done in the IDE. It's not an "all or nothing" situation, there is a choice, and it's not that you can't choose for each individual task which one would work best.Quote:
Originally Posted by manav
A lot of people who don't use command line do so because they simply have never learned how to use the tools that are available there. There's also the problem that many of the OLD DOS and Windows equivalents of the Unix tools where not quite as good as the Unix equivalents.
--
Mats
Command lines are definitely outdated now, especially for Windows (maybe not for Linux).Quote:
Originally Posted by manav
There are tools that can generate scripts and the like, so you won't have to do it by hand. A good GUI will not care if the filenames contain spaces or not.
A library that requires you to compile your project via a makefile is a bad library. A good library can optionally support both.
Command lines are tricky and error prone (remember screwing up C++ exception handling due to compiling via the command line?).
That is your personal opinion, and you are entitled to it. I use command line a lot in Windows, it works just fine and does what you want, and building Windows drivers is completely done with command-line tools provided by the Windows DDK. Yes, you can make the Visual Studio IDE run the command line tools for you, but it's not running the standard IDE build tools.Quote:
Originally Posted by Elysia
As to getting options correct, you can get that right and wrong in both command line and IDE - if you don't set the right options [and figuring out WHAT IS RIGHT is a bit part of that puzzle] in either of them, you don't get what you wanted. It makes absolutely no difference if you have to select a box in an IDE or type in /EHsc [or whatever option you happen to want to use] on the command line - whichever way you do it, you still need to get it right.
--
Mats
While the original thing I was aiming for was that the IDE will set the default options for you and pass them to the compiler wheras with the command-line compiler, you have to set those manually because those options will default to OFF or whatever if you don't specify them.Quote:
Originally Posted by matsp
So it's less error prone to use visual studio to compile instead of the compiler. This fact was eventualized by the fact that manav compiled wrong because he was given the incorrect information (or as some say, failed to read the manual) about which command lines should be used. Had he compiled using the IDE instead, he would have received no such thing.
(Further to note that he did ignore the warning generated by the compiler also suggests that he failed to read the manual properly.)
As a side note to the original post: I ran the program as posted, and it works fine, but if I type in "1a" as the input, it will get into an infinite loop and eventually run out of memory. It takes a quite long time, since it's outputting the string "Enter a number or -1 to end..." many many times before it fails (at least on my machine).
--
Mats
Did I say they were? I mentioned IDEs are the future, that's all. IDEs will always be easier (OK, some will disagree on this, but anyway) than command lines or scripts.Quote:
Originally Posted by manav
The further we go into the future, the more feature rich the IDEs are going to become, as well as easier, probably. Therefore, in terms of ease and usability, I would a good IDE > command line tools & scripts.
Command lines and scripts exists today because no one has really invented anything to replace them. Relics of the old, yet relevant today.
The reason scripting and command line programs continue to exist and be used is because it is easier to implement advanced functionality in them than it is in a interactive program (eg IDE, GUI, etc).
While some development environments make it easier to develop graphical or text based user interfaces than was possible in the past, it is basically easier to parse a string (eg command line input) than it is to respond to various inputs or events associated with a user interface. It is possible to develop an IDE with all the advanced features of a command-line equivalent, but the effort of getting it right (correct "look and feel", correct responses to all possible sets of inputs,all the other things that contribute to "usability") is greater. Getting those sorts of things right requires consistent rules of interface design to achieve usability (an active area of research) and then development of high quality tools that allow development of user-interfaces using those rules (IDE is another area with considerable investment happening) and then programmer discipline to use them (a requirement against which many programmers require a lot of development).
This sort of thing is one of the reasons that vendors like Apple (MacOS attempts to provide all necessary power through GUI, so the user rarely needs to employ a command line program) charge a premium for their products. [And, no, I am not a MacOS user -- I pay less and use windows, but find I must sometimes resort to the command line].
Both Microsoft and Apple, however, are pushing forward GUIs. I don't know about Apple, but Microsoft is certainly trying to push their own techologies on us to make it easier to develop feature-rich and pretty GUIs.
In the future, the line between command line and GUIs is going to blur even more so, I think. And yet, will Linux still retort to their mostly command-line approach, I wonder?
Nay.Quote:
Originally Posted by manav
A GUI can express a lot of things a scripted language can, but it depends on the complexity and the aim. Expressing C++ is a GUI would be next to impossible (but DOABLE), but if you have the time and determination, it's possible. I dare say it would be a quality program too, if done right.
No, no period.Quote:
The GUI and command line/script tools have completely different benefits and fields of work. Period.
It can be done either ways.
Sure, you can make a compiler command line, but then again, you can make it as a dll or another form of code base - equally possible. It's just that we do not do this for various reasons - but it doesn't mean we cannot, or that it is targetted at a different field of work.
It may just be a bad habit, or disadvantages to it, but it's certainly possible.
You can say it's legacy. We still use old units for physics, for example, or food, even though newer, better units exist. Legacy.
Yes, let's not claim one is better then the other or that something is not doable in the other or that one only works in specialized fields. That way no one (or fewer) will complain.
I'd like to see C++ expressed as a GUI :D I mean, it would be cool to see XD, not that we need it.
Oh yeah, and no hard feelings. No hatred towards anyone here. Don't take anything serious :)
IDEs slow me down terribly when I'm editing code. I can't imagine anyone being more productive using one. What I can imagine and in fact have seen, are programmers who know how to push buttons, right-click, mouse-over, but are lost outside of the IDE. Even something as simple as browsing and editing source is a challenge, let alone compiling, linking, and running a simple test program.Quote:
Originally Posted by Elysia
I find that claim rather strange. It seems to me that an IDE should be no worse than using the tools separately, assuming that it does integrate those tools and allow you to configure them appropriately.Quote:
IDEs slow me down terribly when I'm editing code. I can't imagine anyone being more productive using one.
I do not see a problem with that. All that shows is that those programmers are only familiar with the tool that they use. Remove that tool and they flounder until they learn to use the new set of tools that they have at hand.Quote:
What I can imagine and in fact have seen, are programmers who know how to push buttons, right-click, mouse-over, but are lost outside of the IDE. Even something as simple as browsing and editing source is a challenge, let alone compiling, linking, and running a simple test program.
I agree. The common scenario here is that someone is used to editor X, and the keyboard mapping/functionality in the IDE editor is noticeably different from that. It does take some extra time to learn a new editor, and if you are one of those people who can remember some keyboard shortcut only after using it 200 times, it takes some effort to learn the new set of things. [I confess that quite often I press Emacs commands in the Eclipse-based tools we use here. Most of the time that's not a problem (aside from it not doing what I want), but when I do CTRL-X CTRL-S, it sometimes cuts a big piece of code and then saves the file, rather than just saving the file...].Quote:
Originally Posted by laserlight
Indeed. Tools you are not used to, whether that is just a different hammer, IDE or command line tools. Producing software is difficult (once it gets to a large and complex enough size), and getting everything right is not always easy, whether you have an IDE or use Makefiles, batch files, or some other way to build your source into an executable result.Quote:
I do not see a problem with that. All that shows is that those programmers are only familiar with the tool that they use. Remove that tool and they flounder until they learn to use the new set of tools that they have at hand.
--
Mats
For me, fullscreen GVim is largely preferable to the 1/4 screen edit window in an IDE, switching from mouse to keyboard and back, getting interrupted by Intellisense for things I already knew in the first place, having to hunt for settings to view/edit in various dialogs, etc.Quote:
Originally Posted by laserlight
Right, and the tool has abstracted away the process of compiling and linking and even running programs for some. I've seen people fire up an IDE just to run a program that was built with it. When I ask where the generated .obj or .class files are to validate that the build is current, the eyes glaze over.Quote:
I do not see a problem with that. All that shows is that those programmers are only familiar with the tool that they use. Remove that tool and they flounder until they learn to use the new set of tools that they have at hand.
I maintain that GVim is an IDE :DQuote:
For me, fullscreen GVim is largely preferable to the 1/4 screen edit window in an IDE
Anyway, there is no rule that says that IDEs must have a 1/4 screen edit window (I think they usually have a 1/2 screen edit window or larger by default, anyway), or that they cannot have a full screen mode (and some do).
There is no rule that says that one must switch between mouse to keyboard and back with IDEs. If there was such a rule, it would apply to all text editors too.Quote:
switching from mouse to keyboard and back
Disable unwanted features.Quote:
getting interrupted by Intellisense for things I already knew in the first place
Once you know where they are, you no longer need to hunt for them. If you still need to hunt for them, then perhaps the user interface design is at fault. That would be different from saying that IDEs inherently harm productivity.Quote:
having to hunt for settings to view/edit in various dialogs
Well, it sounds like the Law of Leaky Abstractions is at work here. However, I do not think that is a problem with the tool, but with the programmer. After all, if the programmer really is familiar with what the IDE does, then the programmer would not have that glazed look.Quote:
Right, and the tool has abstracted away the process of compiling and linking and even running programs for some. I've seen people fire up an IDE just to run a program that was built with it. When I ask where the generated .obj or .class files are to validate that the build is current, the eyes glaze over.
These are just my personal preferences, mind you. I may be a special case, as on certain projects I act as coder, builder, and deployer, which is why I need to know how things are built, what and where the artifacts are, etc. On others I may be editing C++, Java, Shell scripts, and Perl code in the same week, and GVim works for all of them exactly the same way.
I find it peculiar that you complain about those specific features out of all an IDE may offer. But a good IDE will allow you to specify where files end up, disable "unwanted" features (why anyone would want to disable IntelliSense, I have no idea), and all that.
Sure, if it works for you, then all is fine, but I do fine it a little strange that you would complain at that of everything.
Not working in an IDE for me would slow me down greatly, I would think. That the IDE abstracts away things is really nice. No need to separately compile and link files.
Editing code is what I do most, so the default window size, key map, Intellisense behavior, etc. are important to me. Sure, I can configure one version of one IDE on one build machine at one client, but then I have to keep repeating that process for the next project or gig. I thought that Eclipse and its myriad plugins might be a good solution to the consistency problem, but it's a hog of a program.Quote:
Originally Posted by Elysia
I do like the cross-referencing you get in an IDE, but when I need to edit or create a source file, I can do it faster in GVim.
So you work with different editors / IDEs / compilers all the time?
My current client has Java, C++, and even VB code in the application suite I am responsible for. I built an ant system on top of all of it for a project a couple years ago, and find it easier to edit in GVim and build with the ant script, which in the case of C++ and VB, invokes the IDE from the command line to build.Quote:
Originally Posted by Elysia
At my previous client, there were days when I would edit shell, Perl, C++, and Java. Not often, but I was working in two languages much of the time.
In my spare time, I dabble with C++ and Python.
Maybe I'll give Eclipse another shot - it's been a couple of years.
Not precisely true. There are some versions of linux (ubuntu comes to mind) that have a goal of an easier to use desktop (ubuntu is based on Gnome, IIRC). Not as far advanced as windows or MacOS, but they are advancing in that direction. Also MacOS is implemented on top of a BSD Unix.Quote:
Originally Posted by Elysia
Command line versus GUI is actually a trade-off, not an absolute case of right versus wrong. GUI front ends appeal more to non-expert users than command lines, so we can expect the practice of designing and implementing GUI to advance. However, it will be a long time before the effort to implement a GUI program will be comparable to the effort to implement a command line program that delivers equivalent functionality -- simply because the fundamentals of user interface, in current state of the art, involve more concepts than command line.
My personal prediction is that there will always be a significant role for both GUI and command line programs. From a design perspective, a well designed functional interface/separation/boundary between user interface and the supporting business logic is always desirable, rather than mixing elements of business logic into the user interface: it allows the user interface and business logic to be updated without breaking the other. This separation of interface and business logic is also fundamental to design and implementation of distributed applications - another happening trend. Two common ways of separating user interface from business-logic are (1) a user interface front end that employs a command-line based back-end and (2) a user interface front end and a command-line based front end, that both employ a common business logic back-end (eg using the business logic in a common library).
I invite you to learn and use Linux / any kind of UNIX for at least half a year, and you will see why people like me prefer the commandline for many things over GUIs.Quote:
And yet, will Linux still retort to their mostly command-line approach, I wonder?
One of the main reasons that I use Linux is because it has a vastly more powerful command line compared to Windows. I use the command line quite a bit. For example, nowadays I almost never use a GUI program to do file management (moving, copying etc). It is not because a good one is not available (there is Nautilus), but it is just a lot more efficient to do it on the command line. It does take longer to learn, but I spend many hours in front of the computer everyday, and the timesaving greatly outweighs the time needed to learn. Of course, there is little point in learning the command line if you only use the computer once per month... but I suspect that is not the case.
Actually, I just thought up a crude example -
Suppose you have 1000 programs/commands installed/available. On the command line, one would need to memorize the 1000 commands, but in actual use, it's just typing one command ( an O(1) operation ).
In GUI, however, the 1000 programs would have to be organized in nested menus (a list of 1000 programs to choose from doesn't sound too inviting). That makes choosing a program an O(logn) operation.
Another example -
When I have a naked C++ file to compile and see the output (downloaded from a forum for example), I certainly find it easier to do
than whatever you need to do using an IDE (create a project, add the file, etc).Code:g++ file.cpp
Not true... command line programs have sensible defaults, too.Quote:
While the original thing I was aiming for was that the IDE will set the default options for you and pass them to the compiler wheras with the command-line compiler, you have to set those manually because those options will default to OFF or whatever if you don't specify them.
Of course, there are things that is better done with a GUI (eg, I wouldn't want to do image editing on the command line), but there are also many things better/more efficiently done on the command line.
I'd go mad. I hate command lines.Quote:
Originally Posted by cyberfish
They are good for simple nothings; nothing more.
And how long does it takes to specify the full path to something instead of just selecting the files to move instead and dragging them? The latter sounds faster.Quote:
One of the main reasons that I use Linux is because it has a vastly more powerful command line compared to Windows. I use the command line quite a bit. For example, nowadays I almost never use a GUI program to do file management (moving, copying etc). It is not because a good one is not available (there is Nautilus), but it is just a lot more efficient to do it on the command line. It does take longer to learn, but I spend many hours in front of the computer everyday, and the timesaving greatly outweighs the time needed to learn. Of course, there is little point in learning the command line if you only use the computer once per month... but I suspect that is not the case.
No thanks. There's a reason why there are GUIs around and DOS evolved from command lines.
Or you could assign shortcuts or make a small program that launches said program or script if you type a small "command" or text. I did one such thing long ago for someone. Intuitive and far easier than command line.Quote:
Actually, I just thought up a crude example -
Suppose you have 1000 programs/commands installed/available. On the command line, one would need to memorize the 1000 commands, but in actual use, it's just typing one command ( an O(1) operation ).
In GUI, however, the 1000 programs would have to be organized in nested menus (a list of 1000 programs to choose from doesn't sound too inviting). That makes choosing a program an O(logn) operation.
You could argue that it is semi-command line since you have to type the program name, and sure, that may be the case, but I won't have to remember all thousand arguments to the program.
Which means the compiler might be misconfigured unless you punch in the correct arguments (and some compilers requires you to type more than just no command lines).Quote:
Another example -
When I have a naked C++ file to compile and see the output (downloaded from a forum for example), I certainly find it easier to do
than whatever you need to do using an IDE (create a project, add the file, etc).Code:g++ file.cpp
And I could just re-use a project I already have for such purposes.
A GUI can organize the output and sort them, the output from the command line can't.
Yes, but not all. Microsoft's C++ compiler requires a load of arguments to compile correctly; otherwise it will not generate any good code, or no code at all.Quote:
Not true... command line programs have sensible defaults, too.
O_oQuote:
They are good for simple nothings; nothing more.
My personal server uses a script calling CLI tools to support transparent differencing of massive storage. It is capable of watching any file whether it be local, on the network, or only available on the internet. (libcurl jigdo libtorrent) If a file is updated a difference is performed. (diff diff3 bindiff pdiff) If the file is from a watched source repository the file is pushed to my SVN. (subversion) If a file is part of a package the new file is added to a 7z container. (7zip) The latest version of any file/package/tracker is sent to the NAS and all network links are updated. (ftp libcurl) The difference is pushed to the update stack. The update catalog is itself updated so the old version of the file/package/tracker can be restored. Every day the update set is written to a new session on a DVDROM. (cdrtools) If the update catalog has reached the limit of the DVDROM an email is fired to one of my accounts and as part of packaging an image is generated listing any updates marked as major and the time spanned by the updates. (libmail imagemagick) If a file is an executable distribution/installer it is checked against my list; if the watched target is on my list the file is exploded and customized; if this executable distribution/installer is marked as major or more than two updates have been found a fresh master installer image is produced and an email is fired to one of my accounts. (my own stuff) If the second drive is free and contains a DVDR the image will be burned. At any time anyone with an account can login and request my server burn a fresh release DVD of anything with distribution rights on the server--including a few *nix releases.
If I need to know if some source I've written is sound I can fire off a different service that compiles and runs the relevant test suite on about thirty different devices. (GCC and several emulators)
Alternatively, if I've recently purchased a DVD or two, like say a season of anime, I can use the drive farm to transcode six discs at the same time into files and formats suitable for play/streaming to PS3/XBox 360 and PSP. Once this is successful the files are copied to the relevant network directories and the streaming server software is rebooted. (mplayer mencoder fuppes and some of my own stuff)
The beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together.
Soma
IMO, they should be implemented as DLLs/other techniques instead. CLI is not meant to be called from another program, because frankly, capturing and analyzing the output and determining if something went wrong is a pain. Plus there's no way good communication between the tools can be made.Quote:
Originally Posted by phantomotap
CLI just sucks in this regard, so they should not be used as external components. They can work as external applications, for use with things, but not within a programmatic environment. We don't live in 1980 anymore. Welcome to today's far better interfaces than CLI.
That is what I thought when I first tried Linux. Not anymore.Quote:
I'd go mad. I hate command lines.
They are good for simple nothings; nothing more.
It is easy for a Windows person to underestimate the command line, as Windows doesn't come with even a half decent one.
You can "cd" into a directory, just like you would on a GUI. Then you can use relative paths.Quote:
And how long does it takes to specify the full path to something instead of just selecting the files to move instead and dragging them? The latter sounds faster.
Yes, but DOS != command line. UNIX and Windows took different paths. Windows completely dumped the command line, and focus on GUI, while UNIX continued to develop the command line. One would guess that the UNIX people have accomplished at least something in the last ten years when MS was working on GUIs.Quote:
No thanks. There's a reason why there are GUIs around and DOS evolved from command lines.
Also known as tab completion?Quote:
Or you could assign shortcuts or make a small program that launches said program or script if you type a small "command" or text. I did one such thing long ago for someone. Intuitive and far easier than command line.
You could argue that it is semi-command line since you have to type the program name, and sure, that may be the case, but I won't have to remember all thousand arguments to the program.
BTW, the Linux version is vastly more powerful than the DOS version.
You need to configure a GUI compiler, too. No compiler is that smart, yet. However, gcc defaults are quite okay. I just tried compiling my ~4000 lines chess engine using a simple "g++ main.cpp", and it worked. All the flags (arguments) I use are for optimization purposes.Quote:
Which means the compiler might be misconfigured unless you punch in the correct arguments (and some compilers requires you to type more than just no command lines).
And I could just re-use a project I already have for such purposes.
You are underestimating the power of command line =).Quote:
A GUI can organize the output and sort them, the output from the command line can't.
http://en.wikipedia.org/wiki/Sort_(Unix)
I can, in 5 seconds time, type a command to delete all files in the current working directory, that begins with an "a" and ends in "z". Try that on a GUI.
A while ago I wrote a simple script that goes to the National Geographic website, parse the html (a simple thing on the command line), download the picture of the day, crop out the logo, scale it to the size of my desktop, and set it as my wallpaper, once a day. Try that on a GUI =). If you would rather use C++ for that... be my guest, but you will need to link to an image editing library, and a http library, and whatever API you need to set the wallpaper. I wouldn't be able to do it in < 500 lines at least.
Yes, and that is an example of a poorly designed program. Or perhaps Microsoft only intended it to be called by the GUI, not a human. Unlike GCC.Quote:
Yes, but not all. Microsoft's C++ compiler requires a load of arguments to compile correctly; otherwise it will not generate any good code, or no code at all.
That I totally agree.Quote:
The beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together.
Yes, that is the case with the black box (dos box that comes with Windows). It is 20 years old, not Linux.Quote:
CLI just sucks in this regard, so they should not be used as external components. They can work as external applications, for use with things, but not within a programmatic environment. We don't live in 1980 anymore. Welcome to today's far better interfaces than CLI.
I think phantomotap just showed that it is possible. Things like that are everywhere in UNIX world. (powerful scripts built from simple commands)Quote:
CLI just sucks in this regard, so they should not be used as external components. They can work as external applications, for use with things, but not within a programmatic environment. We don't live in 1980 anymore. Welcome to today's far better interfaces than CLI.
Many of them have DLL versions, for linking with compiled programs.Quote:
IMO, they should be implemented as DLLs/other techniques instead
I never use any command line tool aside from those for which there are not GUI equalient (often chkdsk, ipconfig). Last I tried Linux I just got annoyed and irritated, and I think I have expressed that frustration several times on the forums already.Quote:
Originally Posted by cyberfish
Quote:
You need to configure a GUI compiler, too. No compiler is that smart, yet. However, gcc defaults are quite okay. I just tried compiling my ~4000 lines chess engine using a simple "g++ main.cpp", and it worked. All the flags (arguments) I use are for optimization purposes.
Well, what can I say? Perhaps Microsoft thought no one would bother calling it from the command line and did the right thing by making it callable from GUI only :DQuote:
Yes, and that is an example of a poorly designed program. Or perhaps Microsoft only intended it to be called by the GUI, not a human. Unlike GCC.
That one is a piece of cake. I could write a very, very simple GUI to do that in a short time.Quote:
I can, in 5 seconds time, type a command to delete all files in the current working directory, that begins with an "a" and ends in "z". Try that on a GUI.
At the same time as you're promoting command line, you seem to have underestimated GUIs.
The problem is the lack of good GUIs for some tools, especially for scripted actions such as this.Quote:
A while ago I wrote a simple script that goes to the National Geographic website, parse the html (a simple thing on the command line), download the picture of the day, crop out the logo, scale it to the size of my desktop, and set it as my wallpaper, once a day. Try that on a GUI =). If you would rather use C++ for that... be my guest, but you will need to link to an image editing library, and a http library, and whatever API you need to set the wallpaper. I wouldn't be able to do it in < 500 lines at least.
Can it be done? Certainly. Just as as easy as if it were CLI - I can already picture a prototype of such a GUI in mind, and how to go about doing it.
Then they aren't CLI anymore - they are real interfaces, and everything is alright.Quote:
Originally Posted by cyberfish
^_^Quote:
IMO, they should be implemented as DLLs/other techniques instead. CLI is not meant to be called from another program, because frankly, capturing and analyzing the output and determining if something went wrong is a pain. Plus there's no way good communication between the tools can be made.
CLI just sucks in this regard, so they should not be used as external components. They can work as external applications, for use with things, but not within a programmatic environment. We don't live in 1980 anymore. Welcome to today's far better interfaces than CLI.
I've been a programmer for almost 22 years. I've been a C++ programmer for almost 13 years. I've been programming with Posix interfaces for 8 years. I've been programming with Windows system interfaces for 7 years. I've been programming with Windows GUI interfaces for 7 years. I've been programming with X GUI interfaces for 6 years. I have programmed applications in about forty GUI toolkits. This all to say that I have a lot of experience reading documentation.
With this in mind, I guarantee you that any traditional *nix user could script at least the curl/imagemagick/cdrtools portion of my file master scripts before you could get off the ground with C++ by using the relevant library code.
Soma
Me, too. But I resisted the temptation to go back. And now, I can't go back after I have seen its power. It is undoubted that Linux is indeed harder to learn. It's like how it is harder to learn to drive a car than ride a bike (assuming a car is more useful than a bike at where you live).Quote:
Last I tried Linux I just got annoyed and irritated, and I think I have expressed that frustration several times on the forums already.
Well, what can I say? :)Quote:
Well, what can I say? Perhaps Microsoft thought no one would bother calling it from the command line and did the right thing by making it callable from GUI only
How short is that? As short asQuote:
That one is a piece of cake. I could write a very, very simple GUI to do that in a short time.
? That's 6 characters including the space. My 5 seconds estimation is based on my typing speed of 6/5 letters per second =).Code:rm a*z
The thing is, AFAIK, no one has attempted it (in a big enough project), except Apple's Automator. Not quite as useful as CLI scripting, though (but I have not used it much, so might be wrong). As soon as they put it into a GUI, it loses 90% of its flexibility.Quote:
The problem is the lack of good GUIs for some tools, especially for scripted actions such as this.
Can it be done? Certainly. Just as as easy as if it were CLI - I can already picture a prototype of such a GUI in mind, and how to go about doing it.
People can and do argue that their CLI interfaces are as good as their DLL interfaces.Quote:
Then they aren't CLI anymore - they are real interfaces, and everything is alright.
More linux talk! I don't even know what they heck x/y/z is :|Quote:
Originally Posted by phantomotap
Linux is not for me >_< Everything needs to be written at least once, you know...
Does that include the time it took to write the CLI app itself? If not, then it isn't a fair comparison, you know?Quote:
Originally Posted by cyberfish
True to the first and no to the second, is what I'd like to say. If done properly, it doesn't lose flexibility.Quote:
The thing is, AFAIK, no one has attempted it (in a big enough project), except Apple's Automator. Not quite as useful as CLI scripting, though (but I have not used it much, so might be wrong). As soon as they put it into a GUI, it loses 90% of its flexibility.
Even so, the program could generate a script, which you could script yourself if you wanted. That would please both crowds, and loose no flexibility.
I strongly disagree here.Quote:
People can and do argue that their CLI interfaces are as good as their DLL interfaces.
What if the tools need to communicate?
Say, an application feeds raw frames from a video to a CLI tool via stdin. If the CLI tools receives a corrupt frame, should it terminate after having done 99% or maybe tell the provider: this is corrupt, can you provide a non-corrupt frame or do you want me to skip it, instead of just terminating, or if other non-expected event occur.
Perhaps you want the user to be able to select if they want to continue or not, despite that it might be corrupt? How do you go about doing that with a CLI tool, on a frame-by-frame basis?
No. CLI intefaces are poor, poor, poor, poor. DLL interfaces are far more flexible.
No, but when you say you move file by dragging and dropping, did you include the time it took to write Explorer? =)Quote:
Does that include the time it took to write the CLI app itself? If not, then it isn't a fair comparison, you know?
I wasn't using a specialized program for this task either. "rm" is the standard command for removing files.
Theoretically perhaps, but nothing like that exists yet, and I wonder why.Quote:
True to the first and no to the second, is what I'd like to say. If done properly, it doesn't lose flexibility.
That is essentially what Automator does. The difficulty is in communicating to the GUI what you want the script to do, not actually generating the script.Quote:
Even so, the program could generate a script, which you could script yourself if you wanted. That would please both crowds, and loose no flexibility.
True. Command line programs typically only communicate failure by return code (the "int" in "int main()"). Then, of course, the calling program can lookup what the return code means, just like how people do it with dlls. Normal input/output is done through the pipes (stdin stdout). There is stderr for error logging/reporting actually. What you just said can certainly be done in command line.Quote:
I strongly disagree here.
What if the tools need to communicate?
Say, an application feeds raw frames from a video to a CLI tool via stdin. If the CLI tools receives a corrupt frame, should it terminate after having done 99% or maybe tell the provider: this is corrupt, can you provide a non-corrupt frame or do you want me to skip it, instead of just terminating, or if other non-expected event occur.
Perhaps you want the user to be able to select if they want to continue or not, despite that it might be corrupt?
By prompting the user, just like how you would do it in C++.Quote:
How do you go about doing that with a CLI tool, on a frame-by-frame basis?
Fair enough, let's leave the actual applications out of this :pQuote:
Originally Posted by cyberfish
Command line may be faster, but the GUI certainly isn't slow either...
Sure, but it took time to develop the rm command when it first was created.Quote:
I wasn't using a specialized program for this task either. "rm" is the standard command for removing files.
They're all lazy bastards and don't realize the the gain of doing this :|Quote:
Theoretically perhaps, but nothing like that exists yet, and I wonder why.
I don't think it would be that difficult, no...Quote:
That is essentially what Automator does. The difficulty is in communicating to the GUI what you want the script to do, not actually generating the script.
Pretty solution, though? Hardly. I think not.Quote:
True. Command line programs typically only communicate failure by return code (the "int" in "int main()"). Then, of course, the calling program can lookup what the return code means, just like how people do it with dlls. Normal input/output is done through the pipes (stdin stdout). There is stderr for error logging/reporting actually. What you just said can certainly be done in command line.
But then again, that's not what a tool should do. That reduces flexibility by a lot (what if you wanted to display the error in german and not english, which the app was written in?).Quote:
By prompting the user, just like how you would do it in C++.
I think that just defies the purpose of such a tool.
You seem to be hung up on the concept of reuse. The time to develop rm is irrelevant, because it's amortized by the incredible flexibility the combination of rm and shell commands give you.Quote:
Sure, but it took time to develop the rm command when it first was created.
The time to develop a GUI for removing files is not mitigated unless it gives you very smart way of selecting files according to specific criteria. And in all likelihood, this criteria engine will use some glob or regular expression as the input, thus emulating the command line.
You keep harping about what the command line can't do or can't do properly, or even what it shouldn't do, when you have almost no experience with it. You're not making arguments. You're merely demonstrating ignorance.
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.Quote:
Fair enough, let's leave the actual applications out of this
Command line may be faster, but the GUI certainly isn't slow either...
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-*
Yes, and it was >20 years ago, and GUI programs haven't caught up to that kind of flexibility yet.Quote:
Sure, but it took time to develop the rm command when it first was created.
That is a very noble undertaking. Very courageous of you, Elysia. =)Quote:
They're all lazy bastards and don't realize the the gain of doing this :|
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?Quote:
Pretty solution, though? Hardly. I think not.
CLI is not God, there is a limit to what it can do, too =).Quote:
what if you wanted to display the error in german and not english, which the app was written in?
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 =).
Where's the difference between localization in CLI and GUI apps?Quote:
what if you wanted to display the error in german and not english
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.Quote:
Of course there is a limit to how complex a script gets.
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
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 CornedBee
There are solutions to that too... DLL interfaces or using compatible apps to create scripts.Quote:
Originally Posted by phantomotap
Or how about just a CLI wrapper tool for the DLL interfaces?
You can say so. But it makes us wonder about you ...
Aside from CLI tools not popping up dialogs ...Quote:
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.
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.
I'm not blaming the CLI - it's about how the tool should not prompt, but the program.Quote:
Originally Posted by CornedBee
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.
O_oQuote:
There are solutions to that too... DLL interfaces or using compatible apps to create scripts.
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.
^_^Quote:
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:
Quote:
They are good for simple nothings; nothing more.
SomaQuote:
CLI intefaces are poor, poor, poor, poor. DLL interfaces are far more flexible.
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.Quote:
Originally Posted by phantomotap
Hence the "wrapper" part ;)Quote:
^_^
That would allow the scripting... and I love that you said that; especially after these gems:
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.
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.Quote:
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.
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.Quote:
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.
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
Sorry for my ignorance. Linux newbie here =) (~3 years).Quote:
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.
Ah well, what can I say? :)Quote:
Originally Posted by phantomotap
I'll just let CLI win (for now :D).