Otóż jak w tytule, napisałem prościutką aplikację w konsoli każącą wypisać tekst. Zamieszczam kod:
// First - pierwszy program w C++
#include
#include
void main()
{
std::cout << "Witam w C++." << std::endl;
getch();
}
Przy kompilacji wyskakuje bład: “implicit declaration of function `int getchar(…)”. Objawia się on w linii 12, przy poleceniu getch(); 
. Co jest źle? Przepisywałem przykład z podobno bardzo dobrego kursu. 8)
Nie wiem co to conio.h, ale na mój gust to powinno być int main(), funkcja główna zwraca wartość int.
to plik nagłówkowy.
Zamiana void na int nie pomogła.
Wiem, że plik nagłówkowy ale po co, co to za biblioteka, czy co. Lepiej pisz bez takich dodatków, na początek wystarczy standardowy C++.
#include
int main()
{
std::cout << "Witam w C++." << std::endl;
}Kurde, zależy mi na getch();. To najbaredziej podstawowe podstawy podstaw ;). Czy jest odpowiednik polecenia Delay(3000) w C++?
O, kolejny temat w którym ktoś chce połączyć conio z iostream.
Powtórzę po raz kolejny: nie należy łączyć tych dwóch bibliotek tak jak nie należy łączyć stdio z iostream.
Druga rzecz: conio jest biblioteką dostępną (niemal wyłącznie) w środowiskach Borlanda. Nie jest to standardowy zestaw funkcji C.
Trzecia rzecz: szukaj, było przynajmniej dwa razy na forum.
Czwarta rzecz: nr47 , jest taka niepisana zasada, że jak się czegoś nie wie i jedynie przypuszcza, to lepiej tego nie wyrażać. Funkcja main ma kilka prototypów - nie musi zwracać inta jeśli nie ma takiej potrzeby.
Piąta rzecz: Pentium , tak istnieje odpowiednik. Nazywa się sleep.
Fatalny przykład, szemek. Nie dość, że implementujesz coś, co istnieje, to jeszcze sugerujesz aktywne czekanie. Proces będzie się starał wykonać jak najwięcej porównań w pętli while i pożre całą moc procesora, jaką udostępni system.
Ryan , więc jak wygląda prawidłowy kod bez biblioteki conio.h i z poleceniem getch(); ?
Zastanów się, czy Twoje pytanie ma sens. Skoro getch() jest częścią biblioteki conio dostępnej (głównie) w środowiskach Borlanda i nie stanowiącej części standardu (ani C ani C++), to jak chcesz użyć getch() bez conio?
Gdyby Twoje pytanie brzmiało: jak uzyskać funkcjonalność zbliżoną do getch() przy braku conio - odpowiedź byłaby możliwa w pewnych warunkach. To o co prosisz to niebuforowane IO, które w przypadku klawiatury uzyskuje się różnie w różnych środowiskach i na różnych platformach. Implementacja pod Linuksa będzie inna niż jeśli piszesz aplikację Win32. Są też inne, gotowe biblioteki oferujące taką funkcjonalność, np. większość odmian curses.
Nie spełniasz warunków z tego tematu i tym samym nie jestem w stanie udzielić Ci jednoznacznej odpowiedzi. Zadawaj pytania przemyślane, podaj informacje niezbędne do udzielenia odpowiedzi a ją otrzymasz. W każdym innym przypadku - nie licz na cud.
Chcę dodać, że pisałem program w Dev-C++. Program przepisałem z kursu. kiedy używałem Microsoft Visual Studio 2005 Express, wszystko było OK. Więc moje pytanie brzmi: Skoro nie da się połączyć iostream z conio to czy można prosić o kod programu, który wyświetla napis i czeka na naciśnięcie Entera?.
Czytaj uważnie - nie nie da się, tylko nie powinno się. Jeśli chcesz czekać na naciśnięcie entera a nie dowolnego klawisza, to najprostszy kod wygląda tak:
#include
#include
int main(int argc, char *argv[])
{
std::string buf;
std::cout << "Wcisnij ENTER..." << endl;
std::getline(std::cin, buf);
}Thx. Mógłbyś dać linka do Borland C++ Builder (jeśli możesz)? Oczywiście, szukałem w googlach, ale mnie znalazłem. A MSVS 2005 nie moge zainstalować. 
Nie wierzę, że szukałeś. Wpisujesz nazwę i masz do pobrania pod pierwszym linkiem wynikowym.
Link ze strony Borland nie działa.
Sprawdziłem: działa.
Google mnie tu przywiodly. Troche smieszna ta dyskusja. Chcialbym, aby ktos tu mi wytlumaczyl dlaczego nie mozna laczyc iostream.h z conio.h czy tez iostream z cstdio (czy stdio.h jak wolicie) Korzystalem z opcji “szukaj”, ale jest tu tego cała masa i nie wiem, w którym poście znajdę konkretną odpowiedź. Od biedy prosze uprzejmie o linka do wlasciwej dyskusji.
Btw: Program, nad którym trwała burza mózgów można rozwiązać w jeszcze prostszy sposób…Nie tworzy się niepotrzebnych zmiennych, które zawsze stanowią dodatkowy narzut (jak już się bawimy w informatyków, to robimy to na serio). Co prawda sprawdzenie warunku petli tez posiada pewna niezerowa wartosc w szacowaniu zlozonosci obliczeniowej takiego programu, ale i tak jest to rozwiazanie lepsze. Strumien pobiera kolejne znaki i tak już z bufora streambuf, który powstaje przy inicjalizacji każdego obiektu istream (ostream zreszta tez). To akurat nie ma w tym przykładzie większego znaczenia, ale porada z cyklu “warto wiedziec”… Nie ma sensu tworzyć buforu bufora - na pewno nie w tym przypadku. Jakby sie klocic to mozna tez powiedziec, ze jesli tych znaczkow (roznych od enter) bedzie wiecej (srednio niz 15 - potem ta wartosc jest systematycznie zwiekszana) to dochodzi do alokacji wiekszej ilosci pamieci na obiekt string, ktory pelni role bufora. Getch(), o ktory upominał się kolega to obecnie raczej relikt przeszłości - należy stosować metode get() z klasy istream. Nalezy nie znaczy, ze musi. Tak samo jak nie musi pisac int main() zamiast void main(), lub umieszczac jakichkolwiek prototypow w liscie inicjalizacyjnej w funkcji main(). Warto jednak wyksztalcac dobre nawyki.
#include
using namespace std; //dla wygody
int main()
{
cout << "Wcisnij ENTER...";
while (cin.get() != '\n');
return 0;
}Może odpowiem od końca.
Tak banalne programy o jakie “rozbijają się” użytkownicy na tym forum można zrobić na przynajmniej kilka sposobów, praktycznie zawsze lepiej niż sugerują autorzy wątku. Staram się odpowiadać na większość, póki starcza mi czasu i siły. Bo czasem problemy są rozbrajające.
Nie odpowiadam ani najlepszym ani jedynym słusznym (jakikolwiek on jest) kodem. Staram się sugerować drobne usprawnienia i podpowiadam rozwiązania. Stawiam na małe kroki, bo nie zależy mi na tym by utrudnić zrozumienie problemu ludziom, którzy mimo blisko zerowej wiedzy chcą programować. Większość “programów” rozpiswanych tutaj można streścić w kilku linijkach, mimo iż “prototypy” mają ich kilkadziesiąt. Jasne, mogę tak robić, ale jeśli ktoś ma wątpliwości gdzie postawić średnik to skrót myślowy na dziesięć linii takiej osobie zupełnie się nie przysłuży.
Jasne, że bufor kosztuje. Szczególnie automagiczna klasa string. Osobiście stronię od iostream i klas automatycznych w większości przypadków. Ale gro osób tutaj czyta Symfonię a Grębosz jest proponentem wszystkiego co obiektowe. A wracając do bufora: jako że iostream nie używam a i nie mam czasu na wertowanie dokumentacji API, którego tykać nie chcę, o get() najzwyczajniej w świecie zapomniałem (lub nie znałem - nie pamiętam nawet kiedy ostatnio używałem iostream).
Odpowiedzi “dlaczego nie łączyć” nie było, bo nikt się tematem nie zainteresował i każdy tą informację “olał”. Powodów jest kilka. Zacznijmy od wyrabiania dobrych nawyków. Po grzyba dwie biblioteki wykonujące to samo - IO? conio jest uzupełnieniem stdio, więc te dwie wykorzystywać wspólnie wolno. Choć generalnie używanie conio to moim zdaniem strata czasu. Standard Borlanda to nie standard.
Powód drugi: ponieważ zapis danych na ekran lub do pliku nie koniecznie odbywa się synchronicznie. Nie ma gwarancji, że np. powrót z funkcji printf() jest równoznaczny z wyświetleniem obrazu na ekranie (czy w przypadku fprintf - zapisem do pliku). Implementacja bibliotek nie jest narzucona, narzucony jest wyłącznie interfejs. Biblioteka może swobodnie dane buforować (szczególnie byłoby to korzystne przy zapisie do pliku przy wykorzystaniu suboptymalnego zapisu po znaku).
W przypadku, gdy biblioteka buforuje zapis, mieszanie wyjścia przy użyciu np. stdio i iostream może zaowocować tym, że teksty na ekranie (w pliku) pojawią się w innej kolejności niż sugerowałby kod.
stdout jest globalnym, współdzielonym uchwytem a zapis na ekran jest synchroniczny i szybki. Uruchamiając aplikację z przekierowaniem strumienia do pliku, wszystkie te założenia można włożyć między bajki. Zapis do udziałów sieciowych pod Windowsem jest asynchroniczny i wolny.
Witam na forum.
Trudno się z tym wszystkim nie zgodzić. Ja chciałbym od siebie dodać, że oczywiście każde poprawne rozwiązanie jest dobre. Różnice między poszczególnymi implementacjami w wydajności (na takim poziomie złożeniowym problemu!) są minimalne biorąc pod uwagę obecne możliwości komputerów oraz metody optymalizacji kodu stosowane przez kompilatory. Ja jak najbardziej popieram wnioski wysnute przez szanownego przedmówcę - zawsze można napisać jakiś kawałek kodu lepiej, a potem jeszcze lepiej. Co mi się podoba w conio i stdio czego nie znalazlem w iostream i innych bibliotekach…Co prawda ostatnio uzywałem bibliotek Borlanda jak i samej biblioteki stdio pare lat temu, ale pamiętam na przykład że była opcja formatowania tekstu, że można było zmieniać kolor czcionki i kolor tla(bodaj sprintf, ale glowy nie dam), no i byly tez funkcja, ktora przyjmowala argumenty (x,y), ktore przyjmowaly wspolrzedne na oknie konsoli i wlasnie tam umieszczaly kursor. I one byly mi przydatne, natomiast zgadzam sie nalezy mieszac stdio z iostream w kwestii wyswietlania/pobierania etc.
Jeszcze o conio. W Windows istnieją tzw. Console Functions. Jeśli uruchamia się aplikację w oknie linii poleceń, pozwalają one na pisanie tekstu, zmianę koloru, skok po ekranie, zmianę rozmiaru okna i zmianę rozmiaru bufora ekranowego. Z powodzeniem zastępują conio. Pod Linuksem (jak i być może pod Windowsem) najlepszą konsolową biblioteką będzie zawsze implementacja curses. Conio nie jest złe z założenia. Jest niezbyt przenośne i jeśli ktoś nie zdaje sobie z tego sprawy, lepiej by conio nie używał.