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; Originally Posted by Elysia So you work with different editors / IDEs / compilers all the time? My current client ...

  1. #31
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Elysia View Post
    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.

    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.

  2. #32
    Registered User
    Join Date
    Jun 2005
    Posts
    6,433
    Quote Originally Posted by Elysia View Post
    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?
    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.

    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).

  3. #33
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    And yet, will Linux still retort to their mostly command-line approach, I wonder?
    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.

    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
    Code:
    g++ file.cpp
    than whatever you need to do using an IDE (create a project, add the file, etc).

    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.
    Not true... command line programs have sensible defaults, too.

    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.
    Last edited by cyberfish; 05-21-2008 at 11:51 PM.

  4. #34
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,781
    Quote Originally Posted by cyberfish View Post
    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.
    I'd go mad. I hate command lines.
    They are good for simple nothings; nothing more.

    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.
    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.
    No thanks. There's a reason why there are GUIs around and DOS evolved from command lines.

    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.
    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.

    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
    Code:
    g++ file.cpp
    than whatever you need to do using an IDE (create a project, add the file, etc).
    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.
    A GUI can organize the output and sort them, the output from the command line can't.

    Not true... command line programs have sensible defaults, too.
    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 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. #35
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,334
    They are good for simple nothings; nothing more.
    O_o

    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
    Last edited by phantomotap; 05-22-2008 at 01:22 AM.

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,781
    Quote Originally Posted by phantomotap View Post
    The beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together.
    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.
    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. #37
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    I'd go mad. I hate command lines.
    They are good for simple nothings; nothing more.
    That is what I thought when I first tried Linux. Not anymore.
    It is easy for a Windows person to underestimate the command line, as Windows doesn't come with even a half decent one.

    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.
    You can "cd" into a directory, just like you would on a GUI. Then you can use relative paths.

    No thanks. There's a reason why there are GUIs around and DOS evolved from command lines.
    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.

    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.
    Also known as tab completion?
    BTW, the Linux version is vastly more powerful than the DOS version.

    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 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.

    A GUI can organize the output and sort them, the output from the command line can't.
    You are underestimating the power of command line =).
    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, 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.
    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.

  8. #38
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    The beauty of CLI tools aren't their inherent capability but how easily one can glue the various tools together.
    That I totally agree.

    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.
    Yes, that is the case with the black box (dos box that comes with Windows). It is 20 years old, not Linux.

    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)

    IMO, they should be implemented as DLLs/other techniques instead
    Many of them have DLL versions, for linking with compiled programs.

  9. #39
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,781
    Quote Originally Posted by cyberfish View Post
    That is what I thought when I first tried Linux. Not anymore.
    It is easy for a Windows person to underestimate the command line, as Windows doesn't come with even a half decent one.
    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.

    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.
    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.
    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

    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.
    That one is a piece of cake. I could write a very, very simple GUI to do that in a short time.
    At the same time as you're promoting command line, you seem to have underestimated GUIs.

    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.
    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.

    Quote Originally Posted by cyberfish View Post
    Many of them have DLL versions, for linking with compiled programs.
    Then they aren't CLI anymore - they are real interfaces, and everything is alright.
    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.

  10. #40
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,334
    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

  11. #41
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Last I tried Linux I just got annoyed and irritated, and I think I have expressed that frustration several times on the forums already.
    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).

    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
    Well, what can I say?

    That one is a piece of cake. I could write a very, very simple GUI to do that in a short time.
    How short is that? As short as
    Code:
    rm a*z
    ? That's 6 characters including the space. My 5 seconds estimation is based on my typing speed of 6/5 letters per second =).

    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.
    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&#37; of its flexibility.

    Then they aren't CLI anymore - they are real interfaces, and everything is alright.
    People can and do argue that their CLI interfaces are as good as their DLL interfaces.

  12. #42
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,781
    Quote Originally Posted by phantomotap View Post
    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.
    More linux talk! I don't even know what they heck x/y/z is :|
    Linux is not for me >_< Everything needs to be written at least once, you know...

    Quote Originally Posted by cyberfish View Post
    How short is that? As short as
    Code:
    rm a*z
    ? That's 6 characters including the space. My 5 seconds estimation is based on my typing speed of 6/5 letters per second =).
    Does that include the time it took to write the CLI app itself? If not, then it isn't a fair comparison, you know?

    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.
    True to the first and no to the second, is what I'd like to say. If done properly, it doesn't lose 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.

    People can and do argue that their CLI interfaces are as good as their DLL interfaces.
    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? 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.
    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.

  13. #43
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Does that include the time it took to write the CLI app itself? If not, then it isn't a fair comparison, you know?
    No, but when you say you move file by dragging and dropping, did you include the time it took to write Explorer? =)

    I wasn't using a specialized program for this task either. "rm" is the standard command for removing files.

    True to the first and no to the second, is what I'd like to say. If done properly, it doesn't lose flexibility.
    Theoretically perhaps, but nothing like that exists yet, and I wonder why.

    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.
    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.

    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&#37; 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?
    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.

    How do you go about doing that with a CLI tool, on a frame-by-frame basis?
    By prompting the user, just like how you would do it in C++.

  14. #44
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,781
    Quote Originally Posted by cyberfish View Post
    No, but when you say you move file by dragging and dropping, did you include the time it took to write Explorer? =)
    Fair enough, let's leave the actual applications out of this
    Command line may be faster, but the GUI certainly isn't slow either...

    I wasn't using a specialized program for this task either. "rm" is the standard command for removing files.
    Sure, but it took time to develop the rm command when it first was created.

    Theoretically perhaps, but nothing like that exists yet, and I wonder why.
    They're all lazy bastards and don't realize the the gain of doing this :|

    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.
    I don't think it would be that difficult, no...

    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.
    Pretty solution, though? Hardly. I think not.

    By prompting the user, just like how you would do it in C++.
    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?).
    I think that just defies the purpose of such a tool.
    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.

  15. #45
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Sure, but it took time to develop the rm command when it first was created.
    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.
    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.
    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

Page 3 of 4 FirstFirst 1234 LastLast
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