- GiNaC-devel - ginac.de

Re: [PURRS-devel] Re: One last time: annoying warning
by Gabriel Dos Reis 29 Sep '02

29 Sep '02

Roberto Bagnara <bagnara(a)cs.unipr.it> writes: [...] | > Given the tone you're taking | | Tone? Which tone? I am simply defending a point of view that I | believe is quite reasonable. Telling people they are irrespectful to users, when it is a matter of style isn't something I consider "reasonable" for any reasonable definition of "reasonable. [...] | > and the lack of recognizing actual facst, | | Facts? Which facts? I was offered no facts: you and others have | simply stated that your very personal taste is against things like | | void foo(int /* i */) { } | | which I don't believe is a fact. OK, you offered the fact that | the GNU standard library does not always use the form (1) above: | this is a fact. Well, you need to agree with yourself when a fact was given or not. Saying no, then yes isn't helpful. [...] | (I wonder if, | to be consistent, you should also advocate the removal of the unused | argument warnings from g++.) As a g++ user, probably yes. *I* never saw its usefulness. But I understand that other peolpe do use it, and since I don't use it in my own code its mere presence in the compiler doesn't bother me. | I also do not consider a fact the suggestion that we should write | a script to filter out warnings for each compiler we use, perhaps | with variants for different compilation flags, perhaps changing | the scripts to accommodate changes in GiNaC header. First I never qualify that as a *fact* -- so I don't understand why you're bringing it in the first place in this part of your reply. Now, given the wide variety of kinds of noise^Wdiagnostics different compilers output, I do consider that suggestion a good one. [...] | Perhaps the implicit suggestion we have been given is to stop | compiling with extra warnings, but we don't want to do it. | We did not invent the extra warnings options. Not just because you didn't invent them means you ought to use them. [...] | I keep my fingers crossed | in the hope that the GCC developers will resist the temptation | of screwing their header files in the name of abstract style | considerations that do not take the user's needs into account. Well, the header files were screwed (IMO) many times in the name of "abstract style" considerations -- I can't say those modifications were actually taking any input from users. You can look in the archives to see the logs. We also use #pragma GCC system_header to make sure no warning will be output (with some set of options) just because someone thought a given abstract style ought to be diagnosed. Just learn to use the tool. -- Gaby

2 1

Re: One last time: annoying warning
by Gabriel Dos Reis 28 Sep '02

28 Sep '02

Roberto Bagnara <bagnara(a)cs.unipr.it> writes: | Gabriel Dos Reis wrote: | > Roberto Bagnara <bagnara(a)cs.unipr.it> writes: | > | > [...] | > | > | What is important is that the GCC people taking care of the standard | > | library do the right thing. Since they know that someone may very | > | legitimately wish to compile with, e.g., -W -Wall, they write code | > | like | > | | > | virtual iter_type | > | do_get_time(iter_type __s, iter_type /*__end*/, ios_base&, | > | ios_base::iostate& /*__err*/, tm* /*__t*/) const | > | { return __s; } | > | > I'm one of those GCC people taking care of the library and I can | > assure you I don't particularly appreciate that style (like some other | > things in the V3 STYLE). So, I would say that you should be very | > careful in drawing conclusions from things you might read in the V3 | > source code -- not every one has the same idea of the styles to be used. | | It is not a matter of style: it is a matter of respect for the users. I guess it depends on what you define to be irrespectful for users. Given the tone you're taking and the lack of recognizing actual facst, I guess there is no much interest in continuing this thread. [...] | Huh? Looks like a copy-and-paste error... No. Just go and check out. -- Gaby

2 1

Re: One last time: annoying warning
by Gabriel Dos Reis 27 Sep '02

27 Sep '02

