Code::Blocks ... nichts fuer Anfaenger ?!
-
Erhard Henkes schrieb:
Was ist eigentlich der Zahlentyp in Code::Blocks für UINT64? "unsigned long long" aus Dev-Cpp geht wirklich nicht. Vielleicht hast Du Recht mit der Nachfolge, obwohl die Kiste in der Bedienung genau Dev-Cpp entspricht, sogar eine Importfunktion dafür anbietet.
Mein Code::Blocks versteht unsigned long long problemlos. Aber ich verwende auch den MinGW mit GCC 4.2.1 und nicht diese veraltete 3.x-Version. Vielleicht solltest du auch mal deinen Compiler updaten. Ansonsten gibt es noch in stdint.h ein typedef unsigned long long uint64_t. Und die Importfunktionen wurden geschrieben, damit die Leute eher von VC++ oder DevC++ umsteigen.
-
..
-
Erhard Henkes schrieb:
void wait() //ausführliche Version { std::cin.clear(); std::streambuf* pbuf = std::cin.rdbuf(); std::streamsize size = pbuf->in_avail(); std::cin.ignore(size); std::cin.get(); }
Eine Anmerkung noch hierzu (weil sich diese Art den Puffer zu löschen immernoch hartnäckig hält): in_avail muss bei Konsolen nicht das liefern was man hier erwartet, und tut es oft auch nicht. Die Version mit ignore bis '\n' ist portabler.
-
[..
-
Der Unterschied ist für mich:
Den Puffer leeren kann man problemlos mit Standard-C++ (sieht halt ein wenig kompliziert aus ;-)), also sollte man diese Möglichkeit auch nutzen.Für alles was plattformabhängig ist wie GUIs oder eben farbige Konsolen muss man ja zwangsweise die gegebenen Bibliotheken nutzen. Wobei ich auch da Anfängern nicht zur WinAPI raten würde, sondern zu SideWinders Improved Console oder einer der vielen GUI-Bibliotheken eben.
Aber als Anfänger sollte man ja sowieso erstmal die Finger von den Nicht-Standard-C++-Sachen lassen, bis man ein soweit gehendes Verständnis der Sprache hat, dass man mit diesen Bibliotheken dann auch zurechtkommt.
-
Erhard Henkes schrieb:
Gibt es eine Anweisung für Anfänger zum Austausch des GCC von Version 3 auf 4 in Code::Blocks? Ansonsten lasse ich das bei der standardmäßig mitgelieferten Version, damit ich die gleichen Ergebnisse habe. Ich verwende Code::Blocks nur für kleine Experimente, ansonsten MS Visual C++.
Nicht dass ich wüsste. Der automatische MinGW-Installer (http://sourceforge.net/forum/forum.php?forum_id=817299 installiert glaube ich immer noch einen GCC in Version 3. Von Version 4 gibt's ja bisher leider nur den Technology Preview vom 4.2.1 und ganz neu eine Testing-Version vom 4.3.0. Die Installation ist zwar nicht übermäßig kompliziert (hauptsächlich Dateien in die richtigen Verzeichnisse entpacken), aber da man anschließend ein paar Pfade in Code::Blocks neu einstellen muss, würde ich das blutigen Anfängern auf jeden Fall nicht raten. Die sind nur enttäuscht wenn's nicht gleich funktioniert.
-
..
-
Erhard Henkes schrieb:
Ich fasse mal als "Synthese" zusammen:
...
Dem kann ich zustimmen. Die komplizierten oder plattformabhängigen Teile sind in Funktionen versteckt und der Rest entspricht dem, was man in Büchern oder Tutorials so am Anfang lernt. Für kompliziertere Spielereien mit der Konsole würde ich dann aber wie schon erwähnt die Improved Console von SideWinder empfehlen. Man muss das Rad ja nicht neu erfinden.
Als Verbesserung würde ich noch vorschlagen textcolor den Wert 15 als Defaultparameter mitzugeben. Dann kann man den const int farblos auch weglassen.
-
Akzeptiert!
Improved Console 4.0:
http://web56.hermes.server-pool.de/pages/ic.c-plusplus.net/
-
Als Verbesserung würde ich noch vorschlagen textcolor den Wert 15 als Defaultparameter mitzugeben. Dann kann man den const int farblos auch weglassen.
Gute Idee, weg mit Ballast. Ich wollte mit dem "farblos" nur etwas provozieren.
#include <windows.h> //Warning: no C++ standard! #include <iostream> #include <limits> void wait() { std::cin.clear(); std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n'); std::cin.get(); } void textcolor(unsigned short color=15) { SetConsoleTextAttribute(::GetStdHandle(STD_OUTPUT_HANDLE), color); } int main() { for (int i=1; i<15; ++i) { textcolor(i); std::cout << "Hello World!" << std::endl; } textcolor(); std::cout << "\nColorless C++ ISO Standard:" << std::endl; std::cout << "hello, world" << std::endl; wait(); }
-
Obiges Programm macht dem MSVC++ 2008 Probleme, weil das Makro max(a,b) aus windows.h in Konflikt gerät mit der Funktion ...::max()
warning C4003: Nicht genügend übergebene Parameter für das Makro 'max'
error C2589: '(': Ungültiges Token auf der rechten Seite von '::'
usw.Wie kann man das umgehen, ohne windows.h auszublenden?
Ansonsten müsste man in Zusammenhang mit windows.h doch wieder die alte Version verwenden, am besten gleich getch().
-
Wie wäre es damit:
#include <windows.h> #undef max // ...
Und noch eine Frage, wieso das wait so kompliziert?
void wait() { std::cin.clear(); std::cin.sync(); std::cin.get(); }
Die Methode
sync()
sollte absolut ausreichen:
http://www.cplusplus.com/reference/iostream/istream/sync.htmlGrüssli
-
..
-
ich finde es äußerst nervtötend, wenn jedes konsolenprogramm gegen ende noch einen druck auf enter benötigt, um zu beenden. deshalb würde ich anfängern so etwas auch nie empfehlen. besser den umgang mit der konsole gleich lernen.
-
Zum Minmax-Problem (aus windows.h):
/* If defined, the following flags inhibit definition * of the indicated items. * * NOGDICAPMASKS - CC_*, LC_*, PC_*, CP_*, TC_*, RC_ * NOVIRTUALKEYCODES - VK_* * NOWINMESSAGES - WM_*, EM_*, LB_*, CB_* * NOWINSTYLES - WS_*, CS_*, ES_*, LBS_*, SBS_*, CBS_* * NOSYSMETRICS - SM_* * NOMENUS - MF_* * NOICONS - IDI_* * NOKEYSTATES - MK_* * NOSYSCOMMANDS - SC_* * NORASTEROPS - Binary and Tertiary raster ops * NOSHOWWINDOW - SW_* * OEMRESOURCE - OEM Resource values * NOATOM - Atom Manager routines * NOCLIPBOARD - Clipboard routines * NOCOLOR - Screen colors * NOCTLMGR - Control and Dialog routines * NODRAWTEXT - DrawText() and DT_* * NOGDI - All GDI defines and routines * NOKERNEL - All KERNEL defines and routines * NOUSER - All USER defines and routines * NONLS - All NLS defines and routines * NOMB - MB_* and MessageBox() * NOMEMMGR - GMEM_*, LMEM_*, GHND, LHND, associated routines * NOMETAFILE - typedef METAFILEPICT * NOMINMAX - Macros min(a,b) and max(a,b) * NOMSG - typedef MSG and associated routines * NOOPENFILE - OpenFile(), OemToAnsi, AnsiToOem, and OF_* * NOSCROLL - SB_* and scrolling routines * NOSERVICE - All Service Controller routines, SERVICE_ equates, etc. * NOSOUND - Sound driver routines * NOTEXTMETRIC - typedef TEXTMETRIC and associated routines * NOWH - SetWindowsHook and WH_* * NOWINOFFSETS - GWL_*, GCL_*, associated routines * NOCOMM - COMM driver routines * NOKANJI - Kanji support stuff. * NOHELP - Help engine interface. * NOPROFILER - Profiler interface. * NODEFERWINDOWPOS - DeferWindowPos routines * NOMCX - Modem Configuration Extensions */
Also vor dem Include oder Projektweit NOMINMAX definieren.
-
Thx, das habe ich noch nie gesehen.
-
Hallo,
queer_boy schrieb:
ich finde es äußerst nervtötend, wenn jedes konsolenprogramm gegen ende noch einen druck auf enter benötigt, um zu beenden. deshalb würde ich anfängern so etwas auch nie empfehlen. besser den umgang mit der konsole gleich lernen.
Dem kann ich nur zustimmen. Immer, wenn ich eine solche Frage bezogen auf das typische "Warum schliesst sich das Programm sofort-Problem" beantworte, füge ich immer zusätzlich an, dass es sich um "Konsolen"-Programme handelt, die nicht umsonst diesen Namen haben, und man doch auf eine "Warten-Funktion" gut verzichten kann.
MfG,
Probe-Nutzer
-
Da bei MS Windows der Pfad dazu gehört, ist der Start in der Konsole schon lästig, kann mich noch gut an meine eigene DOS-Zeit erinnern.
-
Probe-Nutzer schrieb:
Dem kann ich nur zustimmen. Immer, wenn ich eine solche Frage bezogen auf das typische "Warum schliesst sich das Programm sofort-Problem" beantworte, füge ich immer zusätzlich an, dass es sich um "Konsolen"-Programme handelt, die nicht umsonst diesen Namen haben, und man doch auf eine "Warten-Funktion" gut verzichten kann.
woran ich gedacht habe: wenn hier ab und zu mal jemand einen (etwas) längeren code einfügt, wo man irgendwie gleich zu anfang sieht, dass es viel anzumerken gibt, ist es ganz gut, den rauszukopieren und mit
g++ -W -Wall -ansi -pedantic
zu kompilieren, und dann einfach eine fehlermeldung nach der anderen auf deutsch hier als hinweis reinzuposten - im besten fall kann man dann das programm auch gleich testen, und es ist mir sicher mehr als zweimal passiert, dass ich dachte, irgendetwas stimmt mit der eingabe nicht, wenn das programm nicht gleich nach beendigung der aufgabe schließt.
-
Erhard Henkes schrieb:
Da bei MS Windows der Pfad dazu gehört, ist der Start in der Konsole schon lästig, kann mich noch gut an meine eigene DOS-Zeit erinnern.
Ja, diese Zeiten kenne ich auch noch gut, aber während der Entwicklung einer Konsolen-Anwendung:
Konsole öffnen, Pfad zur Konsolen-Anwendung einmalig eingeben, testen, offen lassen, mit Pfeiltasten Programmnamen immer wieder zurückholen...
Und wenn die Anwendung dann fertig ist?
Umgebungsvariable PATH um den Pfad zu eigenen Konsolenprogrammen ergänzen, Konsole öffnen (entspricht Explorer öffnen auf Windowssystem), nur den Konsolenprogrammnamen eingeben (entspricht Doppelklick auf Programm), oder Explorer mit Verzeichnis der Anwendung öffnen, und Programm in ein Konsolenfenster "drag 'n' droppen", Pfad steht in Konsolenfenster, oder...
Also eigentlich nichts, das allzu lästig sein sollte...
MfG,