🚀 go-pugleaf

"R.G.A.M." <rgam1989@gmail.com> writes:

> Buenas a todos.
>
> Como un desaf�o, tengo en mente crear una clase que pueda almacenar un
> entero de una cantidad indefinida de d�gitos. Para ello, me valdr� de
> un array din�mico, que contendr� en cada elemento un "int". Cada valor
> "int" podr� tener a lo m�s un d�gito menos que la mayor cantidad de
> d�gitos que soporta el tipo en su totalidad, en el sistema de
> numeraci�n decimal.

�Porqu� tan complejidad?

Es mejor poner un solo d�gito en cada int, en base (1+MAX_INT).


Por ejemplo, en base diez:

C/USER[100]> (decompose-base 1234 10)
(4 3 2 1)


Lo mismo en base 2^32:

C/USER[101]> (decompose-base 5000000000000000000000000 (expt 2 32))
(620756992 2332688548 271050)

Hay m�s de quatro mil milliones de digitos diferentes, entre los
cuales estos tres digitos: "620756992" "2332688548" "271050", pero
vale.

Hacer as� simplifica los algoritmos: son los mismos que aplicamos
usualmente digito por digito.

> Mi problem�tica radica en que quiero sobrecargar el operador std::cin
> para esta clase, y en lo posible me gustar�a evitar trabajar con
> cadenas (sean "char" o "string"). �Existe alguna forma de adaptar al
> b�fer para ello? N�tese que debo poder calcular la cantidad de
> d�gitos, o vaciar el b�fer en sentido contrario al corriente.

Ahora, es verdad que un formato "binario" como el que propongo aqu�
hace mas dificil(*) la conversion en base diez, comparado a un formato
"BCD" (Binary Coded Decimal) como el que quieres usar.  La question es
si haces m�s entrada/salidas que calculos.

(*) es decir, la conversion de base no es dificil, pero necesita un
gran n�mero de divisiones o multiplicaciones.   


> Crear el constructor de la clase (asignando directamente un valor
> num�rico al declarar la variable), seg�n mi parecer, es un problema
> similar. Tambi�n me gustar�a ser guiado para ello.
>
> Agradecer� toda ayuda que puedan ofrecerme.

Tanbien se podria usar gmp http://gmplib.org/
http://www.gnu.org/software/gmp/manual/html_node/Language-Bindings.html
Pues, es una soluci�n al problema, pero te gasta el desaf�o...

-- 
__Pascal Bourguignon__