Anfänger ?

It0101

@Wade1234 sagte in Anfänger ?:

"das ist genormt" bedeutet doch so viel wie "da hat jemand einen vorschlag gemacht, wie man es machen könnte, falls man lust haben sollte, sich an die norm zu halten", oder irre ich da?

Naja kein Compilerhersteller wird verklagt, weil er diese oder jene Funktion so oder so genannt hat...

Swordfish

@Wade1234 Da können wir ja froh sein, daß so viele Lust haben ^^

@john-0 Daß es für die Runtime reservierte bezeichner sind heißt doch nicht, daß man sie nicht aufrufen darf.

@john-0 sagte in Anfänger ?:

msrt_ o.ä. wäre mit Sicherheit sinnvoller gewesen

Nein, weil da wären im Gegensatz zu Bezeichnert die mit _ beginnen Kollisionen mit Usercode /* NICHT */ per Standard ausgeschlossen.

*john 0

@Swordfish sagte in Anfänger ?:

Nein, weil da wären im Gegensatz zu Bezeichnert die mit _ beginnen kollisionen mit Usercode mit per Standard ausgeschlossen.

Das würde für jede Bibliothek gelten. Insofern ist das Argument nicht wirklich stichhaltig.

Swordfish

@john-0 sagte in Anfänger ?:

Das würde für jede Bibliothek gelten.

Ne, wieso soll das für jede Bibliothek gelten, bei der es einem völlig frei steht, sie zu verwenden? Um Einbinden von Standardheadern und linken gegen eine Standardlibrary kommt man aber nicht herum. (Komm mir jetzt nicht mit Freestanding Environments.)

*john 0

@Swordfish sagte in Anfänger ?:

Ne, wieso soll das für jede Bibliothek gelten, bei der es einem völlig frei steht, sie zu verwenden?

Es geht um das grundsätzliche Problem von Namenskollisionen, und die explizite Definition der ISO Norm, dass nur Compiler- und Laufzeit-Internas in den Namensräumen _ bzw. __ existieren dürfen. Das wird durch normale Funktionen konterkariert. Ergo, wäre es besser gewesen sie nicht dort unterzubringen. Spezielle UNIX bzw. Linux Eigenheiten werden ja auch nicht in die privaten Namensräume der Compiler verschoben, sondern existieren explizit im normalen Namensraum. Weshalb weicht Microsoft so von der Gepflogenheiten der C Programmierung ab?

Swordfish

@john-0 sagte in Anfänger ?:

Es geht um das grundsätzliche Problem von Namenskollisionen, und die explizite Definition der ISO Norm, dass nur Compiler- und Laufzeit-Internas in den Namensräumen _ bzw. __ existieren dürfen.

Wer sagt das? Du darfst Bezeichner in Deinem Usercode nicht einführen. Wo ist irgendwo verboten, eine Funktion _foobar() aufzurufen?

@john-0 sagte in Anfänger ?:

Bezeichner mit einem _ am Anfang, denn solche Bezeichner sind laut Norm explizit für den Compiler und dessen Laufzeitumgebung reserviert.

Du widersprichst Dir selbst. _fcloseall() ist bei MS Teil der Runtime.

Ich sehe das genau andersrum: GNU packt irgendwelche Bezeichner ("This function is a GNU extension.") wie fcloseall() in einen Standardheader und kein Standard garantiert, daß der nicht auch von Usercode verwendet (=eingeführt) werden dürfte.

@john-0 sagte in Anfänger ?:

die explizite Definition der ISO Norm, dass nur Compiler- und Laufzeit-Internas in den Namensräumen _ bzw. __ existieren dürfen. Das wird durch normale Funktionen konterkariert. Ergo, wäre es besser gewesen sie nicht dort unterzubringen. Spezielle UNIX bzw. Linux Eigenheiten werden ja auch nicht in die privaten Namensräume der Compiler verschoben, sondern existieren explizit im normalen Namensraum.

C++ (latest draf) [lex.name]/3.2:

Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

C11 §7.1.3.1:

[...]

All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.

All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.

Also Du redest ein bisschen Topfen.

RBS2

@Wade1234 sagte in Anfänger ?:

aber dann taut der gefrierschrank ab

Bis dahin ist der Schlüsseldienst längst da und hat dein Schloß aufgeknackt.

RBS2

@Wade1234 sagte in Anfänger ?:

was ich mich grad so frage: warum gibt es eigentlich keine funktion _fopenall()? das wäre doch bestimmt total bequem, alle dateien auf einmal öffnen zu können.

