Εγγραφη και αναγνωση binary αρχειων απο C

[migf1]

Όλο ξεχνάω να το κάνω bookmark με αποτέλεσμα να το γκουγκλάρω όποτε το χρειάζομαι (κάθισα τώρα και το έκανα, έφτιαξα και φακελάκια )...

 

Στο παρακάτω link θα βρείτε λεπτομέρειες μεταξύ "text" και "binary" streams σύμφωνα με την στάνταρ C. Επί της ουσίας μόνο στα Windows (από τα δημοφιλή OS) έχει διαφορά, σε Posix είναι ακριβώς το ίδιο πράγμα.

 

http://c-faq.com/std...xtvsbinary.html

 

Ok. Απο οτι κατάλαβα δεν έχει σχεδον καμια διαφορά η ταχύτητα ανάγνωσης αλλα μόνο το μεγεθος του τελικού αρχείου.

Αν και πιστευα οτι τα binary files (fwrite, fread) είναι πιο γρηγορα σε αναγνωση. αφου δε χρησιμοποιεις ένα σωρο fscanf() για να διαδιαβασεις ένα file με πολλούς αριθμούς αλλα μόνο ένα pointer οριζεις.

 

Σωστα??

 

Η μόνη διαφορά σε κάποιες πλατφόρμες (Windows) είναι πως σε "text" mode το σύστημα θεωρεί δεδομένο πως το αρχείο είναι χωρισμένο σε γραμμές (κι ενδεχομένως περιέχει μόνο printable χαρακτήρες). Διάβασε το Link που έδωσα παραπάνω.

 

Βάζω κι εδώ σε spoiler την σχετική τεκμηρίωση του gcc (λίγο παλαιότερη έκδοση) ...

 

 

 

12.17 Text and Binary Streams

 

The GNU system and other POSIX-compatible operating systems organize all files as uniform sequences of characters. However, some other systems make a distinction between files containing text and files containing binary data, and the input and output facilities of ISO C provide for this distinction. This section tells you how to write programs portable to such systems.

 

When you open a stream, you can specify either a text stream or a binary stream. You indicate that you want a binary stream by specifying the ‘b’ modifier in the opentype argument to fopen; see Opening Streams. Without this option, fopen opens the file as a text stream.

 

Text and binary streams differ in several ways:

 

The data read from a text stream is divided into lines which are terminated by newline ('\n') characters, while a binary stream is simply a long series of characters. A text stream might on some systems fail to handle lines more than 254 characters long (including the terminating newline character).

On some systems, text files can contain only printing characters, horizontal tab characters, and newlines, and so text streams may not support other characters. However, binary streams can handle any character value.

Space characters that are written immediately preceding a newline character in a text stream may disappear when the file is read in again.

 

More generally, there need not be a one-to-one mapping between characters that are read from or written to a text stream, and the characters in the actual file.

 

Since a binary stream is always more capable and more predictable than a text stream, you might wonder what purpose text streams serve. Why not simply always use binary streams? The answer is that on these operating systems, text and binary streams use different file formats, and the only way to read or write “an ordinary file of text” that can work with other text-oriented programs is through a text stream.

 

In the GNU library, and on all POSIX systems, there is no difference between text streams and binary streams. When you open a stream, you get the same kind of stream regardless of whether you ask for binary. This stream can handle any file content, and has none of the restrictions that text streams sometimes have.

 

 

[nilosgr]

Φίλε nilosgr ομολογώ με μπέρδεψες. Για παράδειγμα, ο ακέραιος του 1ος byte uint8_t που έχει ας πούμε την τιμή 200 (μικρότερη δλδ του 1000) γιατί συμφέρει να τον αντιμετωπίσεις ως 3 διαφορετικά ASCII bytes ('2', '0' και '0') ?

Εννοουσα για int

Όχι και όχι.

 

Πρώτον έχεις κάνει ένα ουσιαστικό λάθος στην αποτίμηση των formats: ενώ λες ότι ο int είναι 4 bytes (προφανώς θεωρούμε ότι έτσι είναι στην πλατφόρμα, άρα κατευθείαν memory mapping) λες μετά ότι το "123" είναι 3 bytes. Πώς είναι δυνατόν ο deserializer να ξέρει ότι δεν ακολουθεί άλλο ψηφίο μετά; Στη γενική περίπτωση δε μπορεί, άρα θα χρειαστεί κάτι για delimiter επομένως από 3 χαρακτήρες θα πάμε σε 4, που είναι 33% αύξηση!

