Μπορείτε να προτείνετε δεύτερη γλώσσα;

[kagelos]

 

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

 

 

Όπως ακριβώς είπα, κάτι που σου είπε ένας που το διάβασε από κάποιον ...

Κανένα λειτουργικό (παραγωγής) δεν είναι γραμμένο σε C++, σχεδόν κανείς δεν γράφει drivers σε C++, ενώ ακόμα και ορισμένα embedded που υποστηρίζουν αντικειμενοστραφή παράγωγα τις C (π.χ. Arduino) σχεδόν ποτέ δεν χρησιμοποιούν τις αντικειμενοστραφής δυνατότητες.

 

Ο λόγος είναι ότι δεν υπάρχει έλεγχος στις δομές που δημιουργεί ο compiler (π.χ. vtables και άλλα πολλά).

 

Μην θίγεσαι τόσο εύκολα και μην προσβάλλεις τον άλλο. Μια χαρά γνωρίζω. Καταρχήν το είπα κατά μια έννοια χιουμοριστικά, αλλά είναι 100% αλήθεια. Ρώτα και κάποιον που κάνει system programming τι άποψη έχει για τη C++.

[DeltaLover]

Όπως ακριβώς είπα, κάτι που σου είπε ένας που το διάβασε από κάποιον ...

Κανένα λειτουργικό (παραγωγής) δεν είναι γραμμένο σε C++, σχεδόν κανείς δεν γράφει drivers σε C++, ενώ ακόμα και ορισμένα embedded που υποστηρίζουν αντικειμενοστραφή παράγωγα τις C (π.χ. Arduino) σχεδόν ποτέ δεν χρησιμοποιούν τις αντικειμενοστραφής δυνατότητες.

 

Ο λόγος είναι ότι δεν υπάρχει έλεγχος στις δομές που δημιουργεί ο compiler (π.χ. vtables και άλλα πολλά).

 

Μην θίγεσαι τόσο εύκολα και μην προσβάλλεις τον άλλο. Μια χαρά γνωρίζω. Καταρχήν το είπα κατά μια έννοια χιουμοριστικά, αλλά είναι 100% αλήθεια. Ρώτα και κάποιον που κάνει system programming τι άποψη έχει για τη C++.

 

Ειπες οτι η C++ δεν χρησιμοποιητε για systems programming κατι που νομιζω ειναι καθαρα λαθος, οπως μπορεις να καταλαβεις απο τα links που παραθεσα παραπανω απο που διαφαινεται καθαρα οτι ο ιδιος ο δημιουργος της την προμοταρει γι' αυτους ακριβως τους σκοπους...

 

Το οτι στην C εχουν γραφτει τα περισσοτερα operating systems, το TCP/IP stack, οι περισσοτεροι drivers κλπ δεν το αμφβισβητει κανεις. Αυτο δεν σημαινει ομως οτι και το C++ community δεν την προμοταρει προς αυτη την κατευθυνση (εφοσον εχασε την μαχη στο desktop και server site development απο αλλες πιο ευελικτες γλωσσες αυτος ειναι και ο μοναδικος τομεας στον οποιο μπορει να δειξει καποια χρησιμοτητα αλλωστε)...

 

Λες οτι δεν υπάρχει έλεγχος στις δομές που δημιουργεί ο compiler, που ακριβως αναφερεσαι? Το μονο που μπορω να υποθεσω ειναι οτι μιλας για το name mangling το οποιο στις περιπτωσεις που θελουμε να αποφυγουμε, αν θελουμε να γραψουμε μια library για cross platform compatibility, πρεπει απλα να το κανουμε wrap με ενα standard C interface)...

 

Η προσθεση των vtables απο τον compiler σε μια class που αναφερεις εχει να κανει με τo αν αυτη περιεχει virtual functions, το overhead ειναι mimimum (προσθετοντας ενα word στο declaration) και δεν ειναι σε καμμια περιπτωση υποχρωτικη η χρηση του (αν θελουμε να αποφυγουμε run time polymorphism)...

 

Η C++ μπορει να κανει οτι και C με την διαφορα οτι παρεχει τεχνικες (genetic programming, exceptions, RTTI κλπ) που δεν υπαρχουν στην standard C καθως επισης μεσω της STL επιτρεπει ευκολο code reuse (πχ vector, lisp, map κλπ) επιταχυνοντας και στανταροποιωντας την δουλεια του προγραμματιστη...

 

Σε πληροφορω ακομα οτι υπαρχει καποιο ποσοστο C προγραμματιστων οι οποιοι γραφουν OO κωδικα σε C! Αν σε ενδιαφερει δεν και αυτο το βιβλιο:

 

http://www.amazon.com/Interfaces-Implementations-Techniques-Creating-Reusable/dp/0201498413/ref=sr_1_1?s=books&ie=UTF8&qid=1308061457&sr=1-1

 

Οσον αφορα να 'ρωτησω καποιον' χωρις να θελω να περιαυτολογησω σε πληροφορω οτι χρησιμοποιω C++ απο τα τελη της δεκαετιας του '80, εχω γραψει εκατονταδες χιλιαδες γραμμες σε αυτην (συμπεριλαμβανομενων drivers, db frameworks, MFC, ATL, TCP και UDP servers, genetic algorithms, neuron networks, DSLs κλπ κλπ), εχω παραβρεθει επανηλειμενα στο C++ Convention στο Silicon Valley, εχω συνομιλησει αρκετες φορες με τον ιδιον τον Stroustrup, τον Andrew Koening, τον John Lakos, Jeffrey Richter, Charles Petzhold αλλα και δεκαδες αλλα λιγοτερα γνωστα μελη του C+ Committee , εχω συμμετασχει ενεργα στο κινημα των Design Patterns απο το ξεκινημα του κλπ. κλπ. κλπ. οποτε δεν νομιζω οτι χρειαζεται να ψαχτω περισσοτερο....

[παπι]

Τι το πολυπλοκο εχει το malloc ;

[kagelos]

Η χρήση κλάσεων σημαίνει αυτόματα δημιουργία virtual μεθόδων ακόμα και αν δεν τις ορίσεις (destructor), οι οποίες δημιουργούν memory και code overhead, Αυτό λόγω του VTable αλλά και του padding μνήμης για την κληρονομικότητα. Αν από την άλλη δεν έχεις αντικείμενα, δεν γράφεις C++ αλλά C. Τώρα θα ήθελα πολύ να δω κάποιο κομμάτι από λειτουργικό σύστημα ή driver που χρησιμοποιεί STL.

 

Φυσικά και με τη C για να πετύχεις τα ίδια αποτελέσματα θα έχεις παρόμοιο overhead. Όμως η C έχει το χαρακτηριστικό του ότι γράφεις βγαίνει από τον compiler και τίποτα περισσότερο. Για αυτό και χρησιμοποιείται για system programming, ενώ αντίθετα η C++ δεν χρησιμοποιείται. Ελέγχεις αυτό που θα βγει.

Δεν είπα ότι έχει πρόβλημα το OOP μοντέλο. Όπως πολύ σωστά είπες οι τεχνικές εφαρμόζονται σε C, μόνο που δεν υπάρχει η κληρονομικότητα. Άρα εφόσον και στη C (με χακιές) περιγράφονται αντικείμενα, δεν υπάρχει λόγος να χρησιμοποιηθεί η C++ για system programming.

 

Δεν θα ήθελα να χαλάσω (και άλλο) το θέμα μιας και δεν ήταν αυτό το περιεχόμενο. Ούτε λέω πως δεν είναι καλή η C++ ούτε ότι είναι καλύτερη η C. Απλά ότι για system programming (os, drivers, embedded) μια και μοναδική είναι η high level γλώσσα που χρησιμοποιείται και λέγεται C.

[Directx]

Για την ιστορία, μια πρώιμη εκδοχή της C++ (πριν ακόμα ολοκληρωθεί το standarization της) χρησιμοποιήθηκε για την κατασκευή του Λ.Σ. PSION EPOC32 το οποίο αργότερα μετεξελίχθηκε στο γνωστό SYMBIAN OS το οποίο από την αρχή ως το τέλος του είναι γραμμένο (bottom to top) σε υπέρ (OOP) non-standard C++ μορφή με ελάχιστα τμήματα του γραμμένα σε κώδικα μηχανής.

 

Το EPOC32 προέκυψε ως φυσική εξέλιξη του προγενέστερου 16bitου PSION OS το οποίο ήδη εφάρμοζε αντικειμενοστραφή λογική (με την βοήθεια custom-made preprocessor της PSION) αν και γραμμένο σε C.

 

Όσον αφορά το overhead της STL, πράγματι ήταν μια από τις βασικές αιτίες που δεν χρησιμοποιήθηκε από το νεότευκτο τότε EPOC32 (μαζί επίσης με την μη υποστήριξη των standard C++ exceptions κτλ) αλλά ούτε (από όσο γνωρίζω) από την πρώτη έκδοση του μοντέρνου BADA OS της SAMSUNG. Πολύ αργότερα όμως καθώς η διαθέσιμη επεξεργαστική ισχύ αυξήθηκε τελικά δόθηκε η πολυπόθητη υποστήριξη STL τουλάχιστον στο SYMBIAN OS μέσο (αν θυμάμαι καλά) πειραματικού port.

[DeltaLover]

Η χρήση κλάσεων σημαίνει αυτόματα δημιουργία virtual μεθόδων ακόμα και αν δεν τις ορίσεις (destructor), οι οποίες δημιουργούν memory και code overhead, Αυτό λόγω του VTable αλλά και του padding μνήμης για την κληρονομικότητα. Αν από την άλλη δεν έχεις αντικείμενα, δεν γράφεις C++ αλλά C. Τώρα θα ήθελα πολύ να δω κάποιο κομμάτι από λειτουργικό σύστημα ή driver που χρησιμοποιεί STL.

 

Δεν ειναι ακριβες το οτι η χρήση κλάσεων σημαίνει αυτόματα δημιουργία virtual μεθόδων... Ειναι τελειως λαθος αυτη η αποψη...

 

Αντιθετα η χρηση virtual methods ειναι optional.... Αυτος ακριβως ειναι ο λογος που δεν συνιστατε να επεκτεινουμε τις classes απο το STL:

 

Αν δεις το implementation οποιασδηποτε κλασης απο το STL, ανοιξε για παραδειγμα τον κωδικα για το vector.. Θα παρατηρησεις οτι δεν υπαρχει καμμια virtual method ουτε καν ο destructor.

 

Αυτο συμβαινει ακριβως για να αποφυγουμε την δημιουργια vtable κατι που ενδεχομενα να εχει καποιο (μικρο) κοστος στο performance.

 

Αμεση συνεπεια αυτου ειναι το οτι αν κανουμε derive απο το vector υπαρχει η πιθανοτητα για memory leak αν κανουμε delete σε pointer της derived class.

 

Βεβαιως αυτο το style με το οποιο γινεται το declaration του vector πχ, αντικειται στο Object Orient ascpet του inheritance... Εδω ομως πρεπει να διαχωρισεις τα δυο ειδη polymorphism που εισηγειται η C++:

 

- Vertical polymorphism : Με κλασσικο extending της class χρησιμοποιωντας deriviation

 

- Horizontal polymorphism : Επιτυγχανει πολυμορφισμο χρησιμοποιωντας templates η αλλιως generic programming.

 

Πανω στο θεμα αυτο εχω συζητησει με μελη του committee υποδεικνυωντας οτι η C++ θα πρεπει να προσθεσει ενα keyword παρομοιο με το sealed της C# η το final της Java το οποιο θα 'κλειδωνει' την κλαση, μη επιτρεπωντας το extention της σε χαμηλωτερα επιπεδα ιεραρχιας αφου ακριβως δεν ειναι σχεδιασμενη για τετοιο σκοπο... Αυτη η επεκταση μεχρι στιγμης δεν εχει γινει αποδεκτη κυριως γιατι υπαρχει οντως ενα trick που μπορουμε να κανουμε χρησιμοποιωντας virtual base inheritance το οποιο να εχει ακριβως το ιδιο αποτελεσμα με το sealed η final...

 

Η αντιθεση μου πανω στο θεμα εγκειται στο οτι παροτι η τεχνικη αυτη υπαρχει, αυτη ερχεται στο κοστος του polluting the namespace με μια επιπλεον ψευδοβαση η οποια επιπελον κανει τον κωδικα ιδιατερα verborse σε σημειο να μην χρησιμοποιειται σχεδον ποτε στην πραξη

 

Τι το πολυπλοκο εχει το malloc ;

Αφενως το malloc ειναι πολυ expensive και τεινει να δημιουργησει performance bottlenecks ειδικα σε περιπτωσεις που κανουμε allocations για πολλα μικρα structs. Η κλασικη λυση απο πλευρας C ειναι να δημιουργουμε ενα pool απο preallocated memory το οποιο να μας δινει την απαιτουμενη μνημη χωρις να χρειαζομαστε να κανουμε malloc καθε φορα χρειαζομαστε ενα καινουργιο structure. Η C++ μας δινει καλυτερους μηχανισμους για το προβλημα αυτο εισαγωντας τον new operator τον οποιο μπορουμε να κανουμε overload για να κανει το allocation σε μεγαλα chunks μνημης, ακομα η C++ εχει τον μηχανισμο του placement new ο οποιος μπορει να κανει construct ενα object σε καποια αυθερετη μνημη χωρις να χρειαζεται να την κανει allocate.

 

Αφετερου το malloc οπως και το new της C++ κανει τον προγραμματισμο δυσκολο, καθως ειναι υπευθυνο για πολλα memory leaks. Αυτο συμβαινει γιατι πολλες φορες καποιο pointer σε ενα structure παει out of scope χωρις να εχει προηγουμενα γινει dealloc η delete... Δες για παραδειγμα αυτο το spinet:

 

 

>void foo()
{
       SomeStructure* ss = new SomeStructure();

       ss->DoSomething();

       delete ss;
       
}

 

Αν υποτεθει οτι η ss->DoSomething(); πεταει ενα exception τοτε ο ss παει out of scope χωρις ποτε η μνημη στην οποια κανει point να γινει deallocated.

 

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

[migf1]

Βασικά ο παπι ρώτησε τι το πολύπλοκο έχει η malloc() και όχι πόσο efficiently υλοποιείται under the hood (αν και θεωρώ πως είναι κοινός τόπος ότι η C++ έχει overall περισσότερο overhead από τη C σαν γλώσσα, εξ' ορισμού).

 

Έχει γίνει... λάστιχο το τόπικ! Ο άνθρωπος ρώτησε ποια γλώσσα του προτείνουμε και αντί αυτού έχει "γυρίσει" για άλλη μια φορά σε C vs C++

 

Btw, στο system programming συνήθως χρησιμοποιείται η C για τον πυρήνα και μετά bindings με άλλες γλώσσες για πιο high level πράγματα, από C++ μέχρι scripting languages στα πολύ έξω layers (π.χ. Windows).

 

Τέσπα, η ουσία είναι πόσο σοβαρά και σε τι επίπεδο θέλει να ασχοληθεί ο topic starter. Το καλύτερο από όλα για μένα είναι να τις μάθει και τις 2, ξεκινώντας από C για να πάρει γερές βάσεις και να μάθει να στηρίζεται στις δικές του δυνάμεις για την διαχείριση των πόρων!

 

...

[backy1993]

οχι οτι τα παιδια δε βοηθησαν αλλα εσυ φιλε μιλησες πιο ξεκαθαρα απο ολους +1 απο μενα!

[twiner]

εγώ παιδιά το βλέπω έτσι:

 

αν ο op θέλει να γίνει επιστήμονας προγραμματιστής καλύτερα να πάει σε μια σχετική σχολή όπου θα αναγκαστεί να ψηθεί στη C και να μάθει και τη θεωρία.

 

αν θέλει κάτι για το χόμπι του ή έστω το καλοκαίρι πριν τη σχολή, θεωρώ ότι είναι overkill να κάθεται

να μαθαίνει low level πράγματα όταν με την Python μέσα σε 2 βδομάδες, που λέει ο λόγος, θα χακεύει.

 

[backy1993]

Υπαρχει python και με γραφικο περιβαλλον και χωρις η μονο ενα απο τα δυο (γραφικο περιβαλλον εννοω αντικειμενο στραφεισ)

αν ναι πιο απο τα δυο?

[Lomar]

το γραφικό περιβάλλον δεν έχει καμία σχέση με την αντικειμενοστράφεια.

 

πχ αντικειμενοστραφούς κλάσης με κληρονομικότητα σε ψευδογλώσσα:

 

 

EDITED 2 ΦΟΡΕΣ ΓΙΑ ΠΙΟ ΠΙΣΤΗ ΑΠΟΔΟΣΗ ΤΟΥ ΠΑΡΑΔΕΙΓΜΑΤΟΣ:

 

>

class animal{
   int age;
   string name;
   float weight;
   boolean carnivorous;
  int sound_of_the_animal[ ]; //gemizeis ton pinaka me akeraious i pragmatikous to sunolo twn opoiown an anaparaxthei einai ena niaourisma - vlepe mp3 px
}

class cat extends animal{
  string color;
  string specimen;
  int voice_wavelengths[2];

  function miaou(self){
  	for (i=voice_wavelengths[0];i<voice_wavelengths[1];i++){
			system.audio.out(super.sound_of_the_animal[voice_wavelengths]);
  	}
  }
}

a_cat = new cat(super.age=10, super.name="maria", super.weight="3000", super.carnivorous=True, voice_wavelengths=[450, 780], color="grey-yellow", speciment="alaniara");

 

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

 

 

ps: python δαγκωτό και απο εμένα, έχει και bindings για C++, C, νομίζω και Assembly για να βελτιστοποιήσεις τη ταχύτητα σε συγκεκριμένα σημεία του project σου, αλλά είναι νωρίς ακόμα για αυτά. επίσης έχει βιβλιοθήκες σχεδόν για τα πάντα όλα, αμφιβάλλω αν υπάρχει άλλη γλώσσα με τέτοιο πλήθος.

 

ps2: @DeltaLover φίλε μου τώρα είδα τα ποστ σου, απλά respect. παράγγειλα και το βιβλίο που πρότεινες, είχε γαμάτο εξώφυλλο με τα ψάρια σε προστατευτική διάταξη, να θυμίζουν blocks μνήμης που ένα αόρατο χέρι (βλέπε προγραμματιστής) τα βάζει σε διάταξη. άντε να δούμε αν θα καταφέρω αυτή τη φορά να χωθώ καλά στη c++. Η C με αρρώστησε με τα malloc, realloc, παρόλο που εκτίμησα τη λογική και την αναγκαιότητά τους (αν γνωρίζει κανείς βασικά πράγματα για την αρχιτεκτονική υπολ. συστ. η πιο άμεση και μίνιμαλ προσέγγιση είναι η c γμτ) στράφηκα στη python γιατί επιτέλους, όπως πολύ σωστά παρέθεσε απο xfcd ο twiner πιο πάνω, "programming is fun again"

[DeltaLover]

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

Σε ποιο ακριβως βιβλιο αναφερεσε?

[Lomar]

αυτό:

http://www.amazon.co...08061457&sr=1-1

 

[DeltaLover]

Χμ, Lomar, δεν ξερω αν εκανες καλη επιλογη.... Ισως δεν εκανα κατι κατανοητο για το βιβλιο αυτο....

Εξεδοθη εδω και αρκετα χρονια και πραγματευεται μια σπανιως απαντομενη τεχνικη προγραμματισμου σε standard C, μεσω της οποιας αποδιδει ιδιοτητες του OOP στην C...

 

Αν και ενδιαφερον απο ακαδημαικη αποψη δεν νομιζω οτι αυτα που αναφερονται στο κειμενο αυτο θα σε βοηθησουν να βελτιωθεις γρηγορα σαν προγραμματιστης καθως υποθετει μια αρκετα προχωρημενη αντιληψη της C ειδικα και του OO γενικοτερα και εξειδικευει την θεμα του σε ενα σχετικα προχωρημενο αντικειμενο.

 

Νομιζω οτι εφοσον εχεις επιλεξει PYTHON σαν το core technology σου γι αυτη την περιοδο τουλαχιστον θα πρεπει να επικεντρωθεις σε αυτην ξεκινωντας απο τα βασικα texts οπως πχ Programming Python (http://www.amazon.com/Programming-Python-Mark-Lutz/dp/0596158106/ref=sr_1_1?s=books&ie=UTF8&qid=1308143317&sr=1-1) η κατι αναλογο...

 

Βεβαια καλο ειναι να βελτιωνεις παραλληλα και τις δευτερες γλωσσες σου (απο οτι φαινεται την C) οχι ομως με τοσο εξειδιευμενα texts οσο το C Interfaces and Implementations.

 

Αν θελεις ενα πιο γενικο (πολυ καλο) βιβλιο για προγραμματισμο με εμφαση στους αλγοριθμους και σχετικα ευκολοδιαβαστο προτεινω αυτο:

 

http://www.amazon.com/Programming-Pearls-2nd-Jon-Bentley/dp/0201657880/ref=sr_1_1?s=books&ie=UTF8&qid=1308143562&sr=1-1

 

 

Ενα ακομα πολυ καλο βιβλιο γενικα για προγραμματισμο:

 

http://www.amazon.com/Practice-Programming-Brian-W-Kernighan/dp/020161586X/ref=sr_1_1?s=books&ie=UTF8&qid=1308143643&sr=1-1

 

(Τα περισσοτερα απο αυτα τα βιβλια μπορεις να τα βρεις σε pf free απο καποιο download site)

[warchief]

Και το δικό μου λιθαράκι πάει στην Python. Για αρκετούς λόγους:

 

-Μπορείς να ξεκινήσεις γράφοντας procedural και να επεκταθείς σε OO χωρίς να χρειαστείς να αλλάξεις γλώσσα (πχ απο C σε C++)

 

-Πληθώρα βιβλιοθηκών

 

-Αρκετά καλό online documentation απο python.org (σε C++ και C ειναι δράμα η κατάσταση)

 

-Μπορεί να εστιάσει στον αλγόριθμο που θέλει να αναπτύξει για εκμάθηση χωρίς να πρέπει να ασχοληθεί με άλλα πράγματα πρώτα (πχ memory allocation, iterator traversal κτλπ)

 

-Interactive shell (και με iPython interactive documentation)

 

-Οι βασικοί τύποι δεδομένων ειναι ευπαρουσιάστοι και εύπεπτοι (πχ dict, list, tuple)

 

-Υπαρξη καλού και ευπαρουσίαστου debugger (πχ απο eclipse με pydb)

 

-Dynamic typed

 

Προσωπικά θεωρώ την Python (αρκετά) κοντά σε νοοτροπία της ψευδογλώσσας που μαθαίνουν τα παιδιά στο Λύκειο, και άρα μια οσο το δυνατόν πιο ομαλη μετάβαση