compile C programs for both sunstudio and Visual studio

[happytoday]

I comile C programs for bothe platforms : sunstudio using cc , visual
studio 6 . Is there a command to differeniate which platform I compile
for . That in order to use the the system command .

For example :

If (unixplatform)
system("clear");
else
system("cls")

 

[Ben Bacarisse]

I comile C programs for bothe platforms : sunstudio using cc , visual
studio 6 . Is there a command to differeniate which platform I compile
for . That in order to use the the system command .

For example :

If (unixplatform)
system("clear");
else
system("cls")

Every compiler defines one or more macros that can be used to determine
when you are using it. Check the documentation, but I think Sun
compilers define __sun so you can write:

#ifdef __sun
system("clear);
#else
system("cls");
#endif

Almost all "console programs" run in a window (or maybe even real
hardware) that understands ANSI control sequences. If all you want to
do is a few simple operations like clearing the screen, you could write
short functions that produce the correct sequence. For example,

void screen_clear(void) { puts("\x1b[H\x1b[2J"); }

moves the cursor to the top of the screen and the clears it.

Even if you decide to use conditional compilation, it's a good idea to
put all such system dependencies into functions that are defined away
from the rest of the code:

void screen_clear(void)
{
#ifdef __sun
system("clear);
#else
system("cls");
#endif
}

 

[Heinrich Wolf]

....

Almost all "console programs" run in a window (or maybe even real
hardware) that understands ANSI control sequences. If all you want to
do is a few simple operations like clearing the screen, you could write
short functions that produce the correct sequence. For example,

void screen_clear(void) { puts("\x1b[H\x1b[2J"); }

moves the cursor to the top of the screen and the clears it.

....
The windows console does not natively understand ANSI control sequences. You
would explicitely have to load the ANSI driver. And I was told not to use
hardcoded ANSI control sequences on Unix either.

my code for clearing the screen is the following (working with Turbo C 2.0,
Borland C++Builder 5, MSVC, Linux, SCO Unix, SINIX). clear() is defined on
Unix in curses.h . clrscr() is defined on Turbo C in conio.h , but on
Borland C++Builder clrscr() does not clear more then 44 lines (a Windows
console may have more).

#if defined(sinix) || defined(SNI) || defined(M_UNIX) ||
defined(linux)
#define Unix
#endif

#ifdef Unix
#include <termios.h>
#include <curses.h>
#else
#include <conio.h>
#endif

#ifdef __TURBOC__
#if __TURBOC__ <= 0x0200
#define clear clrscr
#else
#define ReplaceConio
#include <windows.h>
#endif
#endif

#ifdef MSDOS
#define clear() _clearscreen(_GCLEARSCREEN)
#endif

#ifdef _MSC_VER
#define ReplaceConio
#include <windows.h>
#include <wincon.h>
#endif

#ifdef ReplaceConio
void clear(void)
{
COORD coordScreen;
DWORD cCharsWritten,
dwConSize;
HANDLE hConsole;
CONSOLE_SCREEN_BUFFER_INFO csbi;

coordScreen.X = 0;
coordScreen.Y = 0;
hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
GetConsoleScreenBufferInfo(hConsole, &csbi);
dwConSize = csbi.dwSize.X * csbi.dwSize.Y;
FillConsoleOutputCharacter(hConsole, ' ', dwConSize,
coordScreen, &cCharsWritten);
FillConsoleOutputAttribute(hConsole, csbi.wAttributes,
dwConSize, coordScreen,
&cCharsWritten);
SetConsoleCursorPosition(
GetStdHandle(STD_OUTPUT_HANDLE), coordScreen);
}
#endif

 

[Ben Bacarisse]

...

Almost all "console programs" run in a window (or maybe even real
hardware) that understands ANSI control sequences. If all you want to
do is a few simple operations like clearing the screen, you could write
short functions that produce the correct sequence. For example,

void screen_clear(void) { puts("\x1b[H\x1b[2J"); }

moves the cursor to the top of the screen and the clears it.

...
The windows console does not natively understand ANSI control
sequences. You would explicitely have to load the ANSI driver.

You are quite right -- I'd forgotten that.

And I
was told not to use hardcoded ANSI control sequences on Unix either.

Also true (and very much so when I started out) but there are ever fewer
cases where simple ANSI sequences won't work. It's just possible that
with a generous reading of "almost all" and a few corrupt statisticians
in my employ I could still justify my original statement, but I should
give it up!

As your code shows, there is no simple portable solution.

<snip>

 

[Virchanza]

As your code shows, there is no simple portable solution.

I went all-out with a program of a mine and used the cross-platform
"ncurses" library:

http://en.wikipedia.org/wiki/Ncurses

 

[Ben Bacarisse]

I went all-out with a program of a mine and used the cross-platform
"ncurses" library:

http://en.wikipedia.org/wiki/Ncurses

How much functionality does ncurses give you on a Windows console when
there is no ANSI driver loaded?

 

[Keith Thompson]

Almost all "console programs" run in a window (or maybe even real
hardware) that understands ANSI control sequences. If all you want to
do is a few simple operations like clearing the screen, you could write
short functions that produce the correct sequence. For example,

void screen_clear(void) { puts("\x1b[H\x1b[2J"); }

moves the cursor to the top of the screen and the clears it.

And then moves the cursor down one line. puts() prints a '\n'
after printing its argument string.

Better:

fputs("\x1b[H\x1b[2J", stdout);
fflush(stdout);

Of course that's still non-portable, for various reasons that have
been discussed downthread.

But I suggest that the OP should ask himself whether he really
should be clearing the screen in the first place.

For a text editor or some other program that needs to take control
of the entire screen, clearing the screen is certainly a sensible
thing to do, but such a program is probably going to be using curses
or some similar package anyway.

For a program that just reads from stdin (assumed to be a keyboard)
and writes to stdout (assumed to be a screen of some sort),
clearing the screen can erase information that might be of some
value to the user. Consider carefully whether your desire to have
a clean-looking display outweighs your user's desire to keep his
own information on the screen. (Of course, if you're going to be
the only user of the program, do whatever you like.)

 

[Ben Bacarisse]

I can't say, not having touched ncurses for years. However, I can
tell you that there is no need for any ANSI driver, as there is an
entire Windows Console API available to handle such things.

Yes. I suppose I was asking, rather indirectly, does ncurses use it?

 

[Geoff]

I comile C programs for bothe platforms : sunstudio using cc , visual
studio 6 . Is there a command to differeniate which platform I compile
for . That in order to use the the system command .

For example :

If (unixplatform)
system("clear");
else
system("cls")

The Microsoft predefined macros _WIN32 and _MSC_VER come to mind,
recently _WIN64.

http://msdn.microsoft.com/en-us/library/aa273918(v=VS.60).aspx

http://msdn.microsoft.com/en-us/library/b0084kay

I suppose you could set unixplatform true by default and set it false
depending on the return from a conditionally-compiled GetVersionEx
call.

http://support.microsoft.com/kb/307394

 

[Waldek M.]

Dnia Sun, 17 Jul 2011 22:49:38 -0500 (CDT), happytoday napisa³(a):

I comile C programs for bothe platforms : sunstudio using cc , visual
studio 6 . Is there a command to differeniate which platform I compile
for . That in order to use the the system command .

For example :

If (unixplatform)
system("clear");
else
system("cls")

Ugh. First of all, do not use system(). There are good
reasons for that, search google for them.

Secondly, you use preprocessor for the platform checking;
compilers present the appropriate symbols.

Third - don't cross-post, and if you have to, set FUT.

Br.
Waldek

 

[BGB]

I comile C programs for bothe platforms : sunstudio using cc , visual
studio 6 . Is there a command to differeniate which platform I compile
for . That in order to use the the system command .

For example :

If (unixplatform)
system("clear");
else
system("cls")

partial answer:
#ifdef

downside:
can get very nasty very fast if wide portability is a concern (but
generally works well enough in the common case where the number of
relevant combinations of target OS/CPU/... in question is small enough
to be counted using a single hand).


others would likely advise not depending on system-specific behaviors
when possible.

 

[Nobody]

clear() is defined on Unix in curses.h

If you just need to clear the screen, linking against curses is overkill.
system("clear") is the way to go here (and the usual warnings about
system() don't really apply here).

As for portability: my inclination would be to rely upon a macro
containing the command, and set it in a config.h file, or set it in the
Makefile and pass it via -D. That allows for passing an absolute path, or
an alternate command if a particular system doesn't have "clear" (or if
it's broken).

 

[Ian Collins]

If you just need to clear the screen, linking against curses is overkill.
system("clear") is the way to go here (and the usual warnings about
system() don't really apply here).

Why is using a library function "overkill" compared to spawning a new
process just to clear the screen?

 

[Keith Thompson]

Why is using a library function "overkill" compared to spawning a new
process just to clear the screen?

Perhaps because curses tends to be used by programs that need
complete control over the screen, including keeping track of what
character appears at every position, whereas clearing the screen
is a much simpler operation.

The time it takes to spawn a process isn't likely to be significant.

 

[Nobody]

Why is using a library function "overkill" compared to spawning a new
process just to clear the screen?

Because linking creates a hard dependency upon the library. If the library
(or one of its dependencies) doesn't exist, the program fails to run.

Also, curses is a fairly heavyweight library which exerts a lot of
control over the terminal, and which isn't straightforward to use (e.g.
you have to install signal handlers to ensure that the terminal state is
restored if the process is suspended or terminated abnormally).

If you only need to write escape/control sequences in a portable manner,
you're better off using termcap/terminfo to determine the appropriate
sequences. However, there are a lot of portability issues here. E.g.
the choice of the termcap or terminfo database may be coupled to the
choice of the termcap or terminfo API, or it may be orthogonal. Some
systems separate the terminfo API into a separate libtinfo, on others it's
only available via the curses library.

 

[Phil Carmody]

Perhaps because curses tends to be used by programs that need
complete control over the screen, including keeping track of what
character appears at every position, whereas clearing the screen
is a much simpler operation.

The time it takes to spawn a process isn't likely to be significant.

What if the spawning of the process will cause cgroups to notify
a user-space agent which will then potentially do re-jigging of
other processes properties? You're context switching all over the
place unnecessarily.

However, one technique I've seen in the past is to use system() to
call 'clear' or whatever, but rather than letting what it produces
just go to the controlling terminal, it's been read into the C program
and cached. Then to actually clear the screen, you just print out
the cached sequence. That at least reduces your system()s to 1.

Phil

 

[Keith Thompson]

What if the spawning of the process will cause cgroups to notify
a user-space agent which will then potentially do re-jigging of
other processes properties? You're context switching all over the
place unnecessarily.

Yes, and? Does this cause measurable harm?

However, one technique I've seen in the past is to use system() to
call 'clear' or whatever, but rather than letting what it produces
just go to the controlling terminal, it's been read into the C program
and cached. Then to actually clear the screen, you just print out
the cached sequence. That at least reduces your system()s to 1.

Yes, I think I've used that myself.

 

[Phil Carmody]

Yes, and? Does this cause measurable harm?

Yeah. Can you see our Maemo bugzilla - if so, look at the bugs
assigned to me currently....

Phil

 

[Keith Thompson]

Yeah. Can you see our Maemo bugzilla - if so, look at the bugs
assigned to me currently....

I don't think I can; I'll have to take your word for it.