Σφάλμα κατάτμησης (segmentation fault)

[παπι]

 

1ος τρόπος
    my_add(a, 
      int a,b;
   {
       return (a+;
    }

2ος τρόπος
  int a,b;
   my_add( )
     {
        extern a,b;
        return (a+;
      }

Void δεν υπάρχει πουθενά ως όρισμα των συναρτήσεων, τύπος επιστροφής σπάνια υπάρχει (πριν την C99 θεωρούταν ότι επιστρέφει int αν δεν υπήρχε). Για όσους δεν έχουν δει τον 1ο τρόπο γραφής, είναι ο pre-ansi τρόπος δήλωσης (δηλαδή όχι καν για C99 δεν μιλάει το βιβλίο αλλά ούτε καν για C89) όπου δινόταν μόνο το όνομα των μεταβλητών μέσα στις παρενθέσεις και ο τύπος γραφόταν από κάτω πριν το { και ο οποίος είναι deprecated εδώ και χρόνια και επίσης το πρότυπο δηλώνει ότι μπορεί να οδηγήσει σε UB (θα πει κάποιος σε C είναι πολύ εύκολο να έχεις UB αλλά με αυτό το τρόπο είναι γελοίο να έχεις UB και όχι απλά εύκολο).

 

Το πρωτο το ξερω, και αν δεν κανω λαθος, μπορεις να μην βαλεις int ουτε στα args. Το αλλο με το extern, πρωτη φορα το βλεπω χαχαχα.

[migf1]

Το "βαρβάτος" το είπα με την έννοια κάποιου που ασχολείται κι ενδιαφέρεται να μάθει αυτά που του διδάσκει η C. "Λευκό χαρτί" ναι, αλλά δε σημαίνει ότι όλοι έχουν την όρεξη να μάθουν αυτά τα πράγματα. Μπορεί κάποιον να τον ενδιαφέρει το web, άλλουν τα δίκτυα κλπ. Επίσης, δεν είπα ότι η C++ είναι "καλή" πρώτη γλώσσα, και δεν ξέρω C# για να έχω γνώμη.

Ποια είναι αυτά τα "πράγματα"; Σε ρώτησα και σε ένα άλλο ποστ να μου απαριθμήσεις 2-3 άλλα πράγματα για τα οποία είχες επιχειρηματολογήσει αόριστα, αλλά κι εκεί απέφυγες να απαντήσεις.

 

Επίσης δεν είπα ποτέ πως είπες ότι η C++ είναι καλή πρώτη γλώσσα. Εγώ την εισήγαγα στην συζήτηση, όπως και την Java, και την Python, και την C#, επειδή αποτελούν ένα πολύ μεγάλο ποσοστό από τις σημερινές δημοφιλείς γλώσσες, και αποτελούν στανταράκια ως απάντηση σχεδόν πάντα όταν κάποιος ρωτάει με ποια γλώσσα να ξεκινήσει.

 

Τέλος, όταν θέλεις να κάνεις προχωρημένα πράγματα, πρέπει να είσαι βαρβάτος ανεξαρτήτως γλώσσας. Πρέπει να έχεις εντρυφήσει όχι μόνο στις ιδιαιτερότητες της εκάστοτε γλώσσας, αλλά και στις ιδιαιτερότητες του εκάστοτε paradigm που έχεις επιλέξει. Προφανώς η κάθε γλώσσα έχει τις δικές της ιδιαιτερότητες, που δεν είναι κατ' ανάγκην κοινές. Π.χ. τα references στην C++ είναι άλλο πράγμα από τα references στην Java (ή/και στην C#).

 

Αυτός είναι ο λόγος για τον οποίο δε μ' αρέσει η C ως πρώτη γλώσσα. Το γεγονός ότι δε μπορείς να κάνεις τίποτα χωρίς pointers και αναγκάζεσαι να μάθεις κάτι το οποίο μπορεί και να μη σου χρειαστεί ποτέ είναι νομίζω αρκετό. Αντίθετα, μπορείς να ξεκινήσεις με μια γλώσσα με την οποία θα μάθεις πράγματα που μπορείς να μεταφέρεις παντού, είτε σ' ενδιαφέρει το system programming είτε το web είτε οτιδήποτε άλλο.

Καταρχήν μπορείς να κάνεις πάρα πολλά πράγματα χωρίς pointers, αλλά πιθανότατα δεν θα είναι resource efficient (hint: περνάς τα πάντα by value, ακόμα και τα struct).

 

Έπειτα, οι pointers όντως μπορεί να μη σου χρειαστούν σε άλλες γλώσσες, αλλά στις άλλες γλώσσες κατά 101% θα σου χρειαστούν τα references, τα οποία για πολύ κόσμο (εμού συμπεριλαμβανομένου) τα κατανοείς καλύτερα ή/και ταχύτερα αν έχεις ήδη μια έστω βασική εξοικείωση με τους pointers.

 

Ακόμα και στην Python, που θεωρείται (και είναι) αρκετά πιο εύκολη από άλλες, δες για παράδειγμα αυτό το link περί deep & shallow copy. Θεωρείς πιο εύκολο ή πιο δύσκολο να το κατανοήσεις, και κυρίως να το θυμάσαι, αν δεν είσαι ήδη εξοικειωμένος με pointers (εγώ το θεωρώ πιο δύσκολο).

 

Βέβαια, γλώσσες όπως η C++ και η C# όχι μόνο έχουν κι αυτές pointers, αλλά για να ΜΗΝ τους χρησιμοποιήσεις (αλλά ΚΑΙ για να τους χρησιμοποιήσεις) πρέπει να διαβάσεις και να μάθεις περίπου 5-πλάσια θεωρία από ότι στην C (να μην σου πω 10-πλάσια, αν και για να είμαστε απολύτως δίκαιοι, αυτό μάλλον εμπίπτει περισσότερο στο paradigm και στο library και λιγότερο στη γλώσσα).

 

Τέλος, και στην C μαθαίνεις πολλά πράγματα που μπορείς να μεταφέρεις παντού. Αυτό ισχύει με όλες τις γλώσσες, για αυτό για μένα δεν έχει σημασία με το ποια γλώσσα θα ξεκινήσει κανείς. Αλλά, δεν μεταφέρονται τα πάντα παντού, με όποια γλώσσα κι αν ξεκινήσεις.

[defacer]

Ποια είναι αυτά τα "πράγματα"; 

 

Pointer arithmetic χεράκι χεράκι με sizeof καλά είναι για αρχή;

[migf1]

Pointer arithmetic χεράκι χεράκι με sizeof καλά είναι για αρχή;

 

Άλλα "λευκά χαρτιά" δεν έχουν όρεξη να μάθουν pointer arithmetic, κι άλλα "λευκά χαρτιά" δεν έχουν όρεξη να μάθουν ας πούμε multiple inheritance. So what? Και τα δυο "λευκά χαρτιά" μπορούν να κάνουν την δουλειά τους με άλλους τρόπους. Όσο άχρηστο είναι για σένα το pointer arithmetic, άλλο τόσο άχρηστο είναι για κάποιον άλλον το multiple inheritance. Δεν είναι επιχείρημα αυτό, ούτε για τον έναν ούτε για τον άλλον και σίγουρα δεν είναι επιχείρημα για την καταλληλότητα ή όχι κάποιας γλώσσας για εισαγωγή στον προγραμματισμό (και ακόμα πιο σίγουρα, σπάνια διδάσκονται είτε το ένα είτε το άλλο σε εισαγωγικό εξάμηνο... σπάνια χρειάζονται επίσης σε εισαγωγικά courses).

 

At the end of the day πάντως, οι "βαρβάτοι" τα ξέρουν και τα δυο.

 

Παρεμπιπτόντως, το pointer arithmetic καταργεί την ανάγκη του sizeof, οπότε εκείνο το "χεράκι-χεράκι" είναι ολίγον σουρεάλ.

[defacer]

Συγγνώμη, το multiple inheritance το έβλεπες χθες στον ύπνο σου; Γιατί δεν έχω ιδέα διαφορετικά πώς μπήκε στην κουβέντα.
 
FYI θεωρώ (εν συντομία) πως το multiple inheritance είναι χειρότερο από άχρηστο αν είσαι κάτω από master level και σχεδόν άχρηστο (αλλά τουλάχιστον εκεί δε μπορεί να κάνει κακό γιατί το χρησιμοποιείς μόνο κατα συνειδητή επιλογή) αν είσαι master level. Άσχετα όμως από την προσωπική μου γνώμη, κανείς δεν είπε ούτε ότι είναι καλό να μαθαίνεις multiple inheritance, ούτε καν να μαθαίνεις με C++. Επομένως όχι μόνο δεν ξέρω από πού σου ήρθε αλλά δεν καταλαβαίνω και τι προσπαθείς να πεις.
 
Απλά και κατανοητά: ήθελες να σου δώσει κάποιος ένα παράδειγμα πράγματος που αναγκάζεσαι να μάθεις χωρίς πιθανότατα να "χρειάζεται" για να ξέρεις προγραμματισμό -- μιας και ήταν τόσο δύσκολο που δεν το καταλάβαινες από τα λεγόμενα του Kercyn -- σου έδωσα εγώ.

 

Μάλιστα όχι απλά ήθελες να σου το πουν αλλά "παραπονέθηκες" κιόλας ότι το ζητάς ευγενικά και σε "αποφεύγουν" επιμένοντας να "επιχειρηματολογούν αόριστα":
 

Ποια είναι αυτά τα "πράγματα"; Σε ρώτησα και σε ένα άλλο ποστ να μου απαριθμήσεις 2-3 άλλα πράγματα για τα οποία είχες επιχειρηματολογήσει αόριστα, αλλά κι εκεί απέφυγες να απαντήσεις.

 
Τώρα άλλα λόγια ν' αγαπιόμαστε;
 
Το αν το pointer arithmetic καταργεί την ανάγκη του sizeof κάνε ένα διάλειμμα να δεις μια τυπική κλήση malloc για πίνακα ακεραίων (ξέρεις από αυτές που συναντά κανείς πάρα πολύ συχνά σε κώδικα εκμάθησης) ή μια fwrite (ξέρεις την άλλη κλασική περίπτωση που κάνεις το προφανές naive serialization) και μετά ξαναπές μου για σουρεάλ.

[Kercyn]

Δε συμφωνώ ότι μπορείς να κάνεις πολλά πράγματα χωρίς pointers στη C κυρίως λόγω του ότι ένα string είναι ένας πίνακας από char (= pointer). Άμα δεν το χρησιμοποιήσεις αυτό χάνεις ό,τι έχει να κάνει με strings. Όπως είπα, υπάρχουν πολλά "είδη" προγραμματισμού (system, web, software κλπ) και η C εστιάζει κυρίως στο system. Αυτό κατά τη γνώμη μου είναι κακό (πάντα για πρώτη γλώσσα που σκοπό έχει να σου μάθει μερικές γενικές αρχές προγραμματισμού) γιατί εστιάζεις σε ένα πολύ συγκεκριμένο κομμάτι και μαθαίνεις πράγματα γι' αυτό, ενώ πιστεύω ότι πρέπει η πρώτη σου γλώσσα να είναι "ελεύθερη" από τέτοια στοιχεία ούτως ώστε να μπορείς να μαθαίνεις πιο γενικές αρχές.

 

Παράδειγμα, έχω έναν πίνακα από κάτι και θέλω να βάλω ένα καινούριο στοιχείο και στη συνέχεια να βγάλω ένα άλλο. Στη C πρέπει πρώτα να δεσμεύσω μνήμη για το καινούριο στοιχείο και μετά να βάλω αυτό που θέλω. Για να βγάλω το στοιχείο, πρέπει να αποδεσμεύσω τη μνήμη του (αφού πρώτα το έχω βρει manually) και στη συνέχεια πιθανότατα να αναδιανείμω τα στοιχεία του για να μην έχω κενή μνήμη στη μέση του πίνακά μου. Αυτές τις διαδικασίες σκέψου τις ως μέρος άσκησης που δεν έχει καμία σχέση με τη διαχείριση μνήμης και σκοπός της είναι να σου δείξει κάτι άλλο. Σε μια άλλη γλώσσα μπορείς να επικεντρωθείς μόνο στο θέμα της άσκησης. Στη C, θες δε θες θα κάνεις μόνος σου όλη τη διαχείριση της μνήμης για ό,τι θες. Θα μου πεις σε όλες τις γλώσσες μπορεί να είσαι αναγκασμένος να κάνεις κάτι που μπορεί να μην έχει σχέση με αυτό που θες να διδάξεις, απλώς στη C αυτά τα πράγματα είναι περισσότερα και πιο "δύσκολα" στην κατανόηση/υλοποίηση από κάποιον που τώρα ξεκινάει.

[gon1332]

Από την άλλη όμως στη Java ένας νέος έχει να μάθει

ένα σωρό κανόνες για scoping, ενώ στη C μόνο τρεις,

έστω τέσσερις με το static. Σε 10 λεπτά  ξεμπέρδεψες

με τη διδασκαλία για scoping.

 

Η κάθε γλώσσα έχει τα δικά της και για κάθε γλώσσα

μπορούμε να σταθούμε σε ένα σωρό μειονεκτήματα.

Το θέμα είναι να έχεις κάποιον που την γνωρίζει για

να στη διδάξει, αλλά κυρίως να έχεις κίνητρο. Μετά

όλα γίνονται. Όπως με συμβούλευε ένας καθηγητής

στα πρώτα χρόνια: "Πρέπει να μάθεις να διαχωρίζεις

τους καθηγητές από τα μαθήματα". Αν κάποιος καθη-

γητής είναι αδιάφορος ή δεν μπορεί να κάνει το μάθημα

δεν πρέπει να μας παίρνει η κατηφόρα και να μας τρώει

το μοιρολόι. Αυτοί είναι βολεμένοι κατά κάποιον τρόπο.

Οι φοιτητές είναι αυτοί που πρέπει να χτίσουν το μέλλον

τους και αυτό είναι αποκλειστικά στα χέρια τους.

 

Επίσης, δε μπαίνεις σε μία τέτοια σχολή για να γίνεις

"Ο προγραμματιστής". Θα μάθεις C για να μάθεις και

κάτι παραπάνω. Θέλοντας και μη θα ασχοληθείς και

με διαχείρηση μνήμης, αλλά θα έχεις κάποια βάση για

άλλα μαθήματα. Στο μάθημα των αλγορίθμων μπορούν

να σου βάλουν όποια γλώσσα θέλουν. Εμείς για παρά-

δειγμα είχαμε Java. Μακάρι να είχαμε Python. Αν κάποιον

τον χαλάει η C στο πρώτο εξάμηνο, πήγαινε να δεις τί

γίνεται με την Γραμμική Άλγεβρα και τον Μαθηματικό

Λογισμό 1 και μη μου πείτε πως αυτά δεν έπρεπε να

διδάσκονται. Παρεπιπτόντως ένα από τα μαθήματα που

είχαν από πίσω τους στρατιά φοιτητών για να το περάσουν

ήταν ο αντικειμενοστραφής προγραμματισμός με Java.

Πως και έτσι σε μία υψηλού επιπέδου και hot γλώσσα;

Θέλω να πω πως όποιος θέλει τα καταφέρνει και μαθαίνει

και αλγοριθμική σκέψη και με C και με assembly και άλλα

πολλά.

[migf1]

Συγγνώμη, το multiple inheritance το έβλεπες χθες στον ύπνο σου; Γιατί δεν έχω ιδέα διαφορετικά πώς μπήκε στην κουβέντα.

 

FYI θεωρώ (εν συντομία) πως το multiple inheritance είναι χειρότερο από άχρηστο αν είσαι κάτω από master level και σχεδόν άχρηστο (αλλά τουλάχιστον εκεί δε μπορεί να κάνει κακό γιατί το χρησιμοποιείς μόνο κατα συνειδητή επιλογή) αν είσαι master level. Άσχετα όμως από την προσωπική μου γνώμη, κανείς δεν είπε ούτε ότι είναι καλό να μαθαίνεις multiple inheritance, ούτε καν να μαθαίνεις με C++. Επομένως όχι μόνο δεν ξέρω από πού σου ήρθε αλλά δεν καταλαβαίνω και τι προσπαθείς να πεις.

 

Απλά και κατανοητά: ήθελες να σου δώσει κάποιος ένα παράδειγμα πράγματος που αναγκάζεσαι να μάθεις χωρίς πιθανότατα να "χρειάζεται" για να ξέρεις προγραμματισμό -- μιας και ήταν τόσο δύσκολο που δεν το καταλάβαινες από τα λεγόμενα του Kercyn -- σου έδωσα εγώ.

 

Μάλιστα όχι απλά ήθελες να σου το πουν αλλά "παραπονέθηκες" κιόλας ότι το ζητάς ευγενικά και σε "αποφεύγουν" επιμένοντας να "επιχειρηματολογούν αόριστα":

 

 

Τώρα άλλα λόγια ν' αγαπιόμαστε;

Μάλιστα! Δεν σου αρέσει το multiple inheritance ως παράδειγμα. Η κλάση λοιπόν είναι ένα πράγμα που αναγκάζεσαι να μάθεις σε oop γλώσσες χωρίς πιθανότατα να "χρειάζεται" για να ξέρεις προγραμματισμό;

 

Το αν το pointer arithmetic καταργεί την ανάγκη του sizeof κάνε ένα διάλειμμα να δεις μια τυπική κλήση malloc για πίνακα ακεραίων (ξέρεις από αυτές που συναντά κανείς πάρα πολύ συχνά σε κώδικα εκμάθησης) ή μια fwrite (ξέρεις την άλλη κλασική περίπτωση που κάνεις το προφανές naive serialization) και μετά ξαναπές μου για σουρεάλ.

Take your facts straight. Ξέρεις τι σημαίνει pointer-arithmetic και ποια η σχέση του με το sizeof; Εσύ έγραψες για "χεράκι-χεράκι" δεν το έγραψα εγώ. Η malloc και η fwrite έχουν άμεση σχέση με το sizeof και προαιρετική για τον προγραμματιστή σχέση με το pointer-arithmetic. Aν δεν καταλαβαίνεις το pointer-arithmetic ή δεν σε ενδιαφέρει να το μάθεις, μη το χρησιμοποιείς. Χρησιμοποίησε array-indexing notation instead.

 

There you have it!

 

@Kercyn:

 

Θα σε παραπέμψω στο C Programming: A Modern Approach - 2nd Edition. Τους δείκτες τους εισαγάγει στο κεφάλαιο 11 (τους πίνακες στο κεφάλαιο 8). Τα προγράμματα-παραδείγματα που περιέχει μέχρι ΚΑΙ το κεφάλαιο 10 (χωρίς δηλαδή να έχει μιλήσει για δείκτες) ξεκινάνε με υπολογισμό τρισδιάστατου βάρους μιας κούτας, και φτάνουν μέχρι quick-sort και poker hand evaluation. Νομίζω πως έχει πολύ ενδιαφέρον να ρίξεις μια ματιά και στα ενδιάμεσα παραδείγματα, γιατί νομίζω πως θα αναθεωρήσεις.

 

@gon:

 

Είσαι ο μόνος μέσα στο νήμα με τον οποίον εκπέμπουμε στο ίδιο "μήκος κύματος" (μήπως να το κοιτάξεις; διότι δεν είμαι από τα δημοφιλέστερα μέλη του φόρουμ )

 

Που λες, μακάρι να ήτανε μόνο το scope. Η ουσία εδώ για μένα είναι το procedural vs oop. Το oop είναι πολύ πιο πολύπλοκο paradigm από ότι το procedural. Εδώ κολλάει σε μεγάλο βαθμό κι εκείνο το περί 5-πλάσιας και 10-πλάσιας θεωρίας που είχα γράψει σε ένα προηγούμενο ποστ. Και υπάρχει λογική πίσω από αυτό: το oop λάμπει σε μεγάλα πρότζεκτ (αυτός είναι κι ένας βασικός λόγος για τον οποίον "εφευρέθηκε"). Σε μικρά πρότζεκτ συνήθως είναι overkill (εκεί λάμπουν τα procedural και functional paradigms) ενώ τα μεσαία πρότζεκτ είναι "γκρίζα ζώνη" (εννοώντας πως συνήθως και τα 3 paradigms μπορούν αν χρησιμοποιηθούν με παραπλήσια αποτελεσματικότητα, αποδοτικότητα, κλπ).

 

Η προσωπική μου άποψη είναι πως το procedural είναι το ιδανικό για εισαγωγή στον προγραμματισμό, λόγω της αμεσότητας, της απλότητας και της πολύ πιο εύκολης κατανόησής τους συγκριτικά με τα oop και functional.

 

Πάμε στις γλώσσες τώρα. Η C είναι από τις πλέον λιτές αν όχι η πιο λιτή από τις δημοφιλείς γλώσσες. Σίγουρα είναι πολύ πιο λιτή από τις C++, Java και C# (δεν μπορώ εύκολα να πω το ίδιο και για την python, γιατί κι αυτή λιτή είναι ως σύνταξη, keywords, κλπ).

 

Αυτό λοιπόν για μένα πάντα είναι και καλό και κακό από εκπαιδευτικής πλευράς.

 

Καλό γιατί "ξεμπερδεύεις" γρήγορα με τα τυπικά (ένα παράδειγμα είναι ας πούμε το scope που ήδη ανέφερες, άλλο παράδειγμα είναι η έλλειψη σχεδόν ΟΛΗΣ της OOP θεωρίας που αναγκαστικά "κουβαλάνε" μαζί τους όσες γλώσσες υποστηρίζουν OOP).

 

Κακό γιατί για τα περισσότερα από τα μη τετριμμένα πρέπει να χρησιμοποιήσεις δείκτες. Αυτό με τη σειρά του περιέχει και καλά και κακά στοιχεία. Κακά επειδή συγχωρεί πολύ πιο δύσκολα τα λάθη, καλά επειδή άπαξ και τους μάθεις δεν χρειάζεται να μάθεις κανένα άλλο language construct, term, κλπ. Τι εννοώ; Π.χ. η C++ έχει 3-4 διαφορετικούς τύπους δεικτών συν references, η C# έχει κι αυτή δείκτες αλλά και references και delegates, κλπ.

Στη C τα κάνεις όλα με μια κοινή έννοια του όρου δείκτη (ίσως με 2, αν θέλει κάποιος να τους διαχωρίζει σε function και σε μη-function pointers).

 

Όσο πιο advanced όμως γίνονται τα μαθήματα και μεγάλα τα projects (συνήθως δλδ από το 2ο εξάμηνο και μετά) τόσο περισσότερο αρχίζουν να φαίνονται οι περιορισμοί του procedural, ή αν προτιμάς τόσο περισσότερο αρχίζει να "make sense" η έξτρα πολυπλοκότητα του OOP.

 

Ιδανικά, για μένα πάντα, ένας επίδοξος βαρβάτος προγραμματιστής οφείλει να είναι εξοικειωμένος και με τα 2 paradigms (και με αρκετά ακόμα - εδώ δεν εννοώ απαραίτητα νέα paradigms, αλλά και πιο advanced πράγματα, π.χ. design patterns, που ιδανικά είναι paradigm-agnostic, αλλά κι αυτά συνήθως ταιριάζουν καλύτερα με κάποιο ή κάποια paradigms).

 

ΥΓ. Προφανώς το νήμα έχει ξεφύγει από το "εισαγωγή στον προγραμματισμό".

[defacer]

Μάλιστα! Δεν σου αρέσει το multiple inheritance ως παράδειγμα. Η κλάση λοιπόν είναι ένα πράγμα που αναγκάζεσαι να μάθεις σε oop γλώσσες χωρίς πιθανότατα να "χρειάζεται" για να ξέρεις προγραμματισμό;

 

 

Take your facts straight. Ξέρεις τι σημαίνει pointer-arithmetic και ποια η σχέση του με το sizeof; Εσύ έγραψες για "χεράκι-χεράκι" δεν το έγραψα εγώ. Η malloc και η fwrite έχουν άμεση σχέση με το sizeof και προαιρετική για τον προγραμματιστή σχέση με το pointer-arithmetic. Aν δεν καταλαβαίνεις το pointer-arithmetic ή δεν σε ενδιαφέρει να το μάθεις, μη το χρησιμοποιείς. Χρησιμοποίησε array-indexing notation instead.

 

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

 

Τις παπαριές περι pointer arithmetic και sizeof αναρωτιέμαι, τις σκέφτεσαι πολύ πριν τις πεις; Αυτό το σούπερ κλασικό παράδειγμα είναι που χρειάζεται να το καταλάβουν όλοι, και αυτή είναι η κλασική ερώτηση την οποία έτυχε να απαντήσω πριν καιρό στο SO. Ένας θεός ξέρει πόσες φορές έχει διατυπωθεί.

 

There you have it my ass.

[migf1]

Το μόνο που έχω να σου πω είναι πως είσαι επικίνδυνα & τραγικά άσχετος από pointer-arithmetic!

 

Όταν κι εάν καταλάβεις ποτέ πως το pointer-arithmetic είναι διευκόλυνση για να μην υπολογίζεις manually το sizeof όταν κάνεις indexing (ισοδύναμο δλδ με το array-indexing notation), ίσως και να ξανασχοληθώ μαζί σου.

 

EDIT:

 

Α, ξέχασα. Ενημέρωσε επίσης και τους linux-άδες πως είναι obsolete εν έτη 2015.

Επεξ/σία 15 Ιανουαρίου 2015 από migf1

[nucleus]

To ότι η τελευταία απάντηση του op είναι στην πρώτη σελίδα και είμαστε στην τρίτη όσο και εποικοδομητική να είναι η συζήτηση μήπως δεν είναι το σωστό μέρος να γίνει?