Hi again:
Can be overloaded the + and - operators to compile these silly lines:
cl_F a,b;
a=1*b;
a=1/b;
and some like these?
--
***************************************************************************
* Dr. Isidro Cachadiña Gutiérrez *
* Departamento de Física *
* Facultad de Ciencias *
* Universidad de Extremadura *
* 06071 Badajoz ( SPAIN ) *
* email: icacha(a)unex.es *
* Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 *
***************************************************************************
* Usuario Linux: 8569 *
* Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc *
***************************************************************************
2
4
More bugs.
by Isidro Cachadiña Gutiérrez
14 Dec '04
14 Dec '04
Hi again:
Another silly program...
#include <iostream>
#include <cln/lfloat.h>
#include <cln/lfloat_io.h>
using namespace cln;
int main(int argc, char **argv)
{
default_float_format=float_format(100);
cl_LF a,b,c;
b="1e-60";
a="1.0";
c=a+b;
std::cerr << "c=" << c << std::endl;
c=c-a;
std::cerr << "c=" << c << std::endl;
}
And the outputs are 1.0L and 0.0L ¿What happen with the
default_float_format?. If I write a="1.00000000000000000000000 ..." (100
zeros here) I obtain the same result, then b is lost somewhere.
More, when b about < 1e-20 then it is lost. Maybe an error in the
conversion?
Bye.
--
***************************************************************************
* Dr. Isidro Cachadiña Gutiérrez *
* Departamento de Física *
* Facultad de Ciencias *
* Universidad de Extremadura *
* 06071 Badajoz ( SPAIN ) *
* email: icacha(a)unex.es *
* Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 *
***************************************************************************
* Usuario Linux: 8569 *
* Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc *
***************************************************************************
Hi!
Ralf: I take this discussion to the mailing list in the hope that somebody
there might have an idea.
All others: Ralf and I were discussing a small experimental patch (see
attachment) that balances all operator new and delete in order to please
certain compilers. In particular, I added many no-op operator placement
deletes. It also added some unimplemented declarations of private
operator delete(void*) member functions to classes that had unimplemented
private operator new(size_t).
That patch had no effect on the code generated by GCC. However, the Intel
compiler complained abaout four missing symbols:
On Fri, 3 Dec 2004, Ralf Wildenhues wrote:
> * Richard B. Kreckel wrote on Thu, Dec 02, 2004 at 10:17:20PM CET:
> > On Thu, 2 Dec 2004, Ralf Wildenhues wrote:
> > > cl_SV_ringelt.o: cln::cl_SV_inner<cln::_cl_ring_element>::operator delete(void*)
> > > cl_SV_number.o: cln::cl_SV_inner<cln::cl_number>::operator delete(void*)
> > > cl_GV_number.o: cln::cl_GV_inner<cln::cl_number>::operator delete(void*)
> > > cl_GV_I.o: cln::cl_GV_inner<cln::cl_I>::operator delete(void*)
> >
> > Bitte schick' mir mal die drei Dateien zum Disassemblen.
>
> Hier sind die vier. :-)
Disassembling the four offending objects established the following
(linear) call-graphs (not every symbol could be demangled by GNU objdump):
cln::cl_svector_ringelt_destructor(cln::cl_heap*)
cln::cl_heap_SV<cln::_cl_ring_element>::~cl_heap_SV()
_ZN3cln10cl_heap_SVINS_16_cl_ring_elementEED9Ev
cln::cl_SV_inner<cln::_cl_ring_element>::~cl_SV_inner()
_ZN3cln11cl_SV_innerINS_16_cl_ring_elementEED9Ev
cln::cl_SV_inner<cln::_cl_ring_element>::operator delete(void*)
cln::cl_svector_number_destructor(cln::cl_heap*)
cln::cl_heap_SV<cln::cl_number>::~cl_heap_SV()
_ZN3cln10cl_heap_SVINS_9cl_numberEED9Ev
cln::cl_SV_inner<cln::cl_number>::~cl_SV_inner()
_ZN3cln11cl_SV_innerINS_9cl_numberEED9Ev
cln::cl_SV_inner<cln::cl_number>::operator delete(void*)
cln::cl_gvector_number_destructor(cln::cl_heap*)
cln::cl_heap_GV<cln::cl_number>::~cl_heap_GV()
_ZN3cln10cl_heap_GVINS_9cl_numberEED9Ev
cln::cl_GV_inner<cln::cl_number>::~cl_GV_inner()
_ZN3cln11cl_GV_innerINS_9cl_numberEED9Ev
cln::cl_GV_inner<cln::cl_number>::operator delete(void*)
cln::cl_gvector_integer_destructor(cln::cl_heap*)
cln::cl_heap_GV<cln::cl_I>::~cl_heap_GV()
_ZN3cln10cl_heap_GVINS_4cl_IEED9Ev
cln::cl_GV_inner<cln::cl_I>::~cl_GV_inner()
_ZN3cln11cl_GV_innerINS_4cl_IEED9Ev
cln::cl_GV_inner<cln::cl_I>::operator delete(void*)
The pattern is always the same, as is the code that triggers it. For
example in cl_GV_I.cc:
static void cl_gvector_integer_destructor (cl_heap* pointer)
{
(*(cl_heap_GV_I*)pointer).~cl_heap_GV_I();
}
What I find irritating is that the dtors call their objects' operator
delete(void*). Isn't that hazardous?
Regards
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
Hi all:
Are there any way to declare all variables with a number digits for example,
something like.
funcion_foo (DIGITS);
And then you are sure that all floating points variables are of number of
decimal digits given by DIGITS.
Thanks.
--
***************************************************************************
* Dr. Isidro Cachadiña Gutiérrez *
* Departamento de Física *
* Facultad de Ciencias *
* Universidad de Extremadura *
* 06071 Badajoz ( SPAIN ) *
* email: icacha(a)unex.es *
* Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 *
***************************************************************************
* Usuario Linux: 8569 *
* Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc *
***************************************************************************