[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: color in subwindows

From: D. Stimits
Subject: Re: color in subwindows
Date: Mon, 16 Jun 2003 20:46:46 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018

Thomas Dickey wrote:

> On Mon, Jun 16, 2003 at 05:34:32PM -0600, D. Stimits wrote:
> >Thomas Dickey wrote:
> >
> >
> >>On Mon, Jun 16, 2003 at 05:05:30PM -0600, D. Stimits wrote:
> >>
> >>
> >>>I'm trying to use wbkgd(), with a different wbkgd() in different
> >>>subwindows, recursively. These are also inside of a panel. So I might
> >>>have a panel with a subwindow that has a border, and a useful subwindow > >>>inside of the border; this in turn might have a temporary "pop up" style
> >>>subwindow inside of it, and I want to set wbkgd() separately for each
> >>>subwindow. Unfortunately, I seem to be doing something wrong, and the
> >>>final wbkgd() (although called for the specific subwindow and not for
> I don't know - part of the answer is that we're trying to be compatible
> with other implementations of curses, and what you're talking about is
> a detail that I don't recall having been well-tested. From my standpoint,
> I'd like to have a small test program that I could compare with Solaris
> curses, and see that it's not doing what you want. If there's a difference > at that level, I'll try to fix it. Otherwise, it's a matter of seeing how
> to achieve the effect you're working on within the existing design (I can
> try to offer advice on that).

I'm still experimenting with this, I'm convinced I'm doing something wrong.

> >PS: What are the chances that the wprintw family can be fixed to keep
> >the fmt const char* instead of just char*? I know curses.h says they are
> >const, but the actual functions are throwing the const away (according
> that seems to be a matter of interpretation.  I added an extension (an
> option to the configure script) which compiles-in "const" in the places
> where I thought it should have been.  But that's not compatible with
> X/Open curses - so it's not standard (it's fairly easy to construct
> a program that will then compile only with ncurses - I've done it
> accidentally more than once ;-).

Basically, if a parameter to a function is not going to be modified, it should be const in the function declaration. From the man page, and from the curses.h file, it claims it is const already for the fmt parameter:

   int printw(const char *fmt, ...);
   int wprintw(WINDOW *win, const char *fmt, ...);
   int mvprintw(int y, int x, const char *fmt, ...);
   int mvwprintw(WINDOW *win, int y, int x, const char *fmt, ...);
   int vwprintw(WINDOW *win, const char *fmt, va_list varglist);
   int vw_printw(WINDOW *win, const char *fmt, va_list varglist);

However, the library file itself did not have const in the actual implementation. Making fmt const in the ncurses functions will not break or invalidate this against any other implementation at all, it can only help in cases where compilers enforce const, since ncurses does not alter the fmt argument anyway. Here is a sample that does nothing, but will fail to compile under g++, as the c_str() member of a std::string is const, and g++ does not like passing it to a non-const parameter:

// this file name: const_bug.cxx
// g++ -Wall -lcurses const_bug.cxx -o bug
// NOTE: std::string member c_str() returns a const char*
// which is NULL terminated C-style string.
// This will fail with the following, because curses.h
// prototypes are being redefined (as macros or some dynamic
// code generation scheme) with a missing
// "const" and simply uses "char*" not "const char*":
// > g++ -Wall -lcurses const_bug.cxx -o bug
//   const_bug.cxx: In function `int main ()':
//   const_bug.cxx:26: cannot convert `const char *' to `char *' for
//   argument `4' to `mvwprintw (WINDOW *, int, int, char *, ...)'

#include <string>

extern "C"
#include <curses.h>
#include <unistd.h>

int main ()
    WINDOW* win;

    initscr ();
    cbreak ();

    win = newwin (0, 0, 0, 0);
    std::string msg = "window";

    mvwprintw (win, 1, 1, msg.c_str ());
    wrefresh (win);
    sleep (3);

    return 0;

> Some people (including some packagers) simply turn on the const because
> they want to appease g++ -Wall.  For packagers - that's a bad idea, since
> it creates a ripple effect with people having trouble porting to/from
> other systems.

In this case there should be no ripple effect (unless you consider fewer errors and warnings from compilers that check correct "const-ness"). Having the fmt parameter match the man page will simply guarantee to a compiler what we already know is true, that the fmt parameter is not being modified by calling the function. I pretty much consider a C compiler broken if when I pass a const* to a function, and the declaration is non-const, that the compile succeeds. It is historical baggage that no error occurs until a run time attempt to alter a const value, rather than failing at compile time. As is, the curses.h file is pretty useless, as the actual implementation is throwing out the const that is declared in the header file.

D. Stimits, stimits AT attbi DOT com

> (I'm aware that NetBSD curses simply makes some of those "const", having
> gotten an uninformed opinion from someone at X/Open, but they didn't
> make the changes as systematically as I did, and the opinion was apparently
> by someone who doesn't program ;-)
> >to the g++ compiler, which rejects 100% of passing a const to a
> >non-const argument position). Ncurses is not altering these values, but
> >merely having it declared as non-const breaks compiles, so I have to do
> >a strdup(std::string.c_str()) and passing the dup to all print functions
> >taking char*, then deallocating the dup. The generated functions are
> >discarding const.
> >
> >
> >>When using this routine, it is nec-
> >>      essary  to call touchwin or touchline on orig before call-
> >>      ing wrefresh on the subwindow.
> >>
> >
> >
> >
> >
> >_______________________________________________
> >Bug-ncurses mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/bug-ncurses

reply via email to

[Prev in Thread] Current Thread [Next in Thread]