Προγραμματισμος σε C

[imitheos]

Σας ευχαριστω ολους και παλι για τις απαντησεις αν και αισθανομαι λιγο πιο μπερδεμενος απο πριν με ολα αυτα...τελος παντων...

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

 

Δεν πρέπει να μείνεις με την σύγχυση. Γράψε μας ποια points σε μπέρδεψαν και θα προσπαθήσουμε να τα εξηγήσουμε καλύτερα.

[Liam Lawrence]

Koιτα...το να διαφωνειτε μεταξυ σας για καποια θεματα πανω στην γλωσσα με την οποια εγω δεν εχω καμια σχεση (αρα τα παντα μου φαινονται πρωτογνωρα) με μπερδεψε αρκετα...Ξερω οτι για να μαθεις να προγραμματιζεις θα πρεπει να εχεις στο μυαλο σου να κανεις κατι (π.χ. μια εφαρμογη, ενα video game, μια ιστοσελιδα κτλ.)...Εγω προσωπικα ακομα δεν ξερω με τι ακριβως θελω να ασχοληθω...τεινω βεβαια προς τον τομεα της ηλεκτρονικης ασφαλειας...τωρα τι γλωσσες χρειαζεται για αυτο δεν ξερω και ουτε ξερω και που πρεπει να απευθυνθω η τι πρεπει να κανω για να μου λυθουν τετοιου ειδους αποριες

[migf1]

@imitheos:

 

Δεν είναι όλα ρόδινα για τους αρχάριους ούτε στα managed-strings (remember: "there is no free lunch"):

 

Java:

1. http://www.thejavageek.com/2013/07/27/string-comparison-with-equals-and-assignment-operator/

2. http://www.programcreek.com/2013/09/string-is-passed-by-reference-in-java/

3. http://stackoverflow.com/questions/334518/java-strings-string-s-new-stringsilly

 

Ούτε στα managed classes γενικώς (επειδή ανάφερες τα structs της C):

Python:

1. http://stackoverflow.com/questions/9453820/alternative-to-python-string-item-assignment

2. https://docs.python.org/2/library/copy.html

3. http://stackoverflow.com/questions/19068707/slicing-operation-give-deep-copy-or-shallow-copy

 

That being said, κανείς δεν αμφισβήτησε πως η python και η java είναι πιο high-level από τις C και C++.

 

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

 

Το αν είναι καλύτερο να ξεκινήσει κάποιος από high-level και να πάει σε low-level, ή το αντίθετο, δεν είναι κάτι για το οποίο υπάρχει ομόφωνη άποψη. Ως συνήθως οι απόψεις διίστανται.

 

That being said (again ) το να επιχειρήσει κάποιος αρχάριος να μάθει αυτοδίδακτα C ούτε εγώ νομιζω πως είναι η καλύτερη επιλογή, για αυτό και πρότεινα εξαρχής Python κι εγώ.

 

Επιμένω όμως (εννοείται πάντα κατά την άποψή μου) πως ότι και να διαλέξει κάποιος αρχάριος είναι καλό να το επικεντρώσει σε δημοφιλή γλώσσα που να υποστηρίζει ένα μόνο paradigm (ή σχεδόν μόνο ένα). Για imperative paradigm η C είναι τοπ στη δική μου λίστα (ιδανικά σε ακαδημαϊκό πλαίσιο) , για oop η Java, ενώ για functional δεν έχω κατασταλαγμένη άποψη.

 

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

 

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

 

 

[Kercyn]

 

 

 

public static void change(StringBuilder x) {
    x.delete(0, 2).append("cd");
}

:lol: J A V A B O Y S :lol:

 

 

 

Φίλε OP το καλύτερο που έχεις να κάνεις είναι να μην επικεντρωθείς σε κάτι αυτή τη στιγμή. Όταν με το καλό περάσεις στη σχολή σου, προσπάθησε να μάθεις όσα περισσότερα μπορείς (δηλαδή μην κάνεις το λάθος να πεις "αυτό δε μου χρειάζεται άρα δεν το μαθαίνω"). Όσο περνάει ο καιρός θα βρεις κάτι που να σου αρέσει περισσότερο από τα άλλα.

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

[denisbarko]

