Thread: [eboard-devel] Announcement: 0.1.5
Brought to you by:
bergo
From: Felipe B. <be...@se...> - 2001-05-02 17:15:43
|
eboard 0.1.5 is out. The main changes are: - much better engine support, with support for generic engines and nice support for GNU Chess 4 and Sjeng. For info about engines see the new 'engines' section on the website - scripting and autologin support for FICS. - tab position and fonts can be configured. - better notation code ......................................................................... Felipe Paulo Guazzi Bergo - Free Software Developer (be...@se...) Personal Info and GPG Public Key: http://www.advogato.org/person/khazad Campinas - SP - Brazil - Earth * This isn't right. This isn't even wrong! - Wolfgang Pauli |
From: Daniel B. <dbu...@br...> - 2001-05-02 19:59:26
Attachments:
proto_xboard-fix.diff
|
On Wed, May 02, 2001 at 01:15:37PM -0400, Felipe Bergo <be...@se...> was heard to say: > - much better engine support, with support for generic engines > and nice support for GNU Chess 4 and Sjeng. For info about engines see > the new 'engines' section on the website Three cheers :) It doesn't seem to compile for me, though. I get the following errors in proto_xboard.cc: c++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c proto_xboard.cc proto_xboard.cc: In method `char * XBoardProtocolParser::xlateDialect(char *)': proto_xboard.cc:86: return to `char *' from `const char *' discards qualifiers proto_xboard.cc:87: return to `char *' from `const char *' discards qualifiers proto_xboard.cc:88: return to `char *' from `const char *' discards qualifiers proto_xboard.cc:90: return to `char *' from `const char *' discards qualifiers I'm not sure why g++ only complains about those particular lines -- I thought I know C++ pretty well, but it must be implicitly casting them or something. Anyway, the function really ought to return const char *, and the attached patch makes it do that. Daniel -- /-------------------- Daniel Burrows <dbu...@br...> --------------------\ | Will the last person to leave the Universe please | | turn off the lights and close the door? | \---- News without the $$ -- National Public Radio -- http://www.npr.org ----/ |
From: Daniel B. <dbu...@br...> - 2001-05-02 20:13:40
|
On Wed, May 02, 2001 at 03:59:14PM -0400, Daniel Burrows <dbu...@br...> was heard to say: > I know C++ pretty well, but it must be implicitly casting them or something. > Anyway, the function really ought to return const char *, and the attached > patch makes it do that. ..and then it dies because lots of other functions need char * instead of const char *. The following functions take char * and I think you should be able to just make them take a const char *, since they don't look like they need to modify their arguments. (note that this may need other functions to be changed to take a const char *, but all of them should be able to take it) - XBoardProtocolParaser::xlateDialect(char *) This just matches its argument against some patterns; no reason for it to be un-const. - Status::setText(char *) This just passes its argument to a GTK text widget; again, no need for const-ness. - OutputPane::append(char *, int, Importance) The implementation of this just makes a copy of the message and passes it to gtk_ftext_append -- no need that I see to modify its contents. - PatternMatcher::match(char *) As before, it doesn't need to modify its input (in fact, it just copies it into a list of characters (??) and then operates on that) so there's no reason to not declare the arguments to be const. Thanks, Daniel PS - wouldn't it have been easier to use std::string from the start? -- /-------------------- Daniel Burrows <dbu...@br...> --------------------\ | Whoever created the human body left in a fairly basic | | design flaw. It has a tendency to bend at the knees. | | -- Terry Pratchett, _Men at Arms_ | \-- Does your computer have Super Cow Powers? ------- http://www.debian.org --/ |
From: Felipe B. <be...@se...> - 2001-05-02 20:29:09
|
On Wed, 2 May 2001, Daniel Burrows wrote: Daniel, the problem here is compiler versions. I don't know what the GCC guys did, but newer GCCs have a lot of trouble between consts and non-consts. Can you check the man page for your compiler version whether there is a command-line switch to stop bugging about this ? I'm trying to fix the problems now. Using std::string is even worse, I've had problems in the gBib project (gbib.seul.org), because in newer versions of GCC (2.96) there is no legal way to cast a const into non const. That means that every time one needs to call string::c_str, memory must be allocated to strcpy the results in, or the whole thing fails to compile (and since all GTK functions take char *, not const char *, passing text to the widgets requires memory allocation) The patch you sent in the previous mail throws up new warnings in my compiler (egcs 2.91.66) I don't know what is going on with GCC, but it seems that the only legal way to cast const to non-const is using glibc functions like strcpy. I'll post news here when I have some. > On Wed, May 02, 2001 at 03:59:14PM -0400, Daniel Burrows <dbu...@br...> was heard to say: > > I know C++ pretty well, but it must be implicitly casting them or something. > > Anyway, the function really ought to return const char *, and the attached > > patch makes it do that. > > ..and then it dies because lots of other functions need char * instead > of const char *. The following functions take char * and I think you > should be able to just make them take a const char *, since they don't look > like they need to modify their arguments. (note that this may need other > functions to be changed to take a const char *, but all of them should be > able to take it) ......................................................................... Felipe Paulo Guazzi Bergo - Free Software Developer (be...@se...) Personal Info and GPG Public Key: http://www.advogato.org/person/khazad Campinas - SP - Brazil - Earth * Type in an 11-digit prime number to continue. |
From: Daniel B. <dbu...@br...> - 2001-05-02 21:00:16
|
On Wed, May 02, 2001 at 04:29:05PM -0400, Felipe Bergo <be...@se...> was heard to say: > the problem here is compiler versions. I don't know what the GCC guys did, > but newer GCCs have a lot of trouble between consts and non-consts. They don't have trouble with it in a bug-sense; they implement the language spec correctly. Assigning const to non-const is incorrect. This means that code which does this is buggy, even if some C++ compilers happen to compile it (g++ << 2.95 is not exactly a model of standards compliance :) ) > Can you check the man page for your compiler version whether there is a > command-line switch to stop bugging about this ? I can't find one in the g++ info page or the g++ manpage. > I'm trying to fix the problems now. Using std::string is even worse, I've > had problems in the gBib project (gbib.seul.org), because in newer > versions of GCC (2.96) there is no legal way to cast a const into non > const. That means that every time one needs to call string::c_str, memory > must be allocated to strcpy the results in, or the whole thing fails to > compile (and since all GTK functions take char *, not const char *, > passing text to the widgets requires memory allocation) Hmm, is that true? void (* insert_text) (GtkEditable *editable, const gchar *text, gint length, gint *position); that's with GTK+ 1.2.10. Every instance of "char" I can find in the GTK header files is const. Maybe earlier versions are different, in which case it gets ugly. > The patch you sent in the previous mail throws up new warnings in my > compiler (egcs 2.91.66) Yeah, there are other places where you have to do this if you change it in one place. If you want to do a really gross hack, there's a way to cast const char * to char *, called const_cast. Eg, you could do "const_cast<char *>(someptr)". This is really ugly, though, is somewhat obscure (I had to look it up to get the exact syntax) and is (according to my copy of Stroustrop) "not guaranteed to give a single predictable result on all implementations. (you might be able to do a C-style cast, too; eg, "(char *) (someptr)". I don't like abusing the language, but..) Daniel -- /-------------------- Daniel Burrows <dbu...@br...> --------------------\ | We are Debian of Borg. | | You will be packaged. | | Resistance is futile. | \------------- Got APT? -- Debian GNU/Linux http://www.debian.org ------------/ |