Der würde eine Liste aus Pfaden bekommen und eine gleich lange Liste von FILE* zurückgeben, oder NULL, wenn eine der Dateien nicht geöffnet werden kann. Bestimmt gibt es auch den einen oder anderen Anwendungsfall dafür. Allerdings ist das schon sehr speziell.

@RBS2 sagte in Anfänger ?:

Bis dahin ist der Schlüsseldienst längst da und hat dein Schloß aufgeknackt.

ja da hast du natürlich recht. am sichersten ist es aber, im trafohäuschen die ganze straße abzuschalten.

@RBS2 sagte in Anfänger ?:

Der würde eine Liste aus Pfaden bekommen und eine gleich lange Liste von FILE* zurückgeben, oder NULL, wenn eine der Dateien nicht geöffnet werden kann. Bestimmt gibt es auch den einen oder anderen Anwendungsfall dafür. Allerdings ist das schon sehr speziell.

naja wenn du gemäß obiger idee alle dateien mit 1 und 0 überschreiben willst, könnte das programm dann doch ungefähr so aussehen:

int main()
{
     int i;

     _fopenall("f:\\");

     for(i = 0; i < 5; i++)
     {
          _fwriteall(0xFFFFFFFF, 4, _fsizeall());
          _fwriteall(0x00000000, 4, _fsizeall());
     }

     _fcloseall();
}

SeppJ

@RBS2 sagte in Anfänger ?:

@Wade1234 sagte in Anfänger ?:

was ich mich grad so frage: warum gibt es eigentlich keine funktion _fopenall()? das wäre doch bestimmt total bequem, alle dateien auf einmal öffnen zu können.

Der würde eine Liste aus Pfaden bekommen und eine gleich lange Liste von FILE* zurückgeben, oder NULL, wenn eine der Dateien nicht geöffnet werden kann. Bestimmt gibt es auch den einen oder anderen Anwendungsfall dafür. Allerdings ist das schon sehr speziell.

Das wäre ja noch viel zu sinnvoll. Das hat ja ein richtiges Konzept vonwegen Ressourcenhandling. Das passende Äquivalent zu _fcloseall wäre, alle Dateien zu öffnen und die FILE* nicht zurück zu geben. Man kann die Dateien dann ja mit freadall, fwriteall, und fcloseall bearbeiten.

RBS2

@SeppJ sagte in Anfänger ?:

@RBS2 sagte in Anfänger ?:

@Wade1234 sagte in Anfänger ?:

was ich mich grad so frage: warum gibt es eigentlich keine funktion _fopenall()? das wäre doch bestimmt total bequem, alle dateien auf einmal öffnen zu können.

Der würde eine Liste aus Pfaden bekommen und eine gleich lange Liste von FILE* zurückgeben, oder NULL, wenn eine der Dateien nicht geöffnet werden kann. Bestimmt gibt es auch den einen oder anderen Anwendungsfall dafür. Allerdings ist das schon sehr speziell.

Das wäre ja noch viel zu sinnvoll. Das hat ja ein richtiges Konzept vonwegen Ressourcenhandling. Das passende Äquivalent zu _fcloseall wäre, alle Dateien zu öffnen und die FILE* nicht zurück zu geben. Man kann die Dateien dann ja mit freadall, fwriteall, und fcloseall bearbeiten.

So könnte die API für ein RAID-System aussehen. Mit erstaunen stelle ich fest, dass nicht alle User dieses Boards unkonventionellen Ideen ablehnend gegenüber stehen.

Swordfish

@RBS2 Woosh!

. o O ( spätestens bei fseekall() wirds dann *wirklich* lustig )

RBS2

@Wade1234 sagte in Anfänger ?:

was ich mich grad so frage: warum gibt es eigentlich keine funktion _fopenall()? das wäre doch bestimmt total bequem, alle dateien auf einmal öffnen zu können.

Bei Windows gibt es das. Zumindest für einzelne Laufwerke.

To open a physical hard drive for direct disk access (raw I/O) in a Win32-based application, use a device name of the form
\.\PhysicalDriveN
where N is 0, 1, 2, and so forth, representing each of the physical drives in the system.

https://support.microsoft.com/en-us/help/100027/info-direct-drive-access-under-win32

der springende punkt ist einfach, dass dieses fcloseall dann auch alle internen dateihandles ungültig machen muss, was _fcloseall nicht tut, weshalb du im falle eines programmfehlers (verwendung von ungültigem dateideskriptor) keine fehlermeldung bekommst.

Bei Windows gibt es das. Zumindest für einzelne Laufwerke.

damit hast du direkten zugriff auf das laufwerk. so ähnlich wie open("/dev/sda", ...);