Nαι οντως, μου "διαφυγε" ο delimiter...

 

Δέυτερον η ταχύτητα ανάγνωσης/εγγραφής είναι dominated από το αποθηκευτικό μέσο και το stream stack του εκάστοτε runtime και όχι από αυτές τις παραμέτρους που αναφέρεις (αν κατάλαβα καλά τι εννοείς).

Δηλαδη;

[migf1]

@nilos:

 

Σε γενικές γραμμές φαντάζομαι πως εννοεί ο defacer ότι δεν παίζει ρόλο στην ταχύτητα το αν θα ανοίξεις το αρχείο σε "text" ή σε "binary" mode με τη fopen() (και όποιες fxxx() συναρτήσεις μεταχειριστείς στην συνέχεια για την διαχείρισή του).

 

Επίσης δεν παίζει γενικότερα ρόλο, εκτός από κάποιες εξαιρέσεις (π.χ. Windows).

 

Σε γενικές γραμμές επίσης, αν θέλουμε να γράψουμε cross-platform κώδικα, τότε ειδικά για αρχεία text προτιμούμε να τα ανοίγουμε σε "text" mode για να μην ασχολούμαστε εμείς με τις μετατροπές των αλλαγών γραμμής (κι ενδεχομένως κάποιων άλλων non-printable ascii bytes). Αλλά μπορούμε κάλλιστα να τα ανοίξουμε σε "binary" mode και να διαχειριστούμε μόνοι μας τις όποιες διαφορές από πλατφόρμα σε πλατφόρμα (κυρίως δλδ τις αλλαγές γραμμών)... αλλά δεν υπάρχει λόγος.

 

Εν ολίγοις, ο διαχωρισμός που έκανες στον αρχικό σου ποστ μεταξύ binary και ascii δεδομένων δεν υφίσταται σε αυτό που ρώτησε ο ts. Όλα τα δεδομένα αποθηκεύονται ως binary bytes σε όποιο mode κι αν έχεις ανοίξει το αρχείο, ενώ αλλάζει ελαφρώς ο τρόπος που διαβάζονται αν το έχεις ανοίξει σε "text" mode.

 

EDIT:

 

Αυτός ο διαχωρισμός που έκανες, μπορεί να φανεί χρήσιμος αν θες να κρυπτογραφήσεις ή να συμπιέσεις με κάποιον τρόπο τα δεδομένα σου πριν τα αποθηκεύσεις, και ομοίως να τα αποκρυπτογραφήσεις/αποσυμπιέσεις όταν τα διαβάζεις από το αρχείο.

 

Αυτό όμως δεν έχει να κάνει με το αν γράφονται/διαβάζονται ταχύτερα as text. Έτσι κι αλλιώς σε αυτές τις δουλειές πάντα σε binary mode δουλεύουμε.

[defacer]

Δηλαδη;

 

Το "αποθηκευτικό μέσο" περιλαμβάνει τυχόν καθυστερήσεις λόγω controller, seek times, πολλαπλά service requests την ίδια στιγμή κλπ -- δηλαδή χρόνο στον οποίο η CPU δε μπορεί να συνεχίσει την εκτέλεση του προγράμματος γιατί δεν έχουν έρθει ακόμα τα δεδομένα από τη συσκευή αποθήκευσης.

 

Το "stream stack" (όρος που έβγαλα από το καπέλο μου) περιλαμβάνει όλο το processing που γίνεται από το σημείο που καλείς την library function μέχρι τον controller και όταν επιστρέψουν τα δεδομένα από το σημείο που γράφονται στον κατάλληλο buffer του kernel του λειτουργικού μέχρι το σημείο που η κλήση της library function επιστρέφει και ο κώδικάς σου ξαναπαίρνει τον έλεγχο. Δηλαδή περιλαμβάνει

• Όλο το buffering που γίνεται σε όλα τα στάδια εκτός του κώδικά σου. Για παράδειγμα σε C++ ένα stream μπορεί να έχει δικό του buffering, και να υλοποιείται με βάση το C runtime το οποίο έχει δικούς του buffers, το οποίο καλεί τον driver της συγκευής που έχει άλλους buffers, και το λειτουργικό από μόνο του μπορεί να έχει δικούς του buffers.
  
