[Miniprojekt] InOutAlgo: C++ Bibliothek

[Crysis nerd]

Moin,

ich hatte vor einiger Zeit mal eine Mini-Bibliothek angefangen. Mein eigentlicher Gedanke dabei war, einfache Funktionen zum einlesen von Daten von der Konsole zu ermöglichen. Ich hab zu der Zeit einen kleinen C++ Crashkurs geleitet und wollte den Teilnehmern da etwas erleichtern. Da ich aber sowieso Spaß daran hatte, hab ich noch ein paar extra Funktionen eingebaut. Grundsätzlich bietet meine Bibliothek 3 Features:

1. Funktionen zum einlesen von std::cin (für beliebige Typen, auch Arrays)
2. Einfache Ausgabe von Farbigem Text auf der Konsole (in Windows sowie mehreren Linux Distributionen)
3. Kranke Typetraits mit einer Funktion, die einen Typ einer Variable in englisch erklärt

Ich dachte mir, da ich das hier sowieso rumfliegen habe, stell ich es euch mal vor, eventuell interessiert es ja jemanden.

Long story, hier ist Code:

Spoiler

#define IOA_CPP11
#include "InOutAlgo.hpp"
using namespace ioa;

#include <iostream>
using namespace std;


int main()
{
	cout << "Hi du " << FG_GREEN << "grüner "
		<< FG_BLUE << "Schlumpf." << BG_RED 
		<< "Willst du einen Keks?" << C_RESET_FG
		<< " Ok dann nicht :(" << C_RESET << endl;


	const char* blub = "hi";
	ExplainType(blub);
	ExplainType<int const * const * [][3]>();

	double d = GetInput<double>();
	int i[2];
	GetInput(i);

	return 0;
}

Die Ausgabe:

Spoiler

Hi du grüner Schlumpf.Willst du einen Keks? Ok dann nicht
T is a pointer to a const char
T is an array of an array with size '3' of a pointer to a const pointer to a const int
Bitte ein double eingeben: 3.14
Bitte 2 int eingeben.
int (1/2) eingeben: 42
int (2/2) eingeben: 1337

Oder in Farbe (ist ja nicht ganz unwichtig ):
http://sebi707.de/downloads/files/0003785/output.png


Da der 3. Punkt in meiner Liste (nämlich ExplainType) nicht funktioniert ohne C++11 features, aber ich die Bibliothek auch ohne C++11 nutzen wollte, habe ich die zusätzlichen Features mit dem #define IOA_CPP11 optional gemacht. Die C++ 11 Features kann man nicht unter VisualStudio (eventuell unter VS13 RC) nutzen, weil die Variadic templates und ein paar anderes Zeugs nutzen. Unter clang++ und g++ sollte es beides compilieren, da ja jetzt beide language-complete sind (glaub ich...).
Ähm was gibt es noch zu sagen... Alles ist in der hpp Datei, also keine eigenen Source Dateien (wäre für sowas kleines auch doof). Es gibt noch ein paar kleinere Bugs (vorallem im typetraits rund um ExplainType). Kompatibilität endet auch irgendwo. Nicht alle Linux Terminals unterstützen Farben (bei denen die es nicht tun, würde wohl Matsche rauskommen). Sonst hab ich auch versucht die so klar zu strukturiert wie möglich zu halten, alle Deklarationen an den Anfang zu packen. Achja, zurzeit ist noch die Color Klasse ziemlich sinnlos, weil beide Konsolen eh nur 8 unterschiedliche Farben ausgeben können. Wollte es aber erstmal so allgemein wie möglich halten.

Joa das wars erstmal. Wenn ihr wollte, könnt ihr sie gerne nutzen, verändern usw, aber wäre cool wenn ihr meinen Namen nicht daraus löscht ^^ http://sebi707.de/downloads/files/0003792/InOutAlgo.hpp (kleines Update)

Sonst, wenn ihr Anmerkungen habt oder Bugs findet, haut raus. Wollte wie gesagt nur mal vorstellen, falls es einer interessant findet.


LG Lukas

 

[Leandros]

Wie wärs das in ein VCS zu laden, z.B Github?

Ich fühl ihm dann mal mit Objective-C auf die Zähne.


Edit: Öhhm .. ja, die library kann sehr gut spammen
Wenn man über

int i = GetInput<int>();