Roberto Bagnara <bagnara(a)cs.unipr.it> writes: [...] | What is important is that the GCC people taking care of the standard | library do the right thing. Since they know that someone may very | legitimately wish to compile with, e.g., -W -Wall, they write code | like | | virtual iter_type | do_get_time(iter_type __s, iter_type /*__end*/, ios_base&, | ios_base::iostate& /*__err*/, tm* /*__t*/) const | { return __s; } I'm one of those GCC people taking care of the library and I can assure you I don't particularly appreciate that style (like some other things in the V3 STYLE). So, I would say that you should be very careful in drawing conclusions from things you might read in the V3 source code -- not every one has the same idea of the styles to be used. [...] | (stl_alloc.h, lines 120 ff.), ..., you will find hundreds of examples | like that. Naturally, I am really thankful they do that. Naturally you'll also see the opposite: >From stl_algobase.h: template<typename _InputIter, typename _OutputIter> inline _OutputIter __copy(_InputIter __first, _InputIter __last, _OutputIter __result, input_iterator_tag) template<typename _InputIter, typename _OutputIter> inline _OutputIter __copy(_InputIter __first, _InputIter __last, _OutputIter __result, input_iterator_tag) and so one. -- Gaby

2 1

One last time: annoying warning
by Roberto Bagnara 27 Sep '02

27 Sep '02

Dear GiNaC developer, I was composing my fourth message about the the unused parameter in line 84 in basic.h (GiNaC 1.0.11) and about the trivial and 100% safe patch I have proposed to fix it. In another window I was creating a new CVS repository for GiNaC so that we could avoid patching your releases manually over and over again. I was lucky enough to have the inspiration to double check the archives of ginac-devel(a)ginac.de before hitting the "send" button. Having discovered that I was not completely ignored during all this time, I had a chance to erase a message you would not have liked. (I don't think replies to messages sent to ginac-devel should only be sent to the list, but anyway I have now subscribed it: from what I can see this entitles me to receive also some more spam). I would now like to discuss the issue on purely technical grounds. The point is that we need to replace the following line (84) of basic.h virtual void destroy(bool call_parent) { } with the following virtual void destroy(bool /* call_parent */) { } We cannot follow the advice of Christian Bauer (*) to tell the compiler not to warn about unused parameters for the simple reason that we find these warnings very useful in our development work. In contrast, I believe the patch I am repeatedly proposing: 1) complies with the C++ standard; 2) does not cause problems with any the versions of all the C++ compilers we know of; 3) preserves the information about what the bool parameter is; 4) is good both for users that run with warnings on and for those switching them off. I would be very grateful if someone could tell me what is so wrong with it that we have to set up a paraller CVS repository for GiNaC. Thanks a lot Roberto (*) "I suggest turning off that compiler warning. Yes, I'm serious." -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

3 8

Re: One last time: annoying warning
by Gabriel Dos Reis 26 Sep '02

26 Sep '02

"Richard B. Kreckel" <kreckel(a)zino.physik.uni-mainz.de> writes: [...] | I would bet that the GCC developers would agree with him on this | particular unused parameter issue -- but this is speculative. It depends on the GCC developer :-) *I* certainly agree with him; but I can only speak for myself. -- Gaby

1 0

Neue Version
by Jens Vollinga 18 Sep '02

18 Sep '02

1.0.11 da ist.

1 0

Hello. r u still alive?
by Chris Dams 18 Sep '02

18 Sep '02

Hello, I don't see any reactions on my previous post "same problem again plus a few others". Did noone read it? It contains *three* fixes of what I think are bugs. Don't the devellopers care that a^(-1/2) sometimes gets printed in C-source as if it were a^(1/2)? Looking forward to hearing anything! Greetings, Chris Dams

2 3

strange segfault...
by Sheplyakov Alexey 15 Sep '02

15 Sep '02