• Λεπτομέρειες οι οποίες δεν είναι στον έλεγχο του κώδικά σου. Για παράδειγμα εσύ μπορεί να ζητήσεις read 1 byte, αλλά κανείς δεν απαγορεύει από το C runtime ή οποιοδήποτε παρακάτω layer να διαβάσει περισσότερα από τη συσκευή (στην πράξη αυτό γίνεται πάντα) και μάλιστα να τα κρατήσει για να ικανοποιήσει το "we could all see that coming" επόμενο read για 1 byte που θα ζητήσεις. Ο αριθμός και το μέγεθος των buffers παίζει τεράστιο ρόλο (δες παρακάτω).
  

Επειδή σε σύγκριση με τα υπόλοιπα το αποθηκευτικό μέσο είναι πάναργο, η μεγάλη διαφορά εμφανίζεται βάσει

1. του buffering που γίνεται (είτε από εσένα κατευθείαν είτε από κάποιο άλλο layer)
   
2. του κατά πόσο "ταιριάζει" το είδος του buffering με το είδος της πρόσβασης που κάνεις
   

Για παράδειγμα, αν κάποιο layer κάνει πολύ aggressive buffering και overread (π.χ. διαβάζει μίνιμουμ 4Κ κάθε φορά) ενώ εσύ χτυπάς ένα τεράστιο αρχείο με random reads των 32 bytes σε όλη του την έκταση τότε το buffering δε θα κάνει καλό αλλά κακό. Αντίθετα αν θέλεις να διαβάσεις το ίδιο αρχείο από την αρχή μέχρι το τέλος και το κάνεις 1 byte τη φορά τότε το ίδιο σύστημα θα απογειώσει την ταχύτητα (αφού μόνο 1 στα 4096 reads που δίνεις εσύ θα φτάνει μέχρι το αποθηκευτικό μέσο).

 

Μπορείς να τα δεις και μόνος σου στην πράξη αν κάνεις ένα πρόγραμμα που διαβάζει ένα > GB αρχείο με διάφορες "στρατηγικές" και διάφορα read sizes κάθε φορά.

[migf1]

Για αυτό και το ιδανικό από άποψης ταχύτητας είναι να διαβάζεται/γράφεται το αρχείο μονοκόμματα (και να διαχειρίζεται επίσης απευθείας πάνω στη μνήμη, με auto/on-demand saves).

 

Προφανώς κάτι τέτοιο είναι ανέφικτο για πολύ μεγάλα αρχεία, oπότε αναγκαστικά χρησιμοποιούνται άλλες τεχνικές, που συνήθως στοχεύουν σε το δυνατόν λιγότερα file accesses.

 

...

Αν και πιστευα οτι τα binary files (fwrite, fread) είναι πιο γρηγορα σε αναγνωση. αφου δε χρησιμοποιεις ένα σωρο fscanf() για να διαδιαβασεις ένα file με πολλούς αριθμούς αλλα μόνο ένα pointer οριζεις.

 

Σωστα??

 

Τώρα το πρόσεξα αυτό. Η fscanf() δουλεύει είτε το έχεις ανοίξει ως "text" είτε ως "binary" το αρχείο. Ομοίως και οι περισσότερες (αν όχι όλες, δεν το θυμάμαι) fxxx() στάνταρ συναρτήσεις.

 

Δεν υπάρχει δηλαδή τέτοιος διαχωρισμός, ότι π.χ. αν ανοίξεις ένα αρχείο ως "binary" να μην μπορείς να το διαβάσεις με fscanf(). Ομοίως μπορείς κάλλιστα να διαβάσεις ένα αρχείο που το έχεις ανοίξει ως "text" με την fread() και πάει λέγοντας.

 

Το μόνο που αλλάζει είναι ελαφρώς ο τρόπος της "μετάφρασης" των διαβασμένων, κι αυτό σε ορισμένες πλατφόρμες (π.χ. σε Posix δεν αλλάζει ούτε αυτό).

 

Δες για παράδειγμα σχετικό απόσπασμα από την τεκμηρίωση της fread() από την PellesC 6.50 (που είναι Windows specific compiler)

 

Description:

 