eine int requested, aber dann z.B einen buchstaben eingibt, spammt der mir meine cli mit "Bitte ein int eingeben: Fehler bei der Eingabe!".

Allerdings: Farbig

 

[Crysis nerd]

Edit: Öhhm .. ja, die library kann sehr gut spammen
Wenn man über

int i = GetInput<int>();

eine int requested, aber dann z.B einen buchstaben eingibt, spammt der mir meine cli mit "Bitte ein int eingeben: Fehler bei der Eingabe!".
Allerdings: Farbig

Hast Recht :/ Damit hab ich schon immer Probleme gehabt. Hatte es aber irgendwann mal endlich gefixt und eine gute Lösung dafür gefunden. Scheinbar funktioniert es aber wieder nicht. std::cin ist so ein pain in the ass (meiner Meinung nach). Ich versuche da mal ein Fix für zu machen ^^ is ja peinlich, dass gleich das einfachste nicht geht....

Und wieso Github? Ich nutze Github (noch) nicht ^^

Grüße

 

[Leandros]

Warum Github? Ganz einfach, dann könnte ich einfach dort eine issue aufmachen und reinschreiben. Außerdem könnte ich, falls ich einen Fix gefunden hätte (grade keine lust zu suchen ), ihn einfach submitten können.

Git ist super, Github ist ja im Prinzip nur eine web Oberfläche für die Repos. Wenn du einen Git crash kurs brauchst, helf ich gerne.

 

[Crysis nerd]

GIT hab ich schon öfters genutzt nur nicht "in Produktion" und GitHub hab ich auch schon mehrmals bedient und dort was angeguckt Das mit den issues wäre natürlich was, wusste nicht, dass github das gleich dabei hat. Ich nutze für die meisten projekte SVN und Redmine (bitte als GIT-nutzer nicht über svn meckern :/ ).
Wenn du ein UnterRepository aufmachst, dann lad ich es gerne hoch, aber jez direkt nur für das eine Teil einen Github account usw.. ach ich weiß nicht

Was den Fehler an sich angeht: Du wirst (ganz unten in der Datei) sehr viele Helper funktionen sehen, wie _ClearCin (nebenbei: sry für ugly case, dachte das wäre generell für interne namen normaler bibliotheken, erst später herausgefunden, dass es tatsächlich NUR in die STL genutzt werden sollte). Jedenfalls das Problem ist, nach einem formatierten Einlesen, das gescheitert ist, den Inputstrom komplett zu löschen. Da allerdings cin so besonders ist aber man trotzdem nur mit istream methoden darauf rumarbeiten kann -> Chaos. Zumindest meiner Meinung nach. Also nichts gegen die Idee die Standardeingabe als normalen InputStream zu behandeln, aber so... ne.

EDIT: Das Problem war vorallem dies: Man kann zwar Zeichen mit "ignore" verwerfen, allerdings betrifft das auch zeichen, die man noch garnicht eingegeben hat. Also wenn man ignore aufruft aber garkein Zeichen in dem Eingabestream drin ist, wartet das Programm auf Eingabe (das ist blöde). Andererseits kann man auch nicht feststellen, OB noch etwas im stream ist. Daher die sehr abenteuerlichen _Helper.

 

[Leandros]

Hmm, stimmt, ist irgendwie gar nicht so simpel.

 

[Crysis nerd]

Hmm, stimmt, ist irgendwie gar nicht so simpel.

Das "einfachste" in einer Hinsicht wäre, erstmal per std::read_line(std::istream&, std::string) in einen string einzulesen, darauf ein string stream erstellen und von dort dann formatiert einlesen. Find ich nur eigentlich total dämlich, dass man dann 2 Kopiervorgänge durchführen muss, nur weil irgendwer im C++ kommite es nicht gebacken bekommt das gut zu designen. Aber ich lass mich gerne belehren, wie es gut nur mit cin geht ^_^

 

[Leandros]

Was spricht gegen getline? Wäre definitiv eine gute überlegung, hätte auch keine Probleme bei Strings, wie cin (welches bei blank chars die eingabe stoppt).

 

[Crysis nerd]

Habs mal gefixt. Hab jetzt die Methode mit dem stringstream. Sollte jetzt funktionieren, hab aber nur kurz getestet.
http://sebi707.de/downloads/files/0003792/InOutAlgo.hpp

Probleme mit Strings (dass cin bei blank chars stoppt) hab ich aber schon vorher anders gelößt gehabt.

Grüße