αποδεκτός ο παρακάτω κώδικας ( C++ );

[migf1]

Είναι τα υπέρ και τα κατά του εκάστοτε programming paradigm. Το παράδειγμά σου αναφέρεται σε very-high-level programming, όπου η ΜΗ ευελιξία είναι όντως προτέρημα. Σε πιο low levels όμως προκαλεί προβλήματα, καθυστερήσεις, overhead κι ενίοτε αδυνατεί καν να εφαρμοστεί μιας και αυτό που θες να κάνεις δεν υποστηρίζεται από τη γλώσσα.

[m1cRo]

Είναι τα υπέρ και τα κατά του εκάστοτε programming paradigm. Το παράδειγμά σου αναφέρεται σε very-high-level programming, όπου η ΜΗ ευελιξία είναι όντως προτέρημα. Σε πιο low levels όμως προκαλεί προβλήματα, καθυστερήσεις, overhead κι ενίοτε αδυνατεί καν να εφαρμοστεί μιας και αυτό που θες να κάνεις δεν υποστηρίζεται από τη γλώσσα.

Το παράδειγμα μου αναφέρεται σε μεγάλα έργα λογισμικού όπου ο κώδικας πρέπει να είναι κατανοητός, και όχι σε ένα μικρό project που αναλύουμε στο πανεπιστήμιο η σε κάποιο μάθημα. Και επίσης αυτό που αναφέρω δεν είναι η μη ευελιξία της γλώσσας γιατί με c++ πάλι στήνεις αυτά τα συστήματα με αυτόν τον τρόπο. Αυτό που αναφέρω είναι όλη η ιδέα του object oriented analysis και design μαζί με το encapsulation στο οποιο βασίζεται. Εξάλλου δεν γνωρίζω κάτι που να μην μπορεί να γίνει με οποιαδήποτε γλώσσα αρκεί να έχει γνώση αυτός που το φτιάχνει.

[migf1]

Το παράδειγμα μου αναφέρεται σε μεγάλα έργα λογισμικού όπου ο κώδικας πρέπει να είναι κατανοητός, και όχι σε ένα μικρό project που αναλύουμε στο πανεπιστήμιο η σε κάποιο μάθημα. Και επίσης αυτό που αναφέρω δεν είναι η μη ευελιξία ths γλώσσας γιατί με c++ πάλι στήνεις αυτά τα συστήματα με αυτόν τον τρόπο. Αυτό που αναφέρω είναι όλη η ιδέα του object oriented analysis και design μαζί με το encapsulation στο οποιο βασίζεται. Εξάλλου δεν γνωρίζω κάτι που να μην μπορεί να γίνει με οποιαδήποτε γλώσσα αρκεί να έχει γνώση αυτός που το φτιάχνει.

 

Μεγάλο έργα λογισμικού συναντάμε και στο Open Source community, καθώς και σε ολόκληρη τη βιομηχανία ενσωματωμένων συστημάτων που περιλαμβάνει τεράστια γκάμα λογισμικού και μόνο μικρά πρότζεκτς που αναλύονται σε κάποιο πανεπιστήμιο ή σε κάποιο μάθημα δεν είναι.

 

Το object oriented analysis και design μαζί με το encapsulation στο οποιο βασίζεται που αναφέρεις είναι ένα programming paradigm, εδραιωμένο εδώ και πάρα πολλά χρόνια (τα άλλα 2 διαδεδομένα & εδραιωμένα programming paradigms είναι το procedural programming και το functional programming).

 

Αυτό που υποστήριξα λοιπόν είναι πως κανένα από αυτά δεν αποτελεί πανάκεια για κάθε είδους project, γιατί το καθένα έχει τα υπέρ και τα κατά του. Για αυτό και συνήθως τα πολύ μεγάλα έργα λογισμικού συνδυάζουν κώδικα κι από τα 3 paradigms, ανάλογα το level of abstraction του εκάστοτε project layer .

 

Γλώσσες όπως η C++ που δεν ακολουθούν στανταρισμένο programming paradigm, αλλά τα "μπερδεύουν" όλα μαζί, συχνά άναρχα, αποτελούν όντως πρόβλημα στην εκμάθηση, από την άλλη όμως μεριά σου παρέχουν τη δυνατότητα να μην αλλάξεις γλώσσα όταν αλλάζεις level of abstraction.

 

Υπέρ και κατά, δηλαδή.

[Directx]

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

 

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

 

(Βέβαια υπάρχει και η περίπτωση οι νεότεροι προγραμματιστές να μάθουν από τους εμπειρότερους - αλλά ok σε ένα μεγάλο project πας χαλαρά).

[migf1]

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

 

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

 

(Βέβαια υπάρχει και η περίπτωση οι νεότεροι προγραμματιστές να μάθουν από τους εμπειρότερους - αλλά ok σε ένα μεγάλο project πας χαλαρά).

 

+1

 

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

 

Όπως πολύ σωστά επεσήμανε κι ο m1cRro, όλες οι γλώσσες, τουλάχιστον οι δημοφιλείς, μπορούν να κάνουν σχεδόν τα πάντα... αλλά σε βοηθάνε πραγματικά σε διαφορετικούς τομείς η κάθεμιά τους.

 

Για παράδειγμα, δεν θα γράψεις πυρήνα λειτουργικού συστήματος σε Java, όχι γιατί δεν γίνεται, αλλά γιατί δεν σε συμφέρει. Ομοίως, δεν θα γράψεις (πλέον) windowing API σε C, όχι γιατί δεν μπορεί αλλά γιατί δεν σε συμφέρει.

 

Όλα τα παραπάνω, με την προϋπόθεση πως έχεις την ευχέρεια να χρησιμοποιήσεις εξίσου καλά 2-3 γλώσσες και επίσης πως έχεις την ευχέρεια να εντοπίσεις την πιο κατάλληλη για κάθε project. Αυτή τη δουλειά στα πολύ μεγάλα έργα την κάνουν κυρίως οι software-engineers, και κατόπιν αν π.χ. αποφασιστεί πως ο πυρήνας θα γραφτεί σε C/C++ και το GUI σε Java, η εταιρία θα προσλάβει 2 διαφορετικές ομάδες ομάδες για την κάθε δουλειά... μιας και μιλάμε για large-scale projects, άρα "λεφτά υπάρχουν"

[Directx]

[..]μιας και μιλάμε για large-scale projects, άρα "λεφτά υπάρχουν"

Yeap!!

[Re4cTiV3]

Ευχαριστώ παιδιά και για την περαιτέρω συζήτηση!

 

Δηλαδή ένα string ουσιαστικά είναι κάπως έτσι;

 

π.χ. "insomnia" --> i,n,s,o,m,n,i,a,\0,0

Επεξ/σία 27 Μαΐου 2012 από Re4cTiV3

[migf1]

Ευχαριστώ παιδιά και για την περαιτέρω συζήτηση!

 

Δηλαδή ένα string ουσιαστικά είναι κάπως έτσι;

 

π.χ. "insomnia" --> i,n,s,o,m,n,i,a,\0,0

Το πως ακριβώς αναπαριστάνεται εσωτερικά εξαρτάται από τον τρόπο με τον οποίο το έχεις ορίσει αρχικά.

 

Μερικά παραδείγματα:

 

>
char s[ ] = "insomnia";	// { 'i', 'n', 's', 'o', 'm', 'n', 'i', 'a', '\0' }
char s[9] = "insomnia";	// { 'i', 'n', 's', 'o', 'm', 'n', 'i', 'a', '\0' }
char s[10] = "insomnia"; // { 'i', 'n', 's,. 'o', 'm', 'n', 'i', 'a', '\0', '\0' }
char s[10];		// { undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined }
char s[10] = {'\0'};	// { '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0' }

Οι περισσότερες από τις strXXX() συναρτήσεις βασίζονται στην υπόθεση πως τα strings των ορισμάτων τους τελειώνουν σε '\0' (πριν ή ακριβώς στο τέρμα της μνήμης που έχει δεσμευτεί για το καθένα τους).

 

Για παράδειγμα, αν περάσεις στην strlen() ένα string που δεν περιέχει πουθενά τον χαρακτήρα '\0' θα συνεχίσει να μετράει bytes και πέρα από το τέλος της μνήμης του string (κάποια στιγμή θα βρει ένα byte ίσο με '\0' με 0 δλδ σε κάποιο άσχετο σημείο της μνήμης και θα σταματήσει, αλλά προφανώς το αποτέλεσμά της θα είναι αναξιόπιστο).

[Re4cTiV3]

>
surname = new char[ 21 ];
memset(surname,0,21);
strncpy( surname, eponimo, 20 );

 

Εδώ μπορούσαμε στην memset μπορούσαμε να βάλουμε "\0" αντί για 0;

[migf1]

>
surname = new char[ 21 ];
memset(surname,0,21);
strncpy( surname, eponimo, 20 );

 

Εδώ μπορούσαμε στην memset μπορούσαμε να βάλουμε "\0" αντί για 0;

'\0' μπορούσαμε, που είναι ο συμβολισμός της C/C++ για τον χαρακτήρα του οποίου το ASCII code είναι ίσο με 0 (το "\0" είναι string, άρα δεν έχει ASCII code).

[Re4cTiV3]

κατάλαβα

[Haldol]

Το πως ακριβώς αναπαριστάνεται εσωτερικά εξαρτάται από τον τρόπο με τον οποίο το έχεις ορίσει αρχικά.

 

Μερικά παραδείγματα:

 

>
char s[10]; // { undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined }

 

Το έχεις δοκιμάσει αυτό; Διότι το να μη δώσεις τιμή σε μια μεταβλητή που δηλώνεις δε σημαίνει ότι "αδειάζεις" αυτόματα τις θέσεις μνήμης που πιάνει από ότι υπήρχε προηγουμένως σ' αυτές. Το πιο πιθανό είναι να έχει τιμές, απλά να είναι garbage.

[migf1]

Το έχεις δοκιμάσει αυτό; Διότι το να μη δώσεις τιμή σε μια μεταβλητή που δηλώνεις δε σημαίνει ότι "αδειάζεις" αυτόματα τις θέσεις μνήμης που πιάνει από ότι υπήρχε προηγουμένως σ' αυτές. Το πιο πιθανό είναι να έχει τιμές, απλά να είναι garbage.

Δεν καταλαβαίνω τι εννοείς. Τα παραδείγματα που έχω δώσει είναι ακριβή. Ποιο θεωρείς ότι είναι λάθος; Αυτό που έχεις quoted είναι επίσης ακριβές, σύμφωνα πάντα με το standard της γλώσσας (το διευκρινίζω γιατί κάποιοι compilers μηδενίζουν αυτόματα και τις τοπικές μεταβλητές). Αυτό που ονομάζεις "garbage" επίσημα ονομάζεται "undefined".

[Haldol]

Εννοώ ότι αν τρέξεις το παρακάτω το array θα έχει κανονικότατα τιμές, απλά θα είναι ό,τι σκουπίδι έχει μέσα η μνήμη σ' εκείνο το σημείο. Και ο compiler δε πρόκειται να διαμαρτυρηθεί (well, αυτός του VS νομίζω σε ενημερώσει, αλλά ο gcc σίγουρα όχι).

 

>char s[10];
for (i=0; i<10; i++)
{
putchar(s[i]);
}

[migf1]

Εννοώ ότι αν τρέξεις το παρακάτω το array θα έχει κανονικότατα τιμές, απλά θα είναι ό,τι σκουπίδι έχει μέσα η μνήμη σ' εκείνο το σημείο. Και ο compiler δε πρόκειται να διαμαρτυρηθεί (well, αυτός του VS νομίζω σε ενημερώσει, αλλά ο gcc σίγουρα όχι).

 

>char s[10];
for (i=0; i<10; i++)
{
putchar(s[i]);
}

Τι το διαφορετικό έχω γράψει εγώ;