View Poll Results: Who agrees with me that this thread should die?

Voters
5694. You may not vote on this poll
  • Should die now

    5,694 100.00%
  • Should let message board nature take it down the list

    0 0%

Clearing the console

This is a discussion on Clearing the console within the C++ Programming forums, part of the General Programming Boards category; Me, too, and I also know these kinds of things already...

  1. #31
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Me, too, and I also know these kinds of things already
    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

  2. #32
    Sweet
    Join Date
    Aug 2002
    Location
    Tucson, Arizona
    Posts
    1,801
    I still am cooler than you so ya.
    Sad thing is this thread was about clearing the screen and turned into this.
    Woop?

  3. #33
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    Sad thing is this thread was about clearing the screen and turned into this.
    Considering the original question is answered in the FAQ, I see no loss. Plus, the entertainment value of this thread is priceless. Nothing like watching a CS student give a lecture to people who have been programming for 10-20 years.

  4. #34
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Lets see loop costs a memory write that would cached at the very least, this is a pretty quick operation. Body of loop costs a device output, even with buffering this is a pretty slow operation.

    Now instead of pretty little worthless optimizations why not using a better algo to begin with? Heck this would be faster and give the exact same result:
    Code:
    puts("\n\n...\n\n");
    Where ... is 46 more \n

  5. #35
    ^ Read Backwards^
    Join Date
    Sep 2005
    Location
    Earth
    Posts
    282
    I am very new to C++, but uhh…what is wrong with telling the poor guy to just use the following instead of doing it himself?:

    Code:
    system("cls");
    For Visual C++, just make sure to #include <iostream>

    I think that is iostream.h in Borland c++? Or maybe that is just old versions. Like I said, I am new.

  6. #36
    Nonconformist Narf's Avatar
    Join Date
    Aug 2005
    Posts
    174
    just make sure to #include <iostream>
    <cstdlib>, or <stdlib.h> for old compilers. But I'm sure a few people here will be happy to tell you that system() is slow, and unsafe, and not portable. In my opinion, it's all good as long as you know the costs and they're acceptable.
    Just because I don't care doesn't mean I don't understand.

  7. #37
    ^ Read Backwards^
    Join Date
    Sep 2005
    Location
    Earth
    Posts
    282
    In my opinion, it's all good as long as you know the costs and they're acceptable.
    Uhh nope, I do not. Nor was I aware of any of the issues you mentioned!

  8. #38
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    system() is completly portable -- it is part of the standard C libraries, so all C compliant compilers regardless of platform support it. embedded c compilers are not fully c compliant, so they are not bound by those standards.

    There is no completly portable way of spawning one program from another. All the functions (such as system, spawnl, pipes, sockets, CreateProcess, WinExec, and sevefal others) require intimate knowledge of the operating system. So -- using system() is no more and no less portable than using any other of the several functions.
    Last edited by Ancient Dragon; 09-08-2005 at 08:08 PM.

  9. #39
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    system() itself is portable, but system("cls"); is not. Thats what people here tend to mean when we say its a non portable solution.

  10. #40
    Geek. Cobras2's Avatar
    Join Date
    Mar 2002
    Location
    near Westlock, and hour north of Edmonton, Alberta, Canada
    Posts
    113
    Quote Originally Posted by adrianxw
    He'll learn when the real world bites him. After all, as a CS student he's bullet proof. Us old hacks that have actually been doing the job for real money in the real world for years know nothing.

    Where's that damned rep button when you need it.
    I'm a CS student too, and here's what I know from knowledge gained in my algorithms course (using "A Practical Introduction to Data Structures and Algorithm Analysis" by Shaffer) + common sense
    (note: not preaching at anybody, but who knows, this might actually come in handy to someone who doesn't already know it)



    running the loop fifty times results in the following happening:
    i is assigned the value 0, 1 time.
    i is incremented (has 1 added) 50 times.
    i is checked against the vlue '50' 51 times.
    putchar('\n') is called 50 times.

    i.e. At this point it should be obvious to mostly anyone who's spent any time programming that putchar is taking more time than any operations on i are taking, even if you take into account the fact that it's buffered output.


    To go a little further, here is approximately what is happening(while calling putchar), from my knowledge of C:
    first the character '\n' gets copied (I'm not 100% sure of this part, but like 95% sure) and sent to the function putchar. putchar then sends this copied character to the output buffer - which may even require another (lower level) function being run. All in all, putchar('\n) is *at least* 10 times as long as the time required to assign 0 to i (actualy a whole lot more, I am willing to bet money). incrementing i will take even less time than initializing i.


    Now, the proposed optimization is to change i so that access to it will be faster, but consider what's happening first:

    i is taking a certain period of time to be initialized, and to be incremented 50 times, and to be checked against 50, 51 times. putchar is taking (from earlier argument) about 10 times as long as the increment, and let's say that an increment on i takes an average of 1/2 as long as the initialization of i. a check against 50 probably takes somewhere around as long as initializing i (although you could optimize that with a good algorithm)

    now, i is taking 1 time unit to be initialized, and 25 units (50/2) to be incremented throughout the course of the loop, and around 51 units to be checked.
    All together, i is taking around 77 units of time throughout the course of the loop.

    putchar, on the other hand, takes at least 10 units of time per run, and running 50 times, which means it is taking *500* units of time (probably lot more, since it probably takes a lot more than 10 times as long as an operation on i, but let's keep to the times I already mentioned).

    now, let's say that setting i up as a register variable will cut all access times on i by 20%; so now instead of taking 77 time units it only takes 61.6 time units. Let's see how much time we saved on our total operation:
    total time without register: 577
    total time with register: 561.6
    total difference: about 2.7%

    so, assuming putchar takes only 10 times as long as an operation on i, we saved 3% of the time. However, what if putchar takes 50 times as long as an operation on i? well, then:
    total time without register: 2577
    total time with register: 2561.6
    total difference: about 0.6%

    The main point is that operations on the loop variable are *already* a very small part of the overall loop. changing it to a register int doesn't make much difference; but, as you can see, the place where the difference *is* made is *INSIDE* the loop [putchar]
    James G. Flewelling
    Rgistered Linux User #327359
    Athabasca University Student (BSc. CIS)

    http://catb.org/~esr/faqs/smart-questions.html
    http://catb.org/jargon/

    http://www.ebb.org/ungeek
    ---GEEK CODE---
    Version: 3.12
    GCS/IT/M d- s+:++ a-->->>+>++>+++>? C++++>$ UL++>++++$ P++>++++ L++>++++$
    E W++ N o? K? w++(--)>--- O? M? V? PS--(---) PE Y+ PGP? t 5? !X R(*)>++
    tv-->! b++(+++)>++++ DI? D+++(---)>++++$ G e*>++$ h++>*$ r!>+++ y?
    ----/GEEK CODE----
    upd: 2005-02-11

  11. #41
    It's full of stars adrianxw's Avatar
    Join Date
    Aug 2001
    Posts
    4,831
    as you can see, the place where the difference *is* made is *INSIDE* the loop
    If you read my tutorial, which I linked to above, you'll note I do not advocate the use of any kind of loop to clear the screen.....
    Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.

  12. #42
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Just to add to what Cobras said, there's another detail to putting i into a register that was conveniently forgotten. Let's stay with the IA32 arch for the moment, with its 8 general purpose registers. Now, a loop counter will most commonly be stored in the ecx registers. The fun part is that, with most compilers, ecx is not preserved across function calls. In other words, somewhere inside putchar(), another value might be assigned to it. (E.g. the loop counter/pointer in a memcpy call if the buffer is flushed.)
    Since putchar() is a library function, the compiler cannot even do global optimizations. So i cannot be put into a register in the first place - or even if it is in a preserved register, the called function would still have to store it on the stack - in memory.
    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

  13. #43
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    Quote Originally Posted by Thantos
    system() itself is portable, but system("cls"); is not. Thats what people here tend to mean when we say its a non portable solution.
    system("put anything at all here") is not portable. And the point is ....? If you're writing portable code then you wouldn't use system() function for anything. If you want to use it then put it in preprocessor directives like this. But of course I don't do this because I could care less about the portability of my text/example programs. And if I'm writing a program for MS-Windows os and use other win32 api functions portability of the code isn't even an issue, so again system("cls") is a good way to clear the screen.

    Code:
    #if defined(_WIN32)
    system("cls");
    #elif defined(_UNIX)
    system("clear");
    #elif defined(_MAC)
    system("put something else here");
    #endif

  14. #44
    Sweet
    Join Date
    Aug 2002
    Location
    Tucson, Arizona
    Posts
    1,801
    system("cls") is not the best and safest way to clear the screen by any means. Using the bottom of this page would probably be one of the better ways.
    Woop?

  15. #45
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    system("put anything at all here") is not portable. And the point is ....?
    The left side of the quotation. The entire issue is about portability.
    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. Full Screen Console
    By St0rmTroop3er in forum C++ Programming
    Replies: 1
    Last Post: 09-26-2005, 09:59 PM
  2. Console Functions Help
    By Artist_of_dream in forum C++ Programming
    Replies: 9
    Last Post: 12-04-2004, 02:44 AM
  3. Clearing the screen in a dos console window...
    By Unregistered in forum C++ Programming
    Replies: 13
    Last Post: 02-15-2002, 03:15 AM
  4. Just one Question?
    By Irish-Slasher in forum C++ Programming
    Replies: 6
    Last Post: 02-12-2002, 09:19 AM
  5. clearing an NT console
    By iain in forum C++ Programming
    Replies: 1
    Last Post: 12-07-2001, 12:08 PM

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