tonybest Δημοσ. 26 Νοεμβρίου 2011 Δημοσ. 26 Νοεμβρίου 2011 Είναι σωστό αυτό; >#include int main() { int n,m; scanf("%d", &n); scanf("%d", &m); int a[n][m]; } Δηλαδή όπως στη 3η Λυκείου ή χρειάζεται αναγκαστικά malloc; Γιατί μου είπε ο καθηγητής μου πως ο compiler δεν μου εγγυάται ότι διαβάζει τις εντολές από πάνω προς τα κάτω πάντα με τη σειρά και έτσι μπορεί να μη ξέρει το n και το m χρησιμοποιώντας scanf. Όμως όταν το γράφω στα Linux δε μου βρίσκει λάθος, ενώ στα Windows το βρίσκει λάθος!
migf1 Δημοσ. 26 Νοεμβρίου 2011 Δημοσ. 26 Νοεμβρίου 2011 Μια χαρά σωστό μου φαίνεται εμένα (αν προσθέσεις ένα <stdio.h> δίπλα στο #include). Απλά στα Windows ο compiler που χρησιμοποιείς είτε δεν υποστηρίζει την αναθεώρηση C99 της γλώσσας, είτε πρέπει να την ενεργοποιήσεις.
jstark Δημοσ. 26 Νοεμβρίου 2011 Δημοσ. 26 Νοεμβρίου 2011 Σε windows μαλλον θες malloc . Νομίζω η M$ τη C99 την εχει γραμμένη στο γνωστο σημειο...
gallaki Δημοσ. 26 Νοεμβρίου 2011 Δημοσ. 26 Νοεμβρίου 2011 Σε windows είναι ανάλογα με τον compiler στην dev c++ το δέχεται σε άλλους βγάζει λάθος. Αλλά νομίζω για να το κάνεις αυτό και να είσαι και απόλυτα σωστός θα χρειαστείς malloc.
migf1 Δημοσ. 26 Νοεμβρίου 2011 Δημοσ. 26 Νοεμβρίου 2011 Σε windows μαλλον θες malloc . Νομίζω η M$ τη C99 την εχει γραμμένη στο γνωστο σημειο... Ευτυχώς υπάρχουν κι ενημερωμένοι C compilers... με τους Pelles C και mingw τους δημοφιλέστερους ανάμεσά τους. ΥΓ.Btw, χρειάζεται κι ένα <stdio.h> δίπλα στο #include
παπι Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 Μια χαρά σωστό μου φαίνεται εμένα Να φορτωνεις τη stack με πινακες;
tonybest Δημοσ. 27 Νοεμβρίου 2011 Μέλος Δημοσ. 27 Νοεμβρίου 2011 Sorry ξέχασα το stdio.h αλλά δεν είναι εκεί το θέμα. Απλώς ο καθηγητής μου, μου είπε ότι γίνεται αποκλειστικά με malloc.
migf1 Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 Sorry ξέχασα το stdio.h αλλά δεν είναι εκεί το θέμα. Απλώς ο καθηγητής μου, μου είπε ότι γίνεται αποκλειστικά με malloc. Αποκλειστικά με malloc() γινόταν πριν από την αναθεώρηση C99 της γλώσσας. Αυτό με τη σειρά που λες πως σας είπε ο καθηγητής σας εγώ το ακούω για 1η φορά! Μούφα μυρίζομαι για να σε... ξεφορτωθεί Να φορτωνεις τη stack με πινακες; Ναι αμέ, γιατί όχι; Για γενικό προγραμματισμό δεν μιλάμε; (χώρια ότι δεν ήταν αυτή η ουσία της ερώτησης του ts).
kagelos Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 Δεν έχω και πολύ ιδέα από C, αλλά μου έκανε πολύ εντύπωση αυτό που λέτε. Δηλαδή μπορείς να δηλώνεις στην στοίβα πίνακες των οποίων το μέγεθος δεν είναι προκαθορισμένο σε compile time; Και πως ξέρει πόση στοίβα χρειάζεται; Πόσο είναι το Χ στο "sub esp, X" του stack frame;
migf1 Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 Το stack-space είναι platform, implementation και thread dependent. Συνήθως για single-threaded προγράμματα περιορίζεται από το εύρος της virtual memory, ενώ για multi-threaded συνήθως δίνεται από μισό έως 2 Mb per thread. Δεν υπάρχει portable τρόπος να ελέγξεις πόση stack έχεις ελεύθερη, αν και μερικοί compilers έχουν ως extension τη συνάρτηση stackavail() ... όπως π.χ. ο DJGPP (gcc κλώνος για DOS). Αλλιώς μπορείς να δοκιμάσεις με διάφορες πατέντες, όπως π.χ. μετά από heavy recursion να αφαιρέσεις τη διεύθυνση μιας τοπικής μεταβλητής μια συνάρτησης από τη διεύθυνση μιας τοπικής της main(). Σε γενικές γραμμές, δεν χρειάζεται να ασχολείσαι με το stack-size, αν φροντίζεις οτιδήποτε μεγαλύτερο από μερικά kilobytes να το παίρνεις από την heap. Δηλαδή μπορείς να δηλώνεις στην στοίβα πίνακες των οποίων το μέγεθος δεν είναι προκαθορισμένο σε compile time; Σχετικά με αυτό που ξέχασα να σου απαντήσω πριν, ναι .. προστέθηκε (μεταξύ πολλών άλλων) στην αναθεώρηση C99.
παπι Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 Ναι αμέ, γιατί όχι; Για γενικό προγραμματισμό δεν μιλάμε; (χώρια ότι δεν ήταν αυτή η ουσία της ερώτησης του ts). 1 Γιατι υπαρχει process που ειναι χωρισμενο σε καποια καλουλια που ειναι για καποιο λογο. Τι να κανουμε; να βαλουμε και το executing statement στη heap; 2 Γιατι ειναι επικινδυνο. Γλυτωνεις ενα deallocation, κερδιζεις αρκετα stack excepotions. ( κανε ενα stackalloc μεσα σε ενα loop και μπουμ!)
migf1 Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 1 Γιατι υπαρχει process που ειναι χωρισμενο σε καποια καλουλια που ειναι για καποιο λογο. Τι να κανουμε; να βαλουμε και το executing statement στη heap; 2 Γιατι ειναι επικινδυνο. Γλυτωνεις ενα deallocation, κερδιζεις αρκετα stack excepotions. ( κανε ενα stackalloc μεσα σε ενα loop και μπουμ!) Έχεις την τάση να αναγάγεις τα πάντα σε implementation dependent προσεγγίσεις (συνήθως σε Windows dependent προσεγγίσεις). Με αυτή τη λογική να μην κάνει κανείς recursion ποτέ, γιατί ρισκάρει stack overflow (ακόμα κι αν ξέρει εκ των προτέρων για τον Α ή Β λόγο ότι δεν υπάρχει περίπτωση να φάει πάνω μερικά kilobytes) ! Και γιατί δηλαδή είναι επικίνδυνο και πρέπει π.χ. να κάνω υποχρεωτικά malloc() στην heap ένα array από 10 ints; > int n=0; do scanf("%d", &n); while ( n > 10 || n < 1); int arr[n];
kagelos Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 Εγώ πάλι ρωτώ γιατί δεν καταλαβαίνω : Εφόσον το stack frame (το οποίο περιέχει τις τοπικές μεταβλητές) ορίζεται στην είσοδο της συνάρτησης με sub esp, X <- σύνολο μεγέθους τοπικών μεταβλητών πως γίνεται εκ των υστέρων και ενώ έχει ξεκινήσει η εκτέλεση να ορίζεται δυναμικά; Γνωρίζει κανείς;
migf1 Δημοσ. 27 Νοεμβρίου 2011 Δημοσ. 27 Νοεμβρίου 2011 Εγώ πάλι ρωτώ γιατί δεν καταλαβαίνω : Εφόσον το stack frame (το οποίο περιέχει τις τοπικές μεταβλητές) ορίζεται στην είσοδο της συνάρτησης με sub esp, X <- σύνολο μεγέθους τοπικών μεταβλητών πως γίνεται εκ των υστέρων και ενώ έχει ξεκινήσει η εκτέλεση να ορίζεται δυναμικά; Γνωρίζει κανείς; Απλώς γίνονται allocate μέσα στην stack στο σημείο που ορίζεται το μήκος τους. Δεν υπάρχει όμως στάνταρ τρόπος υλοποίησης, ούτε καθορίζεται από το πρότυπο της γλώσσας (νομίζω). Αρκεί λειτουργικά να έχεις το αποτέλεσμα που περιγράφει το πρότυπο (π.χ. θα μπορούσε ένας compiler σε κάποια πλατφόρμα να κάνει allocate το χώρο στη heap και με χρήση εσωτερικών βοηθητικών μεταβλητών να τον κάνει deallocate όταν η μεταβλητή του πίνακα βγει out of scope. O GCC από πολύ παλιά, από τη C89 παρείχε ως extension παρόμοια λειτουργικότητα, με χρήση της συνάρτησης: alloca (μόνο που το scope της είναι function-wise, ενώ για τους πίνακες μεταβλητού μεγέθους είναι scoped όπως οποιαδήποτε άλλη μεταβλητή... π.χ. μέσα σε ένα if statement). Για παράδειγμα, εδώ μπορείς να διαβάσεις τη γενική περιγραφή υλοποίησης των πινάκων μεταβλητού μεγέθους για τον GCC (άλλοι compilers μπορεί να το υλοποιούν διαφορετικά).
παπι Δημοσ. 28 Νοεμβρίου 2011 Δημοσ. 28 Νοεμβρίου 2011 Έχεις την τάση να αναγάγεις τα πάντα σε implementation dependent προσεγγίσεις (συνήθως σε Windows dependent προσεγγίσεις). Με αυτή τη λογική να μην κάνει κανείς recursion ποτέ, γιατί ρισκάρει stack overflow (ακόμα κι αν ξέρει εκ των προτέρων για τον Α ή Β λόγο ότι δεν υπάρχει περίπτωση να φάει πάνω μερικά kilobytes) ! Και γιατί δηλαδή είναι επικίνδυνο και πρέπει π.χ. να κάνω υποχρεωτικά malloc() στην heap ένα array από 10 ints; > int n=0; do scanf("%d", &n); while ( n > 10 || n < 1); int arr[n]; 1) Εχεις heap. 2) Επειδη η c99 εκανε ενα overload operator δεν σημαινει οτι η alloca ειναι safe 3) Και φυσικα δεν κερδιζεις τιποτα. Τιπορα λεμε. Ειτε εχεις ενα alloca ειτε εχεις εναν stack buffer δεν θα δεις καμια διαφορα.
Προτεινόμενες αναρτήσεις
Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε
Πρέπει να είστε μέλος για να αφήσετε σχόλιο
Δημιουργία λογαριασμού
Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!
Δημιουργία νέου λογαριασμούΣύνδεση
Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.
Συνδεθείτε τώρα