Hexadezimal

CJosef schrieb:

Erkennt er nicht? Hmmm ... welchen Compiler hast du?
Bei mir ist die Funktion in stdlib.h deklariert.
Vllt. ist es bei dir eine andere Headerdatei.

Ich benutze gcc auf Linux. Scheint es nicht zu geben. Gibt es eine andere Alternative für itoa?

SeppJ

canonflux schrieb:

Gibt es eine andere Alternative für itoa?

Warum lernst du denn programmieren? Juckt es dich nicht in den Fingern, das selber zu schreiben? Ist nicht schwer. Ich hätte es dir hier längst vorgemacht, wenn ich nicht der Meinung wäre, dass du ohne Komplettlösung wesentlich mehr lernen würdest. Hier ein Tipp, um die einzige Schwierigkeit (die Mischung aus Zahlen und Buchstaben) zu überwinden:

const char* ziffern = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

// Somit gilt:
ziffern[0] == '0';
ziffern[5] == '5';
ziffern[10] == 'A';
ziffern[16] == 'G';

rkhb

canonflux schrieb:

Ich benutze gcc auf Linux. Scheint es nicht zu geben. Gibt es eine andere Alternative für itoa?

Hier gibts ein paar Anregungen:

http://www.jb.man.ac.uk/~slowe/cpp/itoa.html

viele grüße
ralph

CJosef

rkhb schrieb:

canonflux schrieb:

Ich benutze gcc auf Linux. Scheint es nicht zu geben. Gibt es eine andere Alternative für itoa?

Hier gibts ein paar Anregungen:

http://www.jb.man.ac.uk/~slowe/cpp/itoa.html

viele grüße
ralph

Das sind Komplettlösungen

CJosef

char* uitoa ( unsigned number, char* buf, int base )
{
	char digits[] = "0123456789ABCDEFGHIJLKMNOPQRSTUVWXYZ";
	char stack [ 256 ];
	int i = 0, j = 0;
	while ( number )
		stack [ i++ ] = digits [ number % base ], number /= base;
	buf [ i ] = 0;
	while ( i > 0 )
		buf [ j++ ] = stack [ --i ];
	return buf;
}

int main ( void )
{
	char buf [ 256 ];
	unsigned base, number;
	if ( 1 == scanf ( "%u", &number ))
		for ( base = 2; base < 37; base++ )
			printf ( "%s(%u)\n", uitoa ( number, buf, base ), base );
	return 0;
}

http://ideone.com/0Hosqk
:p
Edit:
Schöner wäre es wohl, die Puffer so zu deklarieren:

char stack [ sizeof ( unsigned ) * CHAR_BIT ];
char buf [ sizeof ( unsigned ) * CHAR_BIT + 1 ];

Inzwischen bin ich von einigen Gurus dieses Forums heftig zusammengestaucht worden. Leider gibt es nicht einen konkreten Hinweis, was an den Programmen falsch ist.
Nur um den Beitragszähler täglich zu erhöhen, sollten keine solche Bemerkungen fallen.
Leider habe ich das Gefühl, dass einige Gurus noch wie im letzten Jahrtausend programmieren.

Es ist doch einfach, den Quelltext in andere Kompiler zu übertragen und auszuprobieren. Welche Fehlermeldungen gibt es dann? In welchen Situationen funktionieren die Programme nicht.

Hier also mein Profil:

Ich setze Visual Studio C und C++ ein. Ich schalte bewusst bei allen Programmen die Kompilerschalter zwischen beiden Varianten hin- und her.

Ich beseitige alle Warnungen, auch diejenigen, die mir ein Casting bei malloc, calloc, realloc usw. empfehlen.

Ich versuche meine Programme insbesondere an den Intervallgrenzen zu testen.

Ich benutze (hoffentlich) immer die neuen, gesicherten Funktionen mit dem Postfix _s, also printf_s, scanf_s, strcpy_ und wie sie alle heißen (natürlich in der Norm verzeichnet).

Ich arbeite immer mit der Angabe der Standardströme, um beispielsweise zwischen stdout und stderr sauber zu trennen.

Ich würde gerne zum Beispiel wissen, warum alle Einsender sofort zusammengestaucht werden, wenn sie malloc casten. Meine Gründe für ein sauberes Casting sind:

1. Mein Kompiler warnt mich sinnvollerweise.
2. C ist eine (angeblich) typsichere Sprache. void * ist doch alles, also ein großer Speichermatsch.
3. Ich gebe mit dem Casten dem Kompiler bereits grundlegende Fehler beim Übersetzen zu erkennen.
4. Die OOP hat bewusst die "erweiterte Typkompatibilität" eingeführt, um das Casten zwischen verschiedenen Hierarchieebenen zu erlauben.
5. C versucht "krampfhaft" diese Fähigkeiten durch "typlose" Zeiger zu simulieren. Das muss kein Anfänger lernen.
6. Moderne Sprachen wie Java und C# haben es als große Errungenschaft (ich glaube so um 2003) gepriesen, dass sie jetzt typsichere, generische Datentypen wie Listen usw. eingeführt haben.

gigg

Waldschrat schrieb:

Ich würde gerne zum Beispiel wissen, warum alle Einsender sofort zusammengestaucht werden, wenn sie malloc casten.

http://www.c-plusplus.net/forum/viewtopic.php?t=206606

CJosef

Waldschrat schrieb:

Ich benutze (hoffentlich) immer die neuen, gesicherten Funktionen mit dem Postfix _s, also printf_s, scanf_s, strcpy_ und wie sie alle heißen (natürlich in der Norm verzeichnet).

Welche Norm soll das sein, die Microsoft'sche Norm?

Bitte, bitte vor dem Tippen das Gehirn einschalten!!

N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x Seiten 290ff

Reicht das jetzt?

Was soll denn das ständige Unter-den_Gürtel schlagen, nur weil man einen Beitrag nicht versteht?

CJosef

Waldschrat schrieb:

N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x Seiten 290ff
Reicht das jetzt?

Ich hatte dir schon in einem anderen Thread geschrieben, dass in meinem Draft die _s Funktionen nicht drin stehen.
(Jetzt weiß ich, das er nicht komplett ist :D, keine Ahnung wo ich den mal runtergeladen hatte.)
Hättest du also deinen eigenen Rat befolgt und dein Gehirn vor dem Tippen eingeschaltet, dann würdest du aus obigem Grunde die Frage

CJosef schrieb:

Welche Norm soll das sein, die Microsoft'sche Norm?

als eine ganz normale Frage ansehen.
Microsoft baut nun einmal hier und da Features ein, die nicht standardkonform sind.
Das hat nichts mit ohnmächtig werden zu tun ( bezieht sich auf den anderen Thread ).

Waldschrat schrieb:

Was soll denn das ständige Unter-den_Gürtel schlagen, nur weil man einen Beitrag nicht versteht?

Also, was gibt es da nicht zu verstehen?
Und wieso ständig?
Warum fühlst du dich schon wieder so angepisst?
Das war eine normale Frage!
Okay, Mr. Waldschrat?