The fread function reads, into the array pointed to by dst, up to num elements whose size is specified by size, from the stream pointed to by stream. For each object, size calls are made to the fgetc function and the results stored, in the order read, in an array of unsigned char exactly overlaying the object. The file position indicator for the stream is advanced by the number of characters successfully read. If the file is open in text mode, CR-LF will be translated to LF. The translation will not affect the current file position nor the return value. If an error occurs, the resulting value of the file position indicator for the stream is indeterminate. If a partial element is read, its value is indeterminate.

 

Το μόνο που αλλάζει σε text-streams είναι ότι μεταφράζει τυχόν 2 byte sequences CR-LF (αλλαγές γραμμών) σε ένα LF byte.

 

EDIT:

 

Ξέχασα, ένα σημαντικό που πρέπει να σημειωθεί είναι πως οι fread()/fwrite() παράγουν/διαχειρίζονται endianess-aware αρχεία, οπότε ΔΕΝ μπορούν να χρησιμοποιηθούν σε περιβάλλοντα με άλλο endianess.

 

Αντίθετα, με τις fscanf()/fprintf() τα παργόμενα αρχεία γράφονται/διαβάζονται όμοια σε ολες τις πλατφόρμες.

[imitheos]

Η ερώτηση text vs binary του op τελικά αφορά fopen("τάδε", "r") και fopen("δείνα", "rb") ?

 

Εγώ διαβάζοντας το πρωί το μήνυμα του op, το εξέλαβα όπως ο nilosgr. Δηλαδή να γράψεις σε ένα αρχείο τον αριθμό 50 σαν ένα char ή int και το να το γράψεις σαν "50" δηλαδή '5' + '0' + \0.

 

Ή πιο κατανοητά ας πούμε ότι έχουμε μια struct την οποία γράφουμε κατευθείαν με fwrite μαζί με το padding της και ό,τι περιέχει (η "binary" μέθοδος) και το να γράφουμε σαν string ένα ένα όλα τα πεδία (η "text" μέθοδος).

[migf1]

Η ερώτηση text vs binary του op τελικά αφορά fopen("τάδε", "r") και fopen("δείνα", "rb") ?

 

Εμένα εκεί πήγε απευθείας το μυαλό μου, μιας και ο ts ρώτησε συγκεκριμένα σε C

 

Εγώ διαβάζοντας το πρωί το μήνυμα του op, το εξέλαβα όπως ο nilosgr. Δηλαδή να γράψεις σε ένα αρχείο τον αριθμό 50 σαν ένα char ή int και το να το γράψεις σαν "50" δηλαδή '5' + '0' + \0.

 

Εμένα αυτή η ερμηνεία μου κάνει ως language agnostic, και όχι συγκεκριμένα για C όπως ήταν η ερώτηση. Ενδεχομένως για αυτό και να μην την θεώρησα εξαρχής καν ως valid.

 

Ή πιο κατανοητά ας πούμε ότι έχουμε μια struct την οποία γράφουμε κατευθείαν με fwrite μαζί με το padding της και ό,τι περιέχει (η "binary" μέθοδος) και το να γράφουμε σαν string ένα ένα όλα τα πεδία (η "text" μέθοδος).

 

Δεν κατάλαβα τι εννοείς εδώ. Πως θα περάσεις ως string π.χ. ένα struct που αποτελείται από int, float, doubles, κλπ? Θα κάθεσαι να τα σπας σε ψηφία ένα-ένα για να θεωρηθεί "text" μέθοδος;

[imitheos]

Δεν κατάλαβα τι εννοείς εδώ. Πως θα περάσεις ως string π.χ. ένα struct που αποτελείται από int, float, doubles, κλπ? Θα κάθεσαι να τα σπας σε ψηφία ένα-ένα για να θεωρηθεί "text" μέθοδος;

 

>
struct mitsos {
   char onoma[30];
   char epitheto[50];
   int hlikia;
   int bathmos;
};

1)
fwrite(tade_variable, sizeof(struct mitsos), 1, myfile);

2)
... 
fprintf(myfile, "%d\n", tade.hlikia);
...

 

