Mischung von C und C++ unterdrücken

[quote="Citizen42"]
Gibt es eine Möglichkeit diese Kompatibilität zu C zum Teil aufzubrechen, also z.B. dass den C++-StdLibs alles erlaubt ist, nur bei selbst geschriebenen Sachen läuten dann die Alarmglocken?
[quote].
kannst ja die #include <c*> und #include <*.h> weglassen

Ethon

Marthog schrieb:

Ansonsten muss man einfach aufpassen, dass man bei std::equal und konsorten die Version mit 4 iteratoren verwendet.

Was soll an equal unsicher sein? Eine rein lesende Operation.

Ethon schrieb:

Marthog schrieb:

Ansonsten muss man einfach aufpassen, dass man bei std::equal und konsorten die Version mit 4 iteratoren verwendet.

Was soll an equal unsicher sein? Eine rein lesende Operation.

int x;
int y=*(&x+1337);

ist auch eine rein lesende Operation.

kannst ja die #include <c*> und #include <*.h> weglassen

So einfach ist das nicht. C++ hat glaube ich nicht alle C-Funktionen ersetzt. Z. B. gibt es die Max-Funktion in C++ erst seit C++14. Dass in Firmen schon C++14 programmiert wird, halte ich für sehr unwahrscheinlich!

L. G.,
IBV

Marthog

Ethon schrieb:

Was soll an equal unsicher sein? Eine rein lesende Operation.

Es kann aber immernoch Abstuerze ausloesen, die z.T. schwerwiegende Folgen haben koennen. Ausserdem kann der algorithmus dadurch falsche Ergebnisse liefern, also ein Bug.

IBV schrieb:

kannst ja die #include <c*> und #include <*.h> weglassen

So einfach ist das nicht. C++ hat glaube ich nicht alle C-Funktionen ersetzt. Z. B. gibt es die Max-Funktion in C++ erst seit C++14. Dass in Firmen schon C++14 programmiert wird, halte ich für sehr unwahrscheinlich!

Zum Glück ist programmieren nicht glauben.

(In C gibt es keine Max-Funktion/Makro und in C++ gibt es die seit Templates, also praktisch seit immer. Argumentiere bitte mit Fakten, nicht Wahrscheinlichkeit.)

großbuchstaben schrieb:

kannst ja die #include <c*> und #include <*.h> weglassen

Was soll ich anstelle von** #include <cmath> **dann nehmen?

volkard

Citizen42 schrieb:

Gibt es keine Möglichkeit sich in C++-Projekte warnen zu lassen, wenn irgendwo unsichere Funktionen der C-StdLib genutzt werden, oder wenn mit nacktem Pointer-Fu rumgespielt wird? Menschen machen garantiert Fehler, das kann man nicht wegdiskutieren.

Doch. Profis machen solche Fehler. Aber erfahrene Profis auch?

Lass die Wikipediaparanoia nicht an Dich ran, das wäre ein verschwendetes halbes Jahr.

Ethon

Marthog schrieb:

Ethon schrieb:

Was soll an equal unsicher sein? Eine rein lesende Operation.

Es kann aber immernoch Abstuerze ausloesen, die z.T. schwerwiegende Folgen haben koennen. Ausserdem kann der algorithmus dadurch falsche Ergebnisse liefern, also ein Bug.

Gibt genug Dinge, die Abstürze auslösen können. equals mit 3 Parametern verwendet man halt wenn es sinnvoll ist.
Aber für Angriffe wie vom TE genannt macht man sich damit nicht verwundbar.

Beispiel wo ich es verwende:

bool equal(CharT const* s) const noexcept{
		assert(s != nullptr);
		return std::equal(_begin, _end, s) && s[length()] == 0;
	}

equal mit 4 Parametern wäre reichlich zwecklos.

dot

volkard schrieb:

Lass die Wikipediaparanoia nicht an Dich ran, das wäre ein verschwendetes halbes Jahr.

+1

volkard schrieb:

Citizen42 schrieb:

Gibt es keine Möglichkeit sich in C++-Projekte warnen zu lassen, wenn irgendwo unsichere Funktionen der C-StdLib genutzt werden, oder wenn mit nacktem Pointer-Fu rumgespielt wird? Menschen machen garantiert Fehler, das kann man nicht wegdiskutieren.

Doch. Profis machen solche Fehler. Aber erfahrene Profis auch?

Lass die Wikipediaparanoia nicht an Dich ran, das wäre ein verschwendetes halbes Jahr.

Steff_mc

Ich zitiere mal Scott Meyers aus seinem "must read" Buch.

Effective C++

Mindful of the destructive power of rioting bands of incensed programmers, the standardization committee decided to create new header names for the std-wrapped components.

The algorithm they chose for generating the new header names is as trivial as the results it produces are jarring: the .h on the existing C++ headers was
simply dropped.

So <iostream.h> became <iostream>, <complex.h> became <complex>, etc.

For C headers, the same algorithm was applied, but a c was prepended to each result. Hence C's <string.h> became <cstring>, <stdio.h> became <cstdio>, etc.

For a final twist, the old C++ headers were officially deprecated (i.e., listed as no longer supported), but the old C headers were not (to maintain C compatibility).

In practice, compiler vendors have no incentive to disavow their customers legacy software, so you can expect the old C++ headers to be supported for many years.

Practically speaking, then, this is the C++ header situation:

o Old C++ header names like <iostream.h> are likely to continue to be supported, even though they aren't in the official standard. The contents of such headers are not in namespace std.

o New C++ header names like <iostream> contain the same basic functionality as the corresponding old
headers, but the contents of the headers are in namespace std. (During standardization, the details of some
of the library components were modified, so there isn't necessarily an exact match between the entities in
an old C++ header and those in a new one.)

o Standard C headers like <stdio.h> continue to be supported. The contents of such headers are not in std.

o New C++ headers for the functionality in the C library have names like <cstdio>. They offer the same contents as the corresponding old C headers, but the contents are in std.

All this seems a little weird at first, but it's really not that hard to get used to. The biggest challenge is keeping all the string headers straight: <string.h> is the old C header for char*-based string manipulation functions, <string> is the std-wrapped C++ header for the new string classes (see below), and <cstring> is the std-wrapped version of the old C header. If you can master that (and I know you can), the rest of the library is
easy.