endl ohne Zeilenumbruch

Columbo

hustbaer schrieb:

Und in C++17 können wir dann noch das auto weglassen

Ne, terse range-based for loops sind raus. Leider. Ich kann nicht nachvollziehen, warum es nicht lesbar sein soll...

Und natürlich macht range based for über den Literal auch einen Durchlauf für den Null-Terminator -- also mit ch == '\0'. Was vermutlich nicht erwünscht ist.

=> for (auto ch : boost::range::as_literal("....."))

hustbaer

Arcoth schrieb:

hustbaer schrieb:

Und in C++17 können wir dann noch das auto weglassen

Ne, terse range-based for loops sind raus. Leider. Ich kann nicht nachvollziehen, warum es nicht lesbar sein soll...

Argh.
Wieder mal ne Entscheidung des Comittee die ich nicht ganz nachvollziehen kann.
Na gut, die paar Zeichen für auto&& bringen mich auch nicht um.

Arcoth schrieb:

Ne, terse range-based for loops sind raus. Leider. Ich kann nicht nachvollziehen, warum es nicht lesbar sein soll...

Gibts dafür ne verlässliche Quelle welche Proposals drin und welche draußen sind? Irgendwo habe ich das auch gehört aber weiß nicht mehr wo.

Columbo

sebi707 schrieb:

Arcoth schrieb:

Ne, terse range-based for loops sind raus. Leider. Ich kann nicht nachvollziehen, warum es nicht lesbar sein soll...

Gibts dafür ne verlässliche Quelle welche Proposals drin und welche draußen sind? Irgendwo habe ich das auch gehört aber weiß nicht mehr wo.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4252.pdf

CWG Motion 13 straw poll results were:
In favor: 8 Opposed: 43 abstain: 18
Motion not carried

hustbaer

Wäre jetzt nur noch interessant was da vor der Abstimmung besprochen wurde. Muss ja fast einen guten Grund dagegen gegeben haben wenn die Abstimmung so eindeutig ausgegangen ist.

Train schrieb:

Weiterhin stehen mir files wie <windows.h> ... nicht zur Verfügung, deshalb das "altertümliche" Programmieren hier.

Auf welchem Betriebssystem bist du unterwegs?

Ich würde mal cerr statt cout probieren.

happystudent

hustbaer schrieb:

Wäre jetzt nur noch interessant was da vor der Abstimmung besprochen wurde. Muss ja fast einen guten Grund dagegen gegeben haben wenn die Abstimmung so eindeutig ausgegangen ist.

Laut hier war der Grund wohl das:

int i = 0;

for (i : vec) // Ist dass das 'i' von oben oder ein neues 'i'?
   ;

Fände ich auch ein bisschen verwirrend.

Es muss ein neues i sein weil bei der "alten" Range Based For Loop kann man keine vorhandenen Variablen nutzen, sondern muss immer eine neue anlegen.

happystudent

sebi707 schrieb:

Es muss ein neues i sein weil bei der "alten" Range Based For Loop kann man keine vorhandenen Variablen nutzen, sondern muss immer eine neue anlegen.

Schon klar, aber das ist dann halt nicht mehr konsistent zur "normalen" for loop.

hustbaer

Ah, OK, Verwirrung vermeiden.
Gut, das ist irgendwie verständlich. Und wie gesagt - auto&& zu schreiben ist nicht SO schlimm
(Einzig doof dass viele Leute dann vermutlich auto statt auto& bzw. auto&& schreiben werden -- an Stellen wo man gar nicht kopieren will. Was natürlich doof ist, aber Leute sind halt doof.)

Train

@manni66 ich benutze derzeit Windows 10

Train

Danke manni66 !!!!!!!!!!

Es hat geklappt mit cerr und flush !!!

Hier der Code:

#include <iostream>
#include <time.h>

void sleep(unsigned int mseconds)
{
    clock_t goal = mseconds + clock();
    while (goal > clock());
}

int main()
{
	char example [] = "Hallo du da !";
	for ( int i = 0; i < 13; i++ )
	{
		cerr << example[ i ] << flush;
		sleep(200);
	}
}

Könntest du mir jetzt noch erklären wieso das so funktioniert? Will ja auch dazu lernen bin ja eher neu auf dem Gebiet. also wieso das mit ceer funktioniert. Warum ich flush verwenden muss habe ich ja mittlerweile verstanden.

MfG Train

cerr ist so ähnlich wie cout, ist aber eigentlich für die Ausgabe von Fehlern gedacht. Vermutlich verarbeitet deine Entwicklungsumgebug die Ausgaben mit cerr irgendwie anders.

cout ist oft aus Geschwindigkeitsgründen gepuffert, cerr in der Regel nicht, da man eine Fehlermeldung, die ein Programm kurz vorm Absturz ausgibt, nach Möglichkeit auch sehen will.

Train

ah ok. Danke für die Hilfe

Belli

manni66 schrieb:

cout ist oft aus Geschwindigkeitsgründen gepuffert

Deshalb hat er ja zunächst (vergeblich)

cout << ... << flush;

angehängt ...

Belli schrieb:

manni66 schrieb:

cout ist oft aus Geschwindigkeitsgründen gepuffert

Deshalb hat er ja zunächst (vergeblich)
cout << ... << flush;
angehängt ...

Das Problem ist nur, dass es mehrere Ebenen geben kann, auf denen gepuffert wird und das flush nicht notwendigerweise auch auf allen Ebenen ausgeführt wird. Mag sein, dass das als Fehler der Implementierung zu werten ist.

hustbaer

Naja, ich denke das Problem ist dass cout hier zeilengepuffert ist.
Für nur "normal gepuffert" sollte flush definitiv reichen.