Consider a very simple program: // beginning of file crush_it.cxx #include <iostream> #include <vector> using namespace std; #include <ginac/ginac.h> using namespace GiNaC; int main(int argc,char* argv[]) { vector<symbol> sv(3); sv[0] = symbol("x"); sv[1] = symbol("y"); sv[2] = symbol("z"); cout << "All is OK " << "\n"; cout << sv[0] << " "; cout << sv[1] << " "; cout << "All is OK again" << "\n"; return 0; // segfault here! } // end of file crush_it.cxx And here is gdb session: Breakpoint 3, main (argc=1, argv=0xbffffb24) at crush_it.cxx:21 21 return 0; (gdb) bt #0 main (argc=1, argv=0xbffffb24) at crush_it.cxx:21 (gdb) next Program received signal SIGSEGV, Segmentation fault. 0x403d27fe in free () from /lib/libc.so.6 (gdb) bt #0 0x403d27fe in free () from /lib/libc.so.6 #1 0x403d26d3 in free () from /lib/libc.so.6 #2 0x4032d6b4 in __builtin_delete () from /usr/lib/libstdc++-libc6.2-2.so.3 #3 0x401e6c8d in GiNaC::symbol::destroy () from /usr/lib/libginac-1.0.so.0 #4 0x401ea110 in GiNaC::symbol::~symbol () from /usr/lib/libginac-1.0.so.0 #5 0x0804c0d7 in void destroy<GiNaC::symbol> (__pointer=0x805259c) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:43 #6 0x0804bfa1 in void __destroy_aux<GiNaC::symbol *> (__first=0x8052578, __last=0x80525e4) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:61 #7 0x0804bbfc in void __destroy<GiNaC::symbol *, GiNaC::symbol> (__first=0x8052578, __last=0x80525e4) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:73 #8 0x0804b85c in void destroy<GiNaC::symbol *> (__first=0x8052578, __last=0x80525e4) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_construct.h:78 #9 0x0804b881 in vector<GiNaC::symbol, allocator<GiNaC::symbol> >::~vector (this=0xbffffab0, __in_chrg=2) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_vector.h:266 #10 0x0804a4dd in main (argc=1, argv=0xbffffb24) at crush_it.cxx:21 I use Debian "sid", GiNaC 1.0.10 (installed from debs), g++ 2.95.4

2 1

Same problem again plus a few others.
by Chris Dams 28 Aug '02

28 Aug '02

Hello, Whoever reads this, have a look at my previous post. After this you are probably convinced that it is a good idea to change the line if (overall_coeff.info(info_flags::positive)) in add.cpp into if (overall_coeff.info(info_flags::positive) || is_a<print_csrc_cl_N>(c)) After this have a look at the file mul.cpp. This contains the lines if (is_a<print_csrc_cl_N>(c)) c.s << "recip("; else c.s << "1.0/"; Question: Who closes the opening parenthesis of after the recip? Answer: I don't see anyone doing this. Furthermore it is not closed in my output. Next, try the following program #include <ginac/ginac.h> #include <iostream> using namespace std; using namespace GiNaC; int main() { symbol a("a"),b("b"); numeric half=numeric(1)/2; (power(a,-half)*b).print(print_csrc(cout)); cout << endl; return 0; } The result at my place is b*pow(a,(1.000000e+00/2.000000e+00)) I would have expected a minus sign in the exponent. A patch is attached to this mail that should fix these two problems in mul.cpp. Also mul.cpp seems to be written before the info_flag negint existed. The path also patches mul.cpp to use this flag. Have a nice day, Chris Dams

1 0

problem with print_csrc_cl_N --> solved?
by Chris Dams 27 Aug '02

27 Aug '02

Hello everybody, Let's write something about GiNaC in order to improve the GiNaC/spam ratio in this mailing list a bit. I found that the following program #include <ginac/ginac.h> #include <iostream> using namespace std; using namespace GiNaC; int main() { symbol a("a"),b("b"); (-2*a-2*b).print(print_csrc_cl_N(cout)); cout << endl; return 0; } gives as output: cln::cl_F("-2.0")*bcln::cl_F("-2.0")*a This does not compile since there should be a + between the b and the cln::cl_F. The problem disappears if I change the line if (it != itend && !(it->coeff.info(info_flags::negative) || (it->coeff.is_equal(_num1) && is_exactly_a<numeric>(it->rest) && it->rest.info(info_flags::negative)))) which occurs in the file add.cpp to if (it != itend && (is_a<print_csrc_cl_N>(c) || !(it->coeff.info(info_flags::negative) || (it->coeff.is_equal(_num1) && is_exactly_a<numeric>(it->rest) && it->rest.info(info_flags::negative))))) Now the output of the test program is cln::cl_F("-2.0")*b+cln::cl_F("-2.0")*a which compiles correctly. Greetings, Chris Dams

2 1