- GiNaC-devel - ginac.de

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

[PURRS-devel] Annoying warning again
by Roberto Bagnara 06 Aug '02

06 Aug '02

Dear all, there is a warning about an unused parameter due to line 84 in basic.h (GiNaC 1.0.10): virtual void destroy(bool call_parent) { } Seeing this warning over and over again makes developing with GiNaC a real pain. Therefore I suggest replacing the above line with the following: virtual void destroy(bool /* call_parent */) { } Thanks a lot. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PURRS-devel mailing list PURRS-devel(a)cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/purrs-devel

2 1

PATCH AGAIN: remove_all() method added to the containers
by Roberto Bagnara 05 Aug '02

05 Aug '02

Hi there, I am reiterating the following request because of the obvious reasons of functionality and efficiency. Moreover, the issue of C++ ABI compatibility (which suggested not to apply the given patch) seems now to be completely pointless: GCC 2.95 is ABI-incompatible with GCC 3.0, which is ABI-incompatible with GCC 3.1, which will almost certainly be ABI-incompatible with GCC 3.3. Moreover, hasn't the time of GiNaC 1.1 come yet? All the best Roberto Dear all, of course there are several ways in the current version of GiNaC to erase all the elements from a GiNaC container. However, as far as I can tell, they are either obscure or inefficient or both (removing one element at a time is inefficient, assigning from an empty container is obscure and still measurably inefficient and so forth). Removing all the elements of a container is a very common operation and forcing users to resort to kludges is, I believe, not a very good idea. Moreover, not providing the right method for a common operation reduces the implementor's latitude for future choices (what if you would like to use a different representation for containers? What if this new representation is such that the user's kludges for erasing all the elements are seriously inefficient?) You don't want your users to ask you whether _today_ it is best to clear all the elements using the technique A or by the tecnique B, right? It is not by chance that all the STL containers have a clear() method. Enough for advocacy, please find below a patch adding a remove_all() method to the containers. I feel that the name "remove_all" fits well with the others. The patch allows `make check' to complete successfully and the documentation looks good. I have been careful to follow your coding style. Please let me know if I haven't been successful and I will submit a revised patch. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it diff -rcp GiNaC-1.0.3.orig/doc/tutorial/ginac.texi GiNaC-1.0.3/doc/tutorial/ginac.texi *** GiNaC-1.0.3.orig/doc/tutorial/ginac.texi Fri Dec 21 12:38:03 2001 --- GiNaC-1.0.3/doc/tutorial/ginac.texi Sat Jan 19 18:22:28 2002 *************** canonical form. *** 1193,1198 **** --- 1193,1199 ---- @cindex @code{prepend()} @cindex @code{remove_first()} @cindex @code{remove_last()} + @cindex @code{remove_all()} The GiNaC class @code{lst} serves for holding a @dfn{list} of arbitrary expressions. These are sometimes used to supply a variable number of *************** and @code{prepend()} methods: *** 1230,1242 **** // ... @end example ! Finally you can remove the first or last element of a list with @code{remove_first()} and @code{remove_last()}: @example // ... l.remove_first(); // l is now @{x, 2, y, x+y, 4*x@} l.remove_last(); // l is now @{x, 2, y, x+y@} @} @end example --- 1231,1251 ---- // ... @end example ! You can remove the first or last element of a list with @code{remove_first()} and @code{remove_last()}: @example // ... l.remove_first(); // l is now @{x, 2, y, x+y, 4*x@} l.remove_last(); // l is now @{x, 2, y, x+y@} + @end example + + Finally, you can remove all the elements of a list with + @code{remove_all()}: + + @example + // ... + l.remove_all(); // l is now empty @} @end example diff -rcp GiNaC-1.0.3.orig/ginac/container.pl GiNaC-1.0.3/ginac/container.pl *** GiNaC-1.0.3.orig/ginac/container.pl Wed Dec 19 11:54:04 2001 --- GiNaC-1.0.3/ginac/container.pl Sat Jan 19 18:19:14 2002 *************** protected: *** 250,255 **** --- 250,256 ---- public: virtual ${CONTAINER} & append(const ex & b); virtual ${CONTAINER} & remove_last(void); + virtual ${CONTAINER} & remove_all(void); ${PREPEND_INTERFACE} ${SORT_INTERFACE} protected: *************** ${CONTAINER} & ${CONTAINER}::remove_last *** 547,552 **** --- 548,560 ---- return *this; } + ${CONTAINER} & ${CONTAINER}::remove_all(void) + { + ensure_if_modifiable(); + seq.clear(); + return *this; + } + ${PREPEND_IMPLEMENTATION} ${SORT_IMPLEMENTATION} _______________________________________________ PURRS-devel mailing list PURRS-devel(a)cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/purrs-devel

2 1