Στον σύνδεσμο αυτόν θα βρεις το κανάλι του ΤΕΙ Πειραιά στο YouTube. Τα playlists που βλέπεις είναι από βιντεοσκοπημένες διαλέξεις για το Project των ανοιχτών μαθημάτων που κάνουνε. Μέχρι στιγμής μπορώ να σου πω για C στην λίστα "ΚΟΥΚΟΥΛΕΤΣΟΣ" και για MatLab στην λίστα "ΒΕΛΩΝΗ". Τα υπόλοιπα δεν τα'χω κοιτάξει.

[imitheos]

Στον σύνδεσμο αυτόν θα βρεις το κανάλι του ΤΕΙ Πειραιά στο YouTube. Τα playlists που βλέπεις είναι από βιντεοσκοπημένες διαλέξεις για το Project των ανοιχτών μαθημάτων που κάνουνε. Μέχρι στιγμής μπορώ να σου πω για C στην λίστα "ΚΟΥΚΟΥΛΕΤΣΟΣ" και για MatLab στην λίστα "ΒΕΛΩΝΗ". Τα υπόλοιπα δεν τα'χω κοιτάξει.

Ωραίο κανάλι δεν το ήξερα.

 

Οι διαλέξεις για την C σου άρεσαν ? Δεν είδα όλες τις διαλέξεις φυσικά αλλά οι δύο πρώτες που είδα δεν μπορώ να πω ότι με ενθουσίασαν. Ίσως κάνω λάθος αλλά δεν μου φαίνεται ότι έχει καλή μεταδοτικότητα ο συγκεκριμένος καθηγητής.

 

Επίσης δεν μου άρεσαν κάποιες ανακρίβειες που άκουσα. Μία από αυτές είναι το κλασικό θέμα της main. Το έχουμε αναλύσει 1000άδες φορές στο φόρουμ και ίσως έχει γίνει κουραστικό για κάποιους να το διαβάζουν αλλά η διατύπωση εδώ είναι χειρότερη και από τις κλασικές κακές διατυπώσεις που συναντούμε.

 

Άκουσα τον εκφωνητή να λέει "ο τρόπος με τον οποίο γράφω την main εξαρτάται από τον compiler....όλοι οι τρόποι είναι αποδεκτοί απλά ο τρόπος που έχουμε γράψει στο πίνακα είναι σύμφωνα με το πρότυπο ANSI C" και το slide γράφει:

 

Ο ορισμός της συνάρτησης main

int main()

έχει γίνει σύμφωνα με το πρότυπο ANSI C όπως μπορεί να γίνει και με άλλο τρόπο όπως:

main()
int main(void)
void main()

 

Το πρότυπο δεν λέει ότι πρέπει να γράφουμε "int main()" και εννοείται πως _δεν_ είναι όλοι οι τρόποι αποδεκτοί. Αυτό που βλέπουμε συνήθως (και που το κράζουμε) είναι να χρησιμοποιείται void main() από άγνοια ή αδιαφορία. Εδώ όμως βλέπουμε να προτείνεται κιόλας σαν εναλλακτικός τρόπος δήλωσης

 

Άλλες κλασικές ανακρίβειες είναι "Η μεταβλητή τύπου int (ακεραίου τύπου) στη γλώσσα c καταλαμβάνει 4 bytes".

 

Edit: "Από τους δύο τρόπους (μιλάει για #define και const) ίσως πιο ευκολόχρηστος είναι αυτός με το #define γιατί πρώτα από όλα μπαίνουν οι μεταβλητές στο πάνω μέρος του προγράμματος και εύκολα ο προγραμματιστής βλέπει τις μεταβλητές"

 

ΥΓ: Σε καμμία περίπτωση δεν θέλω να προσβάλω τον εκφωνητή απλά ανέφερα κάποια πράγματα που δεν μου άρεσαν από διδακτική σκοπιά.

Επεξ/σία 18 Ιουλίου 2015 από imitheos

[Ilias95]

@imitheos
Άσε, το τι διδάσκουν στις περισσότερες σχολές ειδικά για παλιές γλώσσες όπως C/C++ είναι για πολύ κλάμα...

Δες πχ. το hello world που μας δίνει ο άλλος στις σημειώσεις του για C++ οι οποίες είναι από το '98 (!!!), αλλά πολύ αμφιβάλω αν έκανε compile αυτό το «πράγμα» ακόμα σε κάποιον compiler του τότε.

#include <iostream.h>

main()
{
    cout << "Hello C++" << endl;

    return(0);
}

 
 

Φαντάσου με 3 (ή 4 αν θες) τρανταχτά λάθη στο hello world, πως είναι οι υπόλοιπες σημειώσεις...

[παπι]

Να τον προσβαλεις. Γιατί όχι; Είναι αστεία λάθη. Γιατί να μιλήσει σε έναν αρχάριο για το ποσό χώρο πιάνουν οι οι τύποι; Μάλιστα κάνοντας και λάθος.

 

Απλά πράματα, int = ακέραιος double = πραγματικός. ,next

[imitheos]

Να τον προσβαλεις. Γιατί όχι; Είναι αστεία λάθη. Γιατί να μιλήσει σε έναν αρχάριο για το ποσό χώρο πιάνουν οι οι τύποι; Μάλιστα κάνοντας και λάθος.

 

Απλά πράματα, int = ακέραιος double = πραγματικός. ,next

Ναι για αρχή τουλάχιστον θα μπορούσε να το παραλείψει. Ίσως το έκανε για να εξηγήσει για ποιο λόγο υπάρχουν short, int, long αντί για ένας τύπος μόνο.

 

Γενικά πάντως υπάρχουν δυστυχώς πάρα πολλά λάθη:

 

char c=127, d=128, e=129;
printf("%d %d %d\n",c,d,e);

* Στο παραπάνω παράδειγμα θα εμφανιστούν οι τιμές 127 -127 -126

 

Τώρα βλέπω την ενότητα δύο και υπάρχει το παραπάνω slide. Παραβλέποντας το θεωρητικό σενάριο (υπερχείλιση ενός signed αριθμού είναι UB και μπορεί να συμβεί οτιδήποτε), πρακτικά στις περισσότερες περιπτώσεις θα εμφανιστούν 127 -128 -127 λόγω συμπληρώματος ως προς δύο και όχι αυτό που γράφει.

 

* Στην C οι χαρακτήρες κωδικοποιούνται με αριθμούς χρησιμοποιώντας την κωδικοποίηση ASCII.

* Έχει 95 εκτυπώσιμους χαρακτήρες από 32 έως 126.

Ποιος του το είπε αυτό ?

 

* Για την αποφυγή αυτού του προβλήματος χρησιμοποιείται η συνάρτηση fflush() που καθαρίζει ότι έχει μείνει στον buffer και έχει σαν παράμετρο το stdin

Ίσα-ίσα δεν πρέπει να χρησιμοποιείται με το stdin.

 

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

[migf1]

...

Γενικά πάντως υπάρχουν δυστυχώς πάρα πολλά λάθη:

char c=127, d=128, e=129;
printf("%d %d %d\n",c,d,e);

* Στο παραπάνω παράδειγμα θα εμφανιστούν οι τιμές 127 -127 -126

 

Τώρα βλέπω την ενότητα δύο και υπάρχει το παραπάνω slide. Παραβλέποντας το θεωρητικό σενάριο (υπερχείλιση ενός signed αριθμού είναι UB και μπορεί να συμβεί οτιδήποτε), πρακτικά στις περισσότερες περιπτώσεις θα εμφανιστούν 127 -128 -127 λόγω συμπληρώματος ως προς δύο και όχι αυτό που γράφει.

...

 

 

Κανένα από τα δυο δεν είναι ακριβές. Το πρότυπο δεν επιβάλλει ο char να είναι signed ή unsigned. Είναι implementation dependent. Άρα, σε όποιον compiler ο char είναι by default unsigned, ο παραπάνω κώδικας θα τυπώσει κανονικά:

127 128 129

Σε αυτές τις περιπτώσεις καλό είναι να ορίζουμε explicitly τις μεταβλητές μας είτε ως signed είτε ως unsigned char, ώστε να μη μας επηρεάζει το implementation dependency (το οποίο btw σε όλους τους σοβαρούς compilers αλλάζει και από τη γραμμή εντολών... π.χ. στον gcc με -funsigned-char και -fsigned-char).

 

Γενικώς πάντως, από το (πολύ) λίγο που παρακολούθησα το 1ο βίντεο, δυστυχώς το επίπεδο γνώσης του καθηγητή περί ANSI/ISO C δείχνει να είναι επιεικώς μέτριο.

 

Να τον προσβαλεις. Γιατί όχι; Είναι αστεία λάθη. Γιατί να μιλήσει σε έναν αρχάριο για το ποσό χώρο πιάνουν οι οι τύποι; Μάλιστα κάνοντας και λάθος.

 

Απλά πράματα, int = ακέραιος double = πραγματικός. ,next

Διαφωνώ. Είμαι δηλαδή της άποψης πως ο sizeof αποτελεί θεμελιώδη τελεστή στη C, οπότε θεωρώ πως καλό είναι να διδάσκεται από νωρίς. Τα primitive data-types αποτελούν πολύ καλή ευκαιρία για να γίνει και εισαγωγή στον sizeof.

[imitheos]

Κανένα από τα δυο δεν είναι ακριβές. Το πρότυπο δεν επιβάλλει ο char να είναι signed ή unsigned. Είναι implementation dependent.

Έχεις δίκιο. Εκτός ότι μπορείς να επιλέξεις τι θέλεις, υπάρχουν και αρχιτεκτονικές με unsigned char από τη μάνα τους. Δεν το ανέφερα για τον ίδιο λόγο που δεν εξήγησα και το κομμάτι της undefined behavior και απλά ανέφερα μέσα στην παρένθεση.

 

Ήθελα να τονιστεί το λάθος αντί να χαθεί μέσα σε ένα κατεβατό πληροφορίας. Το σκεπτικό μου ήταν ότι ακόμη και στο πλαίσιο που κινείται ο εκφωνητής δηλαδή να παρουσιάζει συμπεριφορές του compiler του ως συμπεριφορές τις γλώσσας, ακόμη και σε αυτό το πλαίσιο έχει λάθη.

 

Γενικώς πάντως, από το (πολύ) λίγο που παρακολούθησα το 1ο βίντεο, δυστυχώς το επίπεδο γνώσης του καθηγητή περί ANSI/ISO C δείχνει να είναι επιεικώς μέτριο.

Εμένα δεν με χάλασαν τόσο οι γνώσεις του. Έχω ζήσει δύο καθηγητές c / c++ στη σχολή μου και έχω δει διαλέξεις από 2-3 ακόμη από άλλες σχολές και αυτός φαίνεται να γνωρίζει περισσότερα από όλους.

 

Στη δική μου σχολή το βιβλίο δεν ανέφερε ποτέ τι είναι το casting και δεν έγινε ποτέ συζήτηση ότι μπορεί λόγω line buffering να μην εμφανιστεί η έξοδος για αυτό υπάρχει δυνατότητα να γίνει "flush" το stream (έστω και αν το δίδαξε λάθος με το stdin. προς υπεράσπισην του θα μπορούσαμε να πούμε ότι στα windows που χρησιμοποιεί, το fflush δουλεύει σωστά με το stdin).

 

Εδώ σε ξένα βιβλία για C (αν εξαιρέσεις το βιβλίο του King και ίσως άλλα 1-2 το πολύ βιβλία) υπάρχει πολύ ελλειπές περιεχόμενο και δεν διδάσκονται έννοιες που θα έπρεπε.

 

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

[Xero1991]

 

 

Η python αντίθετα υποστηρίζει πάρα πολλά πράγματα (όπως πχ να γράψεις ένα tcp server με 3 γραμμές αντί για 150 σε C) και έτσι οι ασκήσεις είναι πιο ενδιαφέρουσες.

 

Όντως? Υπάρχουν sites/youtube videos που σε μαθαίνουν έτσι python? Αν ναι, ένα λινκ θα ήταν παραπάνω από καλοδεχούμενο

 

[imitheos]

Όντως? Υπάρχουν sites/youtube videos που σε μαθαίνουν έτσι python? Αν ναι, ένα λινκ θα ήταν παραπάνω από καλοδεχούμενο

Δεν ξέρω αν υπάρχουν tutorials που σε μαθαίνουν να γράψεις ένα tcp server αλλά σίγουρα οι ασκήσεις είναι πιο πολύπλοκες και ενδιαφέρουσες από το "δώσε ένα αριθμό -> έδωσες τον αριθμό 10" και από μετατροπές τύπου "δώσε μέτρα. τα τάδε μέτρα είναι δείνα πόδια".

[migf1]

...

 

Εμένα δεν με χάλασαν τόσο οι γνώσεις του. Έχω ζήσει δύο καθηγητές c / c++ στη σχολή μου και έχω δει διαλέξεις από 2-3 ακόμη από άλλες σχολές και αυτός φαίνεται να γνωρίζει περισσότερα από όλους.

 

Στη δική μου σχολή το βιβλίο δεν ανέφερε ποτέ τι είναι το casting και δεν έγινε ποτέ συζήτηση ότι μπορεί λόγω line buffering να μην εμφανιστεί η έξοδος για αυτό υπάρχει δυνατότητα να γίνει "flush" το stream (έστω και αν το δίδαξε λάθος με το stdin. προς υπεράσπισην του θα μπορούσαμε να πούμε ότι στα windows που χρησιμοποιεί, το fflush δουλεύει σωστά με το stdin).

 

Αν αυτά ισχύουν και σήμερα και αποτελούν και τον κανόνα στη χώρα μας, τότε είναι ολίγον... τραγικό.

 

...

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

 

Συμφωνώ για την (μη) μεταδοτικότητα του συγκεκριμένου καθηγητή, αλλά πιο σημαντική θεωρώ την έλλειψη γνώσης. Το ακροατήριο είναι σχεδόν "καταδικασμένο" να μισήσει τη C (ή όποια άλλη γλώσσα ήταν στη θέση της).

 

Πάλι από το ΤΕΙ Πειραιά έβλεπα κάτι άλλα βίντεο, με κάποιον νεότερο εκφωνητή που παρατήρησα πως ενώ ξέρει, αποφεύγει να επιμείνει. Για παράδειγμα, ενώ σε κάποια διαφάνεια τους εξηγεί πως π.χ. το μέγεθος του int μπορεί να είναι είτε 2 είτε 4 bytes, ανάλογα τo implementation (βέβαια μπορεί να είναι ακόμα μεγαλύτερο, το πρότυπο επιβάλει να είναι τουλάχιστον 2 bytes) αργότερα σε όλες του τις προφορικές αναφορές το παρουσιάζει σαν να είναι πάντα 4 bytes. Επίσης, σε άλλες διαφάνειες γράφει int main( void) σε άλλες int main() και σε άλλες main(). Σε αυτό το

, όταν τις συνδυάζει με δείκτες, σχεδόν καταφέρνει να μπερδέψει ακόμα και μένα, με κατά την άποψή μου αχρείαστη επιμονή σε ακατάλληλα παραδείγματα

 

Στο Harvard University από την άλλη μεριά, μέχρι το 2008 ο David Malan έκανε ολόκληρο show σχεδόν σε κάθε μάθημα, μπροστά  σε ασφυκτικά γεμάτο αμφιθέατρο, μιας και η εισαγωγή σε CS με C που δίδασκε ήταν από τα πλέον δημοφιλή μαθήματα του πανεπιστημίου. Όσοι έχετε όρεξη, αξίζει να παρακολουθήσετε όλο το course,

. Θα μου πεις, συγκρίνεις μήλα με πορτοκάλια (π.χ. τι μισθό έπαιρνε ο Malan τη 10ετία του 2000 στο Harvard και τι μισθό έπαιρναν οι καθηγητές στο ΤΕΙ Πειραίά πέρυσι, ή τι budget & εγκαταστάσεις έχει το Harvard και τι το TEI Πειραιά), και δεν θα έχεις καθόλου άδικο.

 

Όμως και η διαφορά στον τρόπο διδασκαλίας, είναι χαώδης. Πέρα από την παραστατικότητα και την μεταδοτικότητα, ακόμα και με χρήση εθελοντών μέσα από τους φοιτητές, αν δεις τα βίντεο, θα παρατηρήσεις και σε ποια σημεία αποφεύγει να επιμείνει και σε ποια επιμένει. Για παράδειγμα, στην αρχή δεν τους μαθαίνει καν την scanf, αλλά  χρησιμοποιεί έτοιμη μια μικρή input βιβλιοθήκη που έχει φτιάξει ειδικά για το μάθημά του (GetString, GetInt, GetFloat, κλπ). Τέσπα, ξεφύγαμε.

[migf1]

Μια μικρή διόρθωση, ο Malan διδάσκει ακόμα  στο Harvard.