Wats wrong!!

Following is a program which first inputs a stream of alphabets by the user and is then supposed to clear the screen partially. But it does not seem to be doing its job. Can u please help me find wats wrong with this.

Code:

#include<iostream> #include<stdio.h> int main() { char *scr=(char*)0xB8000000; char str[80],c; int i,row=0,col=0; puts("Type the alphabets"); while((c=getchar())!=EOF) { char *v; v=scr+row*160+col*2; *v=c; c+=2; if(c==80) { row++; c=0; } } row=row/2; col=col/2; while(1) { char *v; v=scr+row*160+col*2; *v=' '; c-=2; if(c==0) { row--; c=80; } if(row==0 && col==0) break; } return 0; }

Where did you get that code from?! Have you heard about protected mode?

How do I clear the screen-FAQ()

Yes I have heard about the protected mode. It is an exercise program that I am trying, based upon the explainations and other codes that I read about VDU memory and printing characters to the screen. 0xB8000000 is the address of the VDU memory and anything that is written at this address (with the attrbutes of the characters at odd addresses) is supposed to be appear on the screen. So the blank space that I am trying to print should clear the screen partially ( row=row/2; col=col/2; ).

Quote:

Originally Posted by juice

Yes I have heard about the protected mode. It is an exercise program that I am trying, based upon the explainations and other codes that I read about VDU memory and printing characters to the screen. 0xB8000000 is the address of the VDU memory and anything that is written at this address (with the attrbutes of the characters at odd addresses) is supposed to be appear on the screen. So the blank space that I am trying to print should clear the screen partially ( row=row/2; col=col/2; ).

Well, guess what: You can't. Not in user-space. You need the OS's functions to do that. It ( the OS ) has taken measures to ensure that neither you nor anyone else can dumble with any memory you desire!

Not at all. I've done this in the past, I just can't find wat's wrong..

how far in the past? if you did it on DOS or Windows 95/98/ME, you'll find that a lot has changed since then. if you're doing it on some sort of embedded system, or if you're running this in a kernel module or driver, it's possible, but if it's a user-privilege program on any modern operating system, it simply will not work.

This is C, not C++. It would be appreciated if you could distinguish it enough to put it in its proper category next time.

Code:

char str[80],c; int i,row=0,col=0; puts("Type the alphabets"); while((c=getchar())!=EOF)

The getchar function returns an int, not a char. This is important when comparing against EOF.

Just a note about the "clear a screen".
On windows, this can be easily done:

Code:

#define NOCOMM //this makes sure you don't load all the fat from the next header #include <windows.h>//contains the system function /* ...... */ system("cls"); /* ...... */

This code only runs on windows though, so make the that dependant on the platform, the alternative on linux is described in this post:
Returning to different parts of script. - C++ Forum.
(note the name of the link is insubstantial).

Quote:

Originally Posted by Elysia

This is C, not C++. It would be appreciated if you could distinguish it enough to put it in its proper category next time.

but he/she included <iostream>

doesn't that make it C++? ;)

Quote:

Originally Posted by Shingetsu Kurai

Just a note about the "clear a screen".
On windows, this can be easily done:

Code:

#define NOCOMM //this makes sure you don't load all the fat from the next header #include <windows.h>//contains the system function /* ...... */ system("cls"); /* ...... */

This code only runs on windows though, so make the that dependant on the platform, the alternative on linux is described in this post:
Returning to different parts of script. - C++ Forum.
(note the name of the link is insubstantial).

Firstly, system() is declared in the standard C header, <stdlib.h>. It is not necessary to #include <windows.h> to use it, even on windows.

The problem with system("cls") is that it is completely non-portable. Under windows, it relies on the command interpreter supporting a cls command that clears the screen. That implies a program that runs (under windows) within a console or command window. It is completely inapplicable to windows programs that support a windows GUI.

Similar comments apply to the "alternative on linux" that you linked to.

As mentioned in the link provided by AndrewHunter (and by other posters) clearing a screen is not standard C or C++. If you even need to care about clearing a screen, you need to be quite clear what "screen" actually means for your application, and accept that your code may be completely non-portable.

You also need to accept that a lot of people will provide you with "simple" solutions that don't always work (because they assume you are doing something you are not). If you are using a library that addresses your needs (for example, console I/O functions in the win32 API, curses under linux) you need to accept you are locked into those libraries, and also realise your code may break when the library is updated or the operating system is updated.

And the older the techniques are that you use (for example, using DOS interrupts or BGI (Borland Graphics Interface) calls under DOS) the more likely your program is to cease working when your operating system is upgraded. That is not because those techniques are bad (in fact, in their day, they were actually quite brilliant) but simply because life moves on. If it is not nailed down in a standard - and preferably a standard that can be applied cross-system - you are vulnerable to obsolescence.

Quote:

Originally Posted by Elkvis

but he/she included <iostream>

doesn't that make it C++? ;)

It doesn't change the fact that it's C with a C++ header.