Re: color in subwindows

[D. Stimits]

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