Ας πούμε ότι έχεις την παραπάνω δομή. Στην "binary" μέθοδο γράφεις με την fwrite όλη τη δομή μαζί με το padding και τα πάντα (ή έστω το κάθε πεδίο ένα-ένα με fwrite(tade.hlikia, sizeof(int), 1, myfile)) ενώ στην "text" μέθοδο γράφεις όλα τα πεδία σαν string και δεν μπλέκεις με padding, endianness, κτλ. Την "text" μέθοδο δηλαδή σκέψου την σαν μια πολύ απλοϊκή μπακάλικη serialisation.

 

Το πιο λογικό είναι να εννοεί να ανοίξεις το αρχείο σαν text ή binary όπως περιγράψατε, απλά για κάποιο λόγο και εμένα όπως και τον nilosgr μου ήρθε αυτό στο μυαλό.

[migf1]

Α οκ, τώρα κατάλαβα πως το εννοείς αυτό με το struct (αυτονόητο μεν, αλλά δεν πήγε καν το μυαλό μου).

 

Σχετικά με την ερμηνεία, το Νο.2 του ts δίνει όντως περιθώριο διαφορετικής ερμηνείας, αλλά και πάλι εφόσον μιλάει για ταχύτητα και όχι π.χ. για μέγεθος, νομίζω πως και πάλι παραπέμπει στις στάνταρ ορολογίες της C περί "binary" και "text" αρχείων.

 

Ας μας το ξεκαθαρίσει όμως, γιατί αν εννοεί αυτό που λέτε εσύ και ο nilos, τότε είναι τελείως διαφορετικό πράγμα (αν και πάλι δεν το βρίσκω να συμβαδίζει με ερώτηση περί ταχύτητας, κάτι τέτοιο θα ήταν πολύ πιο συμβατό π.χ. με ερώτηση περί μεγέθους).

[moukoublen]

Αν για παράδειγμα έχεις μια δομή ( struct a { int a; int b; short c; char d; char e; } ) και διαβάζεις πολλές εγγραφές αυτής της δομής από ένα δυαδικό αρχείο (οπότε έχουν γραφτεί δυαδικά σε αυτό) τότε - νομίζω - γλιτώνεις σε χρόνο (που μπορεί στο φινάλε να είναι παντελώς ασύμαντος) μιας και κάνεις απευθείας ανα ομάδες byte εκχώρηση των δεδομένων όπως ακριβώς τα διαβάζεις, στη μνήμη.

 

Αν είχες αποθηκεύσει πολλές έγραφες μιας τέτοιας δομής σε μορφή κειμένου, τότε έχεις και την επιπλέον καθυστέρηση του parse του να κάνει το κείμενο int. (Ξέχωρα που θέλεις και κάτι παραπάνω για να ξεχωρίσεις τον έναν int από τον άλλο).

 

EDIT - Δεν είχα δει τη δεύτερη σελίδα οπότε κάτι παρόμοιο έχει ξαναγραφεί.

 

Κοινώς (αφήνω έξω την ουσιαστική μηχανολογία του πράγματος που ανέφερε π.χ. ο defacer, και στέκομαι λίγο θεωρητικά αν μιλώντας για binary αρχείο μιλάμε αυτόματα και αυτονόητα για binary εγραφή των δεδομένων όπως τα έχεις στο πρόγραμμα -> στο αρχείο (δηλαδή για τον int γράφεις τα όσα byte σου υπαγορεύει το σύστημα στο αρχείο με το περιεχόμενο του int),

 

Δεν θα είναι λοιπόν πιο γρήγορο όταν θα έρθει η ώρα να διαβάσεις πολλές έγραφες αριθμών (που έχουν γραφεί δυαδικά) το να πάρεις από ένα stream - file - whatever και ανά -όσα υπαγορεύει το σύστημα - π.χ. 4 byte τα τα βάζεις κατευθείαν στη μνήμη όπως είναι;;;

 

Διαφορετικά αν διαβάζεις τους αριθμούς και εκείνοι έχουν γραφεί σαν string όπως είπε και ο imitheos θες και μία στοιχειώδη μετατροπή - parse - πριν τους καταχωρίσεις (στους αντίστοιχους int) στη μνήμη, έτσι δεν είναι (καθαρά θεωρητικά μιλώντας);

[panoupanou]

Παντως πρώτη φορά το συναντάω αυτο σε Forum. Μια ερώτηση έκανα και μετα απο λιγες ωρες έχει αναλυθεί πλήρως το θέμα . Καλο αυτο!

Τελικά αυτο που με ενδιαφέρει άμεσα ειναι (και φυσικα το συμπερασμα μου) είναι οτι δε χρειαζεται να αλλάξω στο κωδικα μου τον τροπο αποθηκευσης και ανακτησης απο ascii σε binary των αρχείων μου που συνηθως αποτελουνται απο 10.000.000 lines που καθε line έχει 1 δεκαδικο αριθμο.

 

Ευχαριστω για τις απαντησεις!

[migf1]

Παντως πρώτη φορά το συναντάω αυτο σε Forum. Μια ερώτηση έκανα και μετα απο λιγες ωρες έχει αναλυθεί πλήρως το θέμα . Καλο αυτο!

Τελικά αυτο που με ενδιαφέρει άμεσα ειναι (και φυσικα το συμπερασμα μου) είναι οτι δε χρειαζεται να αλλάξω στο κωδικα μου τον τροπο αποθηκευσης και ανακτησης απο ascii σε binary των αρχείων μου που συνηθως αποτελουνται απο 10.000.000 lines που καθε line έχει 1 δεκαδικο αριθμο.

 

Ευχαριστω για τις απαντησεις!

 

Αν επιτρέπεται πως τους γράφεις και πως τους διαβάζεις τώρα αυτούς τους 10.000.000 δεκαδικούς αριθμούς; Κι όταν λες δεκαδικούς, εννοείς πραγματικούς αριθμούς (δηλαδή float/double)?

 

Επίσης υπάρχουν min και max όρια στις τιμές για τον καθένα τους που δεν ξεπερνιούνται ποτέ;

 

Ρωτάω μήπως τελικά μπορέσουμε να το βελτιστοποιήσουμε (αν χρειάζεται δηλαδή).

[moukoublen]

Πάντως σε ένα γρήγορο - πρόχειρο τεστ που έκανα είχα:

 

Δυαδικό

>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(int argc, char **argv)
{
   time_t start, stop;
   FILE *pf;
   pf = fopen("data.bin","wb");
   int i = 0;
   int tmp = 0;
   time(&start);
   for(;i<10000000;i++){
       tmp = rand();
       fwrite(&tmp,sizeof(int),1,pf);
   }
   time(&stop);
   fclose(pf);
   printf("Time: %.2f\n", difftime(stop, start));
   return 0;
}

Έξοδος : Time: 1.00

Μέγεθος αρχείου: 38ΜΒ

 

 

Text Αρχείο

>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>[/font]
int main(int argc, char **argv)
{
   time_t start, stop;
   FILE *pf;
   pf = fopen("data.txt","w");
   int i = 0;
   int tmp = 0;
   time(&start);
   for(;i<10000000;i++){
       tmp = rand();
       fprintf(pf,"%d\n",tmp);
   }
   time(&stop);
   fclose(pf);
   printf("Time: %.2f\n",difftime(stop, start));
   return 0;
}

Έξοδος : Time: 2.00

Μέγεθος αρχείου: 100ΜΒ

 

Οπότε ίσως να έχεις μια μικρή (μπορεί και ελαχίστη) βελτιστοποίηση αν τα κάνεις binary (τα δεδομένα αρα και τα αρχεία)

[nilosgr]

Ναι, ομως αμα στο text file βαλουμε:

>for(;i<10000000;i++){
tmp = rand() % 1000;
fprintf(pf,"%d\n",tmp);
}

Mειωνεται σημαντικα κι ο χρονος (στο μισοο) και το μεγεθος στα ~47ΜΒ, δηλαδη εχει σημασια το ευρως και η κατανομη των ακεραιων

[migf1]

Ναι αλλά αν το περιορίσεις σε τιμές από 0 έως 999 (όπως κάνεις με το rand()/1000) τότε και το binary μπορείς να το ορισεις ως uint16_t αντί για int (που συνήθως αντιστοιχεί σε uint32_t)... οπότε θα μειωθεί κι εκείνου ο χρόνος πολύ... όπως προφανώς και το μέγεθος.

 

Κι αν το περιορίσεις από 0 έως 255 (uint8_t) τότε πέφτουν ακόμα περισσότερο και τα 2 (μέγεθος και χρόνος εννοώ) στο binary.

Επεξ/σία 9 Οκτωβρίου 2012 από migf1