int mit 8 Bit definieren

Sone

Swordfish schrieb:

hustbaer schrieb:

@@Swordfish
s.o.

Bitte etwas ausführlicher - stehe evtl. auf diversen Leitungen.

Nun habe ich aber das Problem, daß mein int8 z.B. con cout als char interpretiert wird.

P.S.: Zu genau diesem Problem habe ich bereits vor ner kleinen Weile nen Thread geöffnet.

volkard

Sone schrieb:

P.S.: Zu genau diesem Problem habe ich bereits vor ner kleinen Weile nen Thread geöffnet.

Fein. Und was fehlt?

hustbaer

Swordfish schrieb:

hustbaer schrieb:

@@Swordfish
s.o.

Bitte etwas ausführlicher - stehe evtl. auf diversen Leitungen.

uint8_t ist oft genug (fast immer?) ein Typedef auf unsigned char .
unsigned char wird von den Iostreams als Zeichen ausgegeben.
Der OP will aber einen Typen der als Zahl ausgegeben wird.
uint8_t ist also nicht der Typ den der OP will.

Sone

volkard schrieb:

Sone schrieb:

P.S.: Zu genau diesem Problem habe ich bereits vor ner kleinen Weile nen Thread geöffnet.

Fein. Und was fehlt?

Der Link.

Swordfish

...

Swordfish

...

Sone

Hier war der Code, den ich damals geschrieben habe (und überarbeitet, daher ist der im Thread "veraltet"), rausgekramt. Das ist Javas byte in C++

#include <istream>
#include <ostream>
#include <limits>

template<bool signed_>
struct base_byte
{
	typedef typename std::conditional<signed_, int8_t, uint8_t>::type underlying_type;

    base_byte(underlying_type t) noexcept:
	value(t) {}

	base_byte() = default;

	operator underlying_type&() noexcept { return value; }
	operator underlying_type() const noexcept { return value; }

	underlying_type value;
};

template<bool si,
         typename CharT,
	     typename Traits>
std::basic_ostream<CharT, Traits>& operator<<(std::basic_ostream<CharT, Traits>& os, base_byte<si> const& b)
{
    using namespace std;
	typename basic_ostream<CharT, Traits>::sentry se(os);
	if(se) try
    {
        ios_base::fmtflags baseflags = os.ios_base::flags() & os.ios_base::basefield;
        bool failed = use_facet<
                                num_put<CharT,ostreambuf_iterator<CharT,Traits> >
                               >(os.getloc()).put(os, os, os.fill(), os.basefield == ios_base::oct || os.basefield == ios_base::hex
        ? static_cast<long>(static_cast<uint8_t>(b.value))
        : static_cast<long>(b.value)).failed();
    }
    catch(...)
    {
        os.setstate( std::ios_base::badbit );
        if( os.exceptions() & ios_base::badbit )
            throw;
    }

	return os;
}

template<bool si,
         typename CharT,
	     typename Traits>
std::basic_istream<CharT, Traits>& operator>>(std::basic_istream<CharT, Traits>& is, base_byte<si>& byte)
{
    using namespace std;
	typename basic_istream<CharT, Traits>::sentry se(is);
	if(se) try
    {
        typedef num_get< CharT, istreambuf_iterator<CharT,Traits> > numget;
        ios_base::iostate err = ios_base::goodbit;
        long lval;
        use_facet< numget >(is.getloc()).get(is, 0, is, err, lval);

        using byte_t = typename base_byte<si>::underlying_type;

        if (lval < numeric_limits<byte_t>::min())
        {
            err |= ios_base::failbit;
            byte = numeric_limits<byte_t>::min();
        }
        else if (numeric_limits<byte_t>::max() < lval)
        {
            err |= ios_base::failbit;
            byte = numeric_limits<byte_t>::max();
        }
        else
            byte = static_cast<byte_t>(lval);
        is.setstate(err);
    }
    catch(...)
    {
        is.setstate( std::ios_base::badbit );
        if( is.exceptions() & ios_base::badbit )
            throw;
    }

	return is;
}

using byte          = base_byte<true >;
using signed_byte   = base_byte<true >;
using unsigned_byte = base_byte<false>;

hustbaer

Swordfish schrieb:

hustbaer schrieb:

Swordfish schrieb:

hustbaer schrieb:

@@Swordfish
s.o.

Bitte etwas ausführlicher - stehe evtl. auf diversen Leitungen.

uint8_t ist oft genug (fast immer?) ein Typedef auf unsigned char .
unsigned char wird von den Iostreams als Zeichen ausgegeben.
Der OP will aber einen Typen der als Zahl ausgegeben wird.
uint8_t ist also nicht der Typ den der OP will.
std::ostream & operator<<( std::ostream & os, std::uint8_t value )
{
	os << static_cast< unsigned >( value );
	return os;
}
Well!?

*schluck*

Würde ich micht nicht trauen.
Mittlerweile ist das schon SO lange so, dass ich mir gut vorstellen kann dass es JETZT massiv viel Code gibt der dadurch brechen würde.
Und den Bug mag ich dann nicht suchen.

Davon abgesehen finde ich es reichlich pervers. Der Grund dass das überhaupt funktioniert, ist, dass die char Stream-Insertion Operatoren der SCL Memberfunktionen sind. Wären sie freie Funktionen, wäre es ambiguous.
(Daher wäre ich auch nie auf die Idee gekommen dass man das so machen konnte. Ich wusste nämlich ehrlich gesagt weder dass es Memberfunktionen sind, noch dass der Aufruf aus diesem Grund auf einmal nichtmehr ambiguous ist. Wobei ich letzteres nicht im Standard nachgeschlagen habe, ich vertraue da einfach mal auf das was gcc-4.7.2 von ideone.com macht.)

Sone

gcc-4.7.2

Ach was? Ideone hat seinen Compiler endlich geupgraded?

krümelkacker

daishi schrieb:

ich benötige für ein kleies programm 8-Bit int's.

Es war auch erstmal nicht das Problem es über ein typedef zu machen.
typedef char int8;

Schlechte Idee. Da du das int8 und nicht uint8 nennst, gehe ich mal davon aus, dass du vorzeichenbehaftete Ganzzahlen haben willst. Schreibe

typedef signed char int8;

char und signed char sind wirklich zwei verschiedene Typen -- selbst wenn char bei dir vorzeichenbehaftet sein sollte -- wohingegen int und signed int nur Synonyme für einander sind.

daishi schrieb:

Nun habe ich aber das Problem, daß mein int8 z.B. con cout als char interpretiert wird.

Dein typedef ist ja auch nur ein Synonym für char. cout bekommt davon nichts mit.

daishi schrieb:

Wie kann ich mit einen 8 Bit datentyp definieren, der als Ganzzahlbehandelt wird?

Das Sinnvollste ist wohl, bei signed oder unsigned char zu bleiben und für die Ausgabe einen int-Wert explizit zu erzeugen:

signed char x = 23;
cout << int(x) << endl;

Alternativ kannst du schreiben:

struct int8
{
  signed char value;
  int8(int v) : value(v) {}
  operator int() const {return value;}
};

int main()
{
  int8 x = 23;
  cout << x << endl;
}

Sone

struct int8 
{ 
  signed char value; 
  int8(int v) : value(v) {} 
  operator int() const {return value;} 
}; 
  
int main() 
{ 
  int8 x = 23; 
  cout << x << endl; 
}

Wie soll das beim extrahieren funktionieren?
Daher ist mein Code damals so kompliziert geworden

Ethon

Leute, der Thread ist von 2006 und wurde von nem Troll ausgebuddelt ...

Schlitzauge

Frechheit, jetzt wird man schon als Troll beschimpft und abgestempelt.
Warum sollte man einen neuen Thread erstellen, wenn man zu einem bereits existenten Thread / Thema eine Frage hat?
Ich verstehe die Aufregung nicht??? C/C++ existiert gewiss nicht erst seit Gestern oder 2006. Damit haben selbst noch Threads von 2006 und früher ihre Gültigkeit, ergo sollte "ausbuddeln" hier legitim und angebracht sein...
Sonst meckern doch auch viele, dass immer wieder der selbe Thread aufs Neue eröffnet wird. Aber neee, erstma meckern...

Sone

Warum sollte man einen neuen Thread erstellen, wenn man zu einem bereits existenten Thread / Thema eine Frage hat?

Weil das selbstverständlich ist? Deine Frage hat mit dem konkreten Problem des Threads nichts zu tun. Wozu also zwei verschiedene Sachen in einen Thread packen? Damit es unübersichtlicher wird? Lieber jedem seines, dann wird es übersichtlicher.

P.S.: Dein Vorschlag war so schlecht, er könnte glatt von einem Troll sein.

Schlitzauge

P.S.: Dein Vorschlag war so schlecht, er könnte glatt von einem Troll sein.

Das kann man so auch akzeptieren, aber bitte keine implizite Denunzierung, sowas gehört in ein Forum nicht hin.

Weil das selbstverständlich ist? Deine Frage hat mit dem konkreten Problem des Threads nichts zu tun.

Mein, vlt. schlecht / unglücklich gewählter Vorschlag bezog sich doch nur auf eine Antwort hier in diesen Thread, warum sollte das nicht angebracht bzw. fehl am Platze sein???

Worauf ich konkret hinaus wollte, es hieß:

Caster schrieb:

friend std::ostream& operator << ( std::ostream& out, int8 mint )
    {
        out << (int)mint.myint;
        return out;
    }

Mir ist nur aufgefallen, dass hier ein C-cast angewandt wird und meine eigentliche Frage ist nun, ob es nicht besser bzw. zum Lesen verständlicher wäre, stattdessen einen C++-Cast zu verwenden?

volkard

Schlitzauge schrieb:

Mir ist nur aufgefallen, dass hier ein C-cast angewandt wird und meine eigentliche Frage ist nun, ob es nicht besser bzw. zum Lesen verständlicher wäre, stattdessen einen C++-Cast zu verwenden?

Nö.
Aber nur bittere Medicin ist gut.
Man glaubt mehrheitlich, daß static_cast besser sei. Weil es weh tut. Dieser Ritus wirkt selbstverstärkend.
Gleiches Prinzip wie bei Religionen und Horoskopen, Homöopathie und Wünschelruten.

static_cast solltest Du nehmen, um nicht im Forum angepflaumt zu werden, wenn Du mal eine Frage stellst, die mit was ganz anderem zu tun hat aber im vorgestellten Code ein Cast vorkommt. Gnaz so, wie ich am Karfreitag davon absehe, den ganzen Tag mit der Schlagbohrmaschine zu arbeiten, obwohl es keinen Gott gibt.

Nexus

volkard schrieb:

Man glaubt mehrheitlich, daß static_cast besser sei. Weil es weh tut.

Eigentlich, weil es sicherer ist und verhindert, dass man aus Versehen const wegcastet oder Zeiger umbiegt.

Das wusstest du bestimmt auch, aber du schätzt ja jeden Anlass zur Religionskeule

volkard

Nexus schrieb:

volkard schrieb:

Man glaubt mehrheitlich, daß static_cast besser sei. Weil es weh tut.

Eigentlich, weil es sicherer ist und verhindert, dass man aus Versehen const wegcastet oder Zeiger umbiegt.

Das wusstest du bestimmt auch, aber du schätzt ja jeden Anlass zur Religionskeule

In meiner jahrelangen Praxis ist mir noch nie begegnet, daß ich von dem Mehr an Sicherheit profitiert hätte. Ich benutze fast immer c++-casts. Nie hat mir der Compiler mal diesbezüglich eine Warnung oder einen Fehler aus eigenem Code geworfen, der mir geholfen hätte. Ich benutze manchmal c-casts. Nie ist mir ein Fehler passiert, der durch c++-casts aufgedeckt worden wäre.
Es ist echt ein religiöses Problem, denke ich.
Weiß nicht, vielleicht programmiert Ihr anders. Braucht Ihr static_cast statt c-cast wirklich?

Nexus

Zumindest für const , gerade bei Klassencasts, hat es mir schon ab und zu geholfen. Ich finde neben der Sicherheit auch noch praktisch, dass man mit static_cast explizite Umwandlungen besser erkennt. Als positiven Nebeneffekt verleitet Code mit zu vielen static_cast s dazu, sich Gedanken über eine castfreie Lösung zu machen

knivil

2006