Ιδιο προγραμμα-compiler-error c++ σε διαφορετικό linux συστημα

[Razor911]

Καλημέρα και χρόνια πολλά ! Έχω μια απορία γενικής φύσεως .. Πως γίνεται το ίδιο ακριβώς πρόγραμμα να τρέχει-κάνει compile σε ubuntu 12.04LTS με compiler g++ 4.6 version και όταν το δοκιμάσω σε ubuntu 14.04LTS πάλι με 4.6 version να μην τρέχει μου βγάζει "error: 'unlink' was not declared in this scope" και "error: ‘rmdir’ was not declared in this scope" . Παρατήρησα ότι στην 14.04 έχει και τον compiler g++ 4.8 version installed από μόνο του .. λέτε να "μπερδεύεται" ; ; Tο πρόβλημα λύνεται όταν κάνω include την unistd.h library αλλά δεν μπορώ να καταλάβω γιατί να πρέπει να προσθέσω μία extra library στο πρόγραμμα οταν είναι ο ίδιος compiler και το ίδιο πρόγραμμα.. Ευχαριστώ !

[imitheos]

Καλημέρα και χρόνια πολλά ! Έχω μια απορία γενικής φύσεως .. Πως γίνεται το ίδιο ακριβώς πρόγραμμα να τρέχει-κάνει compile σε ubuntu 12.04LTS με compiler g++ 4.6 version και όταν το δοκιμάσω σε ubuntu 14.04LTS πάλι με 4.6 version να μην τρέχει μου βγάζει "error: 'unlink' was not declared in this scope" και "error: ‘rmdir’ was not declared in this scope" . Παρατήρησα ότι στην 14.04 έχει και τον compiler g++ 4.8 version installed από μόνο του .. λέτε να "μπερδεύεται" ; ; Tο πρόβλημα λύνεται όταν κάνω include την unistd.h library αλλά δεν μπορώ να καταλάβω γιατί να πρέπει να προσθέσω μία extra library στο πρόγραμμα οταν είναι ο ίδιος compiler και το ίδιο πρόγραμμα.. Ευχαριστώ !

Για να χρησιμοποιήσεις μια συνάρτηση πρέπει ο compiler να βρει ένα ορισμό της. Για αυτό το λόγο εισάγεις κάποια αρχεία κεφαλίδων όπως το unistd.h (άλλο πράγμα είναι η βιβλιοθήκη). Αν γράψεις σε ένα τερματικό "man 2 unlink rmdir" θα δεις ότι και οι δύο συναρτήσεις ορίζονται στο αρχείο unistd.h οπότε πρέπει ο κώδικάς σου να έχει το include.

 

Τώρα θα μου πεις όμως γιατί παλιά έπαιζε με ίδιο compiler. Γιατί αυτό το θέμα δεν είναι θέμα του compiler αλλά της βιβλιοθήκης libc που υλοποιεί τις συναρτήσεις και παρέχει τα αρχεία κεφαλίδων. Με ένα γρήγορο ψάξιμο, το 12.04LTS έχει αυτό το πακέτο με έκδοση 2.15 ενώ το 14.04 δίνει αυτό με έκδοση 2.19.

 

Τι άλλα αρχεία κεφαλίδων κάνεις include στον κώδικά σου ? Ένα πιθανό σενάριο είναι στην παλαιότερη έκδοση της libc κάποιο από αυτά τα αρχεία που κάνεις include να έκανε το ίδιο εσωτερικά include το unistd.d οπότε οι δηλώσεις των συναρτήσεων να υπήρχαν και στην επόμενη έκδοση να μην το κάνει πλέον.

[Razor911]

Α σ'ευχαριστώ πάρα πολύ για όλες αυτές τις πληροφορίες και διορθώσεις!!

 

Αυτά εδώ κάνω include επίσης :

#include <sys/types.h>
#include <sys/stat.h>
#include <dirent.h>
#include <iostream>
#include <fstream>
#include <cstdlib>
#include <string>
#include <cstdio>
#include <cstring>
#include <time.h>

[imitheos]

Δεν είναι φυσικά το μοναδικό σενάριο αυτό που είπα αλλά είναι από τα πιο πιθανά. Αν δεν βαριέσαι μπορείς να το ελέγξεις.

 

Όταν έχεις μια δήλωση που αρχίζει με # όπως η #include, αυτήν την βλέπει ο preprocessor και όχι ο compiler (άσχετα αν και τα δύο στάδια περιλαμβάνονται στο ίδιο πρόγραμμα). Ο preprocessor δηλαδή θα δει όλα αυτά τα include που έχεις και θα πάει και θα δημιουργήσει ένα αρχείο που πριν τον δικό σου κώδικα θα έχει τον κώδικα όλων αυτών των κεφαλίδων το ένα μετά το άλλο. Αυτό είναι το αρχείο που βλέπει ο compiler και προσπαθεί να το μεταγλωττίσει.

 

Γιατί στο είπα τώρα αυτό. Ο gcc υποστηρίζει την παράμετρο -E με την οποία του λες να μην κάνει compile αλλά να φτάσει μέχρι το στάδιο του preprocessor οπότε βλέπεις τον κώδικά σου μαζί με όλα τα includes όπως θα τον λάμβανε ο compiler.

 

Έτσι αν πας στο 12.04LTS και γράψεις

% g++ -E αρχείο_που_δεν_βρίσκει_την_rmdir.c > my12

θα σου δημιουργήσει ένα αρχείο με όνομα my12 το οποίο μέσα θα έχει όλες τις δηλώσεις όπως αυτές υλοποιούνται στην libc του 12.04. Αν μετά γράψεις

% g++ -E αρχείο_που_δεν_βρίσκει_την_rmdir.c > my14

στο 14άρι ubuntu και το σώσεις στο my14, θα δεις ότι αυτά τα δύο αρχεία θα έχουν πολλές διαφορές. Λογικά μία από αυτές θα είναι ότι στην νεώτερη έκδοση δεν θα υπάρχει ο κώδικας του unistd.h

 

Άσχετο με το παραπάνω πρόβλημα αλλά μια και βλέπω ότι θέλεις να ασχοληθείς με C++ και από ό,τι καταλαβαίνω είσαι στην αρχή ακόμη να αναφέρω κάτι άλλο. Η C++ ενώ είναι ξεχωριστή γλώσσα υποστηρίζει και τη σύνταξη της C (δυστυχώς κατ εμέ). Αυτό έχει ως συνέπεια να πέφτει πολύς κόσμος στη παγίδα του να μπλέκει τις δύο γλώσσες και πχ να χρησιμοποιεί malloc © αντί για new (c++) και διάφορα τέτοια.

 

Όταν βλέπεις ένα include που να τελειώνει σε .h είναι μια καλή πιθανότητα να μπλέκεται κώδικας της c. Μερικά αρχεία κεφαλίδων υλοποιούνται στην C++ ως cόνομα δηλαδή για τις συναρτήσεις που δηλώνονται στο αρχείο time.h μπορείς να χρησιμοποιείς #include <ctime> όπως το έχεις κάνει στην περίπτωση των cstdio, cstring, κτλ.

 

Δεν πολύ-σκαμπάζω από C++ οπότε κάποιος άλλος μπορεί να σου το αναλύσει πιο σωστά από εμένα και να σου δώσει κάποιες καλές συμβουλές.

[Timonkaipumpa]

Άσχετο με το παραπάνω πρόβλημα αλλά μια και βλέπω ότι θέλεις να ασχοληθείς με C++ και από ό,τι καταλαβαίνω είσαι στην αρχή ακόμη να αναφέρω κάτι άλλο. Η C++ ενώ είναι ξεχωριστή γλώσσα υποστηρίζει και τη σύνταξη της C (δυστυχώς κατ εμέ). Αυτό έχει ως συνέπεια να πέφτει πολύς κόσμος στη παγίδα του να μπλέκει τις δύο γλώσσες και πχ να χρησιμοποιεί malloc © αντί για new (c++) και διάφορα τέτοια.

Όταν βλέπεις ένα include που να τελειώνει σε .h είναι μια καλή πιθανότητα να μπλέκεται κώδικας της c. Μερικά αρχεία κεφαλίδων υλοποιούνται στην C++ ως cόνομα δηλαδή για τις συναρτήσεις που δηλώνονται στο αρχείο time.h μπορείς να χρησιμοποιείς #include <ctime> όπως το έχεις κάνει στην περίπτωση των cstdio, cstring, κτλ.

 

Δεν πολύ-σκαμπάζω από C++ οπότε κάποιος άλλος μπορεί να σου το αναλύσει πιο σωστά από εμένα και να σου δώσει κάποιες καλές συμβουλές.

 

 

 

Και δεν χρησιμοποιεί exceptions σε μεθόδους ή δεν χρησιμοποιεί σωστές exceptions (π.χ. invalid_argument ή logic_error, που είναι και μαμά-παιδί), δεν δηλώνει το global namespace με ::, δεν δεν δεν.....

 

Ή αλλιώς κάνει ένα πολύ ωραίο spaghetti programming και μετά του φταίει η C++ που δεν είναι ΟΟ enough και όχι ότι δεν ξέρει την γλώσσα.  

 

Πριν τα τελευταία πρότυπα θυμάμαι ότι κατά καιρούς χρησιμοποιώ .h headers και όχι τους "c" headers γιατί μερικά στοιχεία τα έχουν αφήσει στους .h. Δυστυχώς δεν θυμάμαι απόξω ποια είναι αυτά και βαριέμαι να ψάξω τώρα. 

[Razor911]

Δεν είναι φυσικά το μοναδικό σενάριο αυτό που είπα αλλά είναι από τα πιο πιθανά. Αν δεν βαριέσαι μπορείς να το ελέγξεις.

 

Όταν έχεις μια δήλωση που αρχίζει με # όπως η #include, αυτήν την βλέπει ο preprocessor και όχι ο compiler (άσχετα αν και τα δύο στάδια περιλαμβάνονται στο ίδιο πρόγραμμα). Ο preprocessor δηλαδή θα δει όλα αυτά τα include που έχεις και θα πάει και θα δημιουργήσει ένα αρχείο που πριν τον δικό σου κώδικα θα έχει τον κώδικα όλων αυτών των κεφαλίδων το ένα μετά το άλλο. Αυτό είναι το αρχείο που βλέπει ο compiler και προσπαθεί να το μεταγλωττίσει.

 

Γιατί στο είπα τώρα αυτό. Ο gcc υποστηρίζει την παράμετρο -E με την οποία του λες να μην κάνει compile αλλά να φτάσει μέχρι το στάδιο του preprocessor οπότε βλέπεις τον κώδικά σου μαζί με όλα τα includes όπως θα τον λάμβανε ο compiler.

 

Έτσι αν πας στο 12.04LTS και γράψεις

% g++ -E αρχείο_που_δεν_βρίσκει_την_rmdir.c > my12

θα σου δημιουργήσει ένα αρχείο με όνομα my12 το οποίο μέσα θα έχει όλες τις δηλώσεις όπως αυτές υλοποιούνται στην libc του 12.04. Αν μετά γράψεις

% g++ -E αρχείο_που_δεν_βρίσκει_την_rmdir.c > my14

στο 14άρι ubuntu και το σώσεις στο my14, θα δεις ότι αυτά τα δύο αρχεία θα έχουν πολλές διαφορές. Λογικά μία από αυτές θα είναι ότι στην νεώτερη έκδοση δεν θα υπάρχει ο κώδικας του unistd.h

 

Άσχετο με το παραπάνω πρόβλημα αλλά μια και βλέπω ότι θέλεις να ασχοληθείς με C++ και από ό,τι καταλαβαίνω είσαι στην αρχή ακόμη να αναφέρω κάτι άλλο. Η C++ ενώ είναι ξεχωριστή γλώσσα υποστηρίζει και τη σύνταξη της C (δυστυχώς κατ εμέ). Αυτό έχει ως συνέπεια να πέφτει πολύς κόσμος στη παγίδα του να μπλέκει τις δύο γλώσσες και πχ να χρησιμοποιεί malloc © αντί για new (c++) και διάφορα τέτοια.

 

Όταν βλέπεις ένα include που να τελειώνει σε .h είναι μια καλή πιθανότητα να μπλέκεται κώδικας της c. Μερικά αρχεία κεφαλίδων υλοποιούνται στην C++ ως cόνομα δηλαδή για τις συναρτήσεις που δηλώνονται στο αρχείο time.h μπορείς να χρησιμοποιείς #include <ctime> όπως το έχεις κάνει στην περίπτωση των cstdio, cstring, κτλ.

 

Δεν πολύ-σκαμπάζω από C++ οπότε κάποιος άλλος μπορεί να σου το αναλύσει πιο σωστά από εμένα και να σου δώσει κάποιες καλές συμβουλές.

 

hehe ναι δεν ξέρω πάντως μ' αρέσει περισσότερο η c++ από την c ,σου κάνει σε ορισμένες περιπτώσεις την ζωή πιο εύκολη νομίζω ! Χίλια ευχαριστώ και πάλι .. το είχα απορία αυτο γιατί γίνεται και τώρα όχι απλά μου λύθηκε .. έμαθα περισσότερα κιόλας ! !

[Timonkaipumpa]

hehe ναι δεν ξέρω πάντως μ' αρέσει περισσότερο η c++ από την c ,σου κάνει σε ορισμένες περιπτώσεις την ζωή πιο εύκολη νομίζω ! Χίλια ευχαριστώ και πάλι .. το είχα απορία αυτο γιατί γίνεται και τώρα όχι απλά μου λύθηκε .. έμαθα περισσότερα κιόλας ! !

 

 

Φαντάζομαι για να το λες αυτό χρησιμοποιείς τα features της C++, π.χ. για να ανοίξεις ένα αρχείο δεν χρησιμοποιείς το FILE αλλά streams. Σωστά; (Και το opening του file το έχεις μέσα σε try catch statement)

 

 

Συμφωνώ ότι σου κάνει την ζωή πιο εύκολη.... για την ακρίβεια στην κάνει πολύ εύκολη εάν πας με τα νερά της και όχι με ό,τι ξέρεις από C. 

[Razor911]

Φαντάζομαι για να το λες αυτό χρησιμοποιείς τα features της C++, π.χ. για να ανοίξεις ένα αρχείο δεν χρησιμοποιείς το FILE αλλά streams. Σωστά; (Και το opening του file το έχεις μέσα σε try catch statement)

 

 

Συμφωνώ ότι σου κάνει την ζωή πιο εύκολη.... για την ακρίβεια στην κάνει πολύ εύκολη εάν πας με τα νερά της και όχι με ό,τι ξέρεις από C. 

Ναί όσο μπορώ χρησιμοποιώ τα features της c++ απλά ορισμένες φορές κατανοώ καλύτερα την c ,εξαρτάτε την περίπτωση βέβαια πχ όταν είχαμε να κάνουμε κάτι με shared memory στην c++ ήτανε 2 γραμμές κώδικας και στην c "10" το ίδιο πράγμα ακριβώς :-P αλλού προτίμω c.. Mε streams τα κάνω οταν πρόκειται για αρχεία ναι! Απλά ακόμα είμαι φοιτητής το try-catch δεν το βάζω στις ασκήσεις μας στην c++ στην java το είχα δει που είναι και αυτή αντικειμενοστραφής γλώσσα και το βάζαμε σχεδόν παντού.. Πιστέυω ειναι overkill για try-catch για τις ασκήσεις που μας βάζουν c++ . Ενώ στην java έιχαμε να φτίαξουμε πολύ πιο σύνθετα πράγματα και μέτα εφαρμογή android Κλπ ! Τώρα δεν ξέρω τι να πώ λογικά το καλό είναι να το βάζεις οπου μπορείς ..!

[Timonkaipumpa]

Στην Java δεν μπορείς να μην το βάλεις... δεν σου αφήνει την επιλογή (βγάζει ένα error κάπως σαν uncaught exception ή κάτι τέτοιο...). Η C++ όμως στην αφήνει την επιλογή. 

 

Δεν είναι απλά καλό γενικά, πρέπει να βάζεις. 

 

 

Για απλά πράγματα είναι overkill ο ΟΟP, όχι συγκεκριμένα η C++ ή η Java. Εάν θέλει κανείς να κάνει κάτι γρήγορο (50 γραμμές κώδικα) δεν θα κάτσει να φτιάξει κλάσεις κτλ.... Μία - δύο functions (ούτε καν methods) και τελείωσε. Οπότε python και είσαι ΟΚ. 

 

 

Αλλά εάν γράφεις C++ και θες όντως να δεις το πόσο όμορφη είναι αυτή η γλώσσα φρόντισε να χρησιμοποιείς ό,τι σου δίνει. Προσπάθησε να το κάνεις με τα standards (χωρίς boost π.χ., εάν πρόκειται για no GUI app) και μετά πας σε τέτοια βοηθήματα...

 

 

Θα πάθεις πλάκα με το τι καλούδια έχει... ειδικά όταν αρχίσεις να βλέπεις containers και διαδικασίες πάνω στα στοιχεία ενός container... 

 

 

Y.Γ. Βέβαια.. όλες οι γλώσσες καλές είναι... π.χ. στην Java έχω λατρέψει τα buffers και τα pipes που έχει. Σκέτες ομορφιές. Τόσο pipes που όταν κάνω κάτι με αυτά νιώθω υδραυλικός!