Πρόβλημα με String και παράγωγες συναρτήσεις στην C++

[aris92]

Καλησπέρα και καλές γιορτές!

Έχω ορισμένα προβλήματα και χρειάζομαι βοήθεια.

1) Έχω πρόβλημα με τα string στην C++. Ενώ έχω βάλει την εντολή #include <string> 

και έχω αυτήν την μεταβλητή  ας πούμε

string name;

όταν πάω να το τρέξω που χτυπάει λάθος  `string' does not name a type 

2) Έχω έτοιμη την κλάση Person

 

class Person {

private:

string name;

unsigned long int ID;

string email;

public:

Person(string nm, unsigned long id, string em)

{ name=nm; ID=id; email=em; }

string getName(void) { return name; }

unsigned long int getID(void) { return ID; }

virtual void setEmail(string em) { email = em; }

string getEmail(void) { return email; }

};

 

μετά μου ζητάει 

Να ορίσώ μια κλάση Student η οποία να είναι απόγονος της Person και

αναπαριστά ένα μαθητή. Ο μαθητής έχει επιπλέον ένα ακέραιο αριθμό έτους, ο οποίος

επιστρέφεται με την public συνάρτηση-μέλος: unsigned short int getYear(void);

Αντικείμενα της Student πρέπει να δηλώνονται σαν, πχ:

// Mini Mouse is a 2nd year student with a student ID of 1002:

Student MiniMouse("Mini Mouse", 1002, 2, "[email protected]");

Εγω πάω μετά και ξαναβάζω στην νέα κλάση Student όλες τις private μεταβλητές της Person

και κάνω έναν νέο constructor μαζί με την νέα μεταβλητή δηλαδή

 

class Student: public Person {

      private: 

      string name;

      unsigned long int ID;

      string email;

      unsigned short int Year;

      public:

      Student(string nm,unsigned long id,unsigned short int etos, string em) 

      { name=nm; ID=id; email=em; Year=etos;}

      string getName(void) { return name; }

      unsigned long int getID(void) { return ID; }

      unsigned short int getYear(void){return Year);}

      string getEmail(void) { return email; }

 

είναι λάθος αυτό που κάνω? Γίνεται να το κάνω και αλλίως? Τα private της Person δεν μπορω να τα προσπελάσω στην Student έτσι δεν είναι?

3) Ορίζω μια κλάση Teacher η οποία να είναι απόγονος της Person και

αναπαριστά ένα καθηγητή. Ο καθηγητής έχει επιπλέον μια ειδικότητα (τύπου string),

που πρέπει να επιστρέφεται από την public συνάρτηση-μέλος: string

getSpecialty(void);

 

Αντικείμενα της Teacher πρέπει να δηλώνονται σαν, πχ:

// Smith is a teacher with ID 7777777,

// specialized in Object-Oriented Programming (OOP):

Teacher Smith("George Smith", 7777777, "OOP", "gsmith");

 

πάλι εγώ το κάνω με τον ίδιο τρόπο όπως στην Student

 

Επίσης μου ζητάει Το email των καθηγητών δίνεται μόνο σαν username, στο οποίο πρέπει αυτόματα

να επικολλήσετε το “@duth.gr”. Δλδ, η συνάρτηση Smith.getEmail() πρέπει να

επιστρέφει [email protected], ακόμα και μετά από κλήση της

Smith.setEmail(“gsmith”);

δεν ξερώ πως να χρησιμοποιώ τα Sting στην C++. πώς μπορώ να το κάνω αυτό?

 

Αυτααα...

thnks!

 

Τελικά για το πρόβλημα με τα string έπρεπε να βάλω και  using namespace std;

 

[defacer]

 

1) Έχω πρόβλημα με τα string στην C++. Ενώ έχω βάλει την εντολή #include <string> 

και έχω αυτήν την μεταβλητή  ας πούμε

string name;

όταν πάω να το τρέξω που χτυπάει λάθος  `string' does not name a type 

 

Η class string (όπως και όλες οι class της standard library) βρίσκεται μέσα στο namespace "std", οπότε όπως είδες και συ πρέπει είτε να αναφέρεσαι σ' αυτή με το πλήρες όνομά της (π.χ. "std::string name;") είτε να την κάνεις import με

using std::string;

είτε να φέρεις μέσα όλο το namespace με

using namespace std;

Το τελευταίο θεωρείται σε αρκετούς κύκλους κακό στυλ, αλλά στα πλαίσια μιας εργασίας δε χρειάζεται να σε απασχολεί.

 

 

2) Έχω έτοιμη την κλάση Person

 

μετά μου ζητάει 

Να ορίσώ μια κλάση Student η οποία να είναι απόγονος της Person και

αναπαριστά ένα μαθητή. Ο μαθητής έχει επιπλέον ένα ακέραιο αριθμό έτους, ο οποίος

επιστρέφεται με την public συνάρτηση-μέλος: unsigned short int getYear(void);

Αντικείμενα της Student πρέπει να δηλώνονται σαν, πχ:

// Mini Mouse is a 2nd year student with a student ID of 1002:

Student MiniMouse("Mini Mouse", 1002, 2, "[email protected]");

Εγω πάω μετά και ξαναβάζω στην νέα κλάση Student όλες τις private μεταβλητές της Person

και κάνω έναν νέο constructor μαζί με την νέα μεταβλητή

 

είναι λάθος αυτό που κάνω? Γίνεται να το κάνω και αλλίως? Τα private της Person δεν μπορω να τα προσπελάσω στην Student έτσι δεν είναι?

 

Καταρχήν στην class Person το σωστό είναι να γράψεις τον constructor σαν

Person(string nm, unsigned long id, string em) : name(nm), ID(id), email(em) {}

Το τμήμα ανάμεσα στην άνω κάτω τελεία και τις άδειες πλέον αγκύλες ονομάζεται constructor initialization list και "πρέπει" να είναι πάντα η επιλογή σου για τέτοιες αρχικοποιήσεις πεδίων της class. Το γιατί δεν είναι προφανές και δε θα το κουράσω εδώ αλλά αν θέλεις μπορείς να διαβάσεις π.χ. αυτό σχετικά.

 

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

 

Αν το πρόβλημά σου είναι πως δεν ξέρεις πώς να γράψεις τον constructor, θα το κάνεις έτσι:

Student(string nm,unsigned long id,unsigned short int etos, string em) : Person(nm, id, em), Year(etos) {}

Σ' αυτό το σημείο να πω επίσης ότι κάνεις "πολύ σημαντικά" (εξαρτάται βέβαια πώς το βλέπει κανείς) λάθη στυλ:

• Στον constructor της Student πας και βάζεις το έτος "ανάμεσα" στις παραμέτρους που παίρνει η base class Person. Απέφευγε να το κάνεις αν δεν υπάρχει συγκεκριμένος λόγος, βάλτην στο τέλος.
• Η ονομασία των πεδίων δεν είναι συνεπής: γιατί το Year γράφεται με κεφαλαίο αλλά όλα τα άλλα με μικρό? Βλέποντας μόνο τον constructor που δίνω παραπάνω, μπορείς να πεις με σιγουριά αν το Year είναι πεδίο της class Student ή αν είναι μια δεύτερη base class της Student την οποία αρχικοποιείς ακριβώς όπως την Person?

 

 

 

3) Ορίζω μια κλάση Teacher η οποία να είναι απόγονος της Person και

αναπαριστά ένα καθηγητή. Ο καθηγητής έχει επιπλέον μια ειδικότητα (τύπου string),

που πρέπει να επιστρέφεται από την public συνάρτηση-μέλος: string

getSpecialty(void);

 

Επίσης μου ζητάει Το email των καθηγητών δίνεται μόνο σαν username, στο οποίο πρέπει αυτόματα

να επικολλήσετε το “@duth.gr”. Δλδ, η συνάρτηση Smith.getEmail() πρέπει να

επιστρέφει [email protected], ακόμα και μετά από κλήση της

Smith.setEmail(“gsmith”);

δεν ξερώ πως να χρησιμοποιώ τα Sting στην C++. πώς μπορώ να το κάνω αυτό?

 

Τι ακριβώς είναι αυτό που δεν ξέρεις πώς να κάνεις?

[aris92]

ευχαριστώ πολύ για την βοήθεια.

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

Στο τρίτο ερώτημα μου αυτό που δεν ξέρω  να κάνω είναι πως θα κολλήσω πίσω από το username το @duth.gr και να το επιστρέψω έτσι. Γενικά δεν ξέρω καλά τα string και δεν ξέρω πως να τα χρησιμοποιώ.

[aris92]

βρήκα την συνάρτηση char * strncat ( char * destination, char * source, size_t num );

πήγα να το κάνω έτσι άλλα δεν μου έτρεξε( τι περίεργο.. ) 

 

 

void Teacher::setEmail(string em)

{

string str="@duth.gr";

 

strncat(em,str,9);

puts(em);

setEmail(em);

}

[Directx]

Καθώς η string υποστηρίζει τον τελεστή + μπορείς να κάνεις

	  string getEmail(void) {

		return email + "@duth.gr";

	  }

Οπότε και το email παραμένει καθαρό (ως έχει) και η getEmail το επιστρέφει με "@duth.gr" όποτε χρειάζεται.

[aris92]

ναι αλλά αφού δεν αλλάζω την mail καθόλου και αλλάζω μόνο την getEmail() τότε θα γίνεται αυτό που μου ζητάει Δλδ, η συνάρτηση Smith.getEmail() πρέπει να

επιστρέφει [email protected], ακόμα και μετά από κλήση της

Smith.setEmail(“gsmith”);

 

[defacer]

 

βρήκα την συνάρτηση char * strncat ( char * destination, char * source, size_t num );

πήγα να το κάνω έτσι άλλα δεν μου έτρεξε( τι περίεργο.. ) 

 

void Teacher::setEmail(string em)

{

string str="@duth.gr";

 

strncat(em,str,9);

puts(em);

setEmail(em);

}

 

Πρώτον, κάποια πράγματα πρέπει να τα καταλαβαίνεις μόνος σου. Η πρώτη παράμετρος της strncat είναι τύπου char*. Εσύ περνάς ένα std::string, το οποίο δεν υλοποιεί (επίτηδες) αυτό που λέγεται conversion operator σε char*. Πώς θα ήταν ποτέ δυνατόν να κάνει compile;

 

Δεύτερον, μακριά από συναρτήσεις του στυλ strncat και puts γιατί δε θα μάθεις ποτέ C++ αλλά αυτό που λέμε "C με καμια class που και που". Για όλα αυτά τα πράγματα υπάρχει ο C++ τρόπος.

 

 

ναι αλλά αφού δεν αλλάζω την mail καθόλου και αλλάζω μόνο την getEmail() τότε θα γίνεται αυτό που μου ζητάει Δλδ, η συνάρτηση Smith.getEmail() πρέπει να

επιστρέφει [email protected], ακόμα και μετά από κλήση της

Smith.setEmail(“gsmith”);

 

Ξεκίνα σκεπτόμενος τι ακριβώς είναι αυτό που θέλεις να κάνεις. Ξαναδιάβασα προσεκτικότερα το πρώτο σου post και είδα κάτι που δεν είχα προσέξει αλλά το οποίο είναι πάρα πολύ σημαντικό:

• το πεδίο email είναι private
• η setEmail() είναι virtual
• η getEmail() δεν είναι virtual

Είναι πολύ σημαντικό να έχεις καταλάβει τι ακριβώς σημαίνει αυτό για τις derived classes της Person, πράγμα για το οποίο δεν είμαι σίγουρος μιας και η Person μάλλον ήταν μέρος της εκφώνησης.

 

Εφόσον για την όποια derived class ο μόνος τρόπος να "ακουμπήσεις" το email είναι μέσω της Person::setEmail, αυτό σημαίνει πως αναγκαστικά θα πρέπει να κάνεις κάτι τέτοιο:

class Teacher : public Person {
public:
    virtual void setEmail(std::string email) {
        Person::setEmail(email + "@duth.gr");
    }
}

 

Αυτό που γίνεται εδώ είναι πως καλείς την Person::setEmail (γιατί αυτός είναι ο μόνος τρόπος με τον οποίο μπορείς να φτάσεις στο πεδίο email) περνώντας μια παράμετρο αλλαγμένη σε σχέση μ' αυτήν που σου περάστηκε εξαρχής.

 

Επίσης, ο λόγος για τον οποίο δουλεύει το email + "@duth.gr" δεν είναι βέβαια μαγική νεραϊδόσκονη αλλά το γεγονός ότι υπάρχει overload του std::operator+ που δέχεται σαν πρώτη παράμετρο ένα const string& και σαν δεύτερη ένα const char*, που είναι αυτά που του περνάμε στην προκειμένη.

 

Μπορείς να φανταστείς τον std::operator+ σαν μια οποιαδήποτε άλλη function f η οποία απλά έχει διαφορετική σύνταξη: αντί για f(x, y) γράφεις x + y. Απο κει και πέρα όλα τα άλλα είναι ίδια και κανονικά μπορεί κανείς να την κάνει overload (υποθέτω έχετε μάθει για overloads?) όσο του αρέσει (εσύ όμως δεν πρέπει να το κάνεις στη συγκεκριμένη γιατί απαγορεύεται αυστηρά να ορίσεις οτιδήποτε μέσα στο namespace std, με κάποιες προχωρημένες εξαιρέσεις που δε μας αφορούν εδώ).

 

 

 

Ο αναγνώστης-τσακάλι θα προσέξει ότι ο συγκεκριμένος operator βρίσκεται μέσα στο namespace std, πράγμα που εγείρει το ερώτημα ότι αν αντί να είχαμε παραπάνω using namespace std γράφαμε απλώς std::string όπου χρειάζεται, δε θα έπρεπε να δημιουργηθεί πρόβλημα επειδή δε θα βρίσκει τον operator+ στον οποίο αναφερόμαστε;

 

Η απάντηση είναι πως όντως έτσι θα ήταν τα πράγματα αν δεν υπήρχε ο κανόνας του λεγόμενου Koenig Lookup ή argument-dependent lookup.

 

 

 

Οπότε έχουμε μια υλοποίηση που πάντα κολλάει ένα @duth.gr πίσω από το email. Θα μπορούσες να πεις ότι βάσει της εκφώνησης που διάβασα παραπάνω αυτό είναι αρκετό, αλλά κατα την άποψή μου είναι κάθε άλλο παρά αρκετό, οπότε ξαναγυρνάω πίσω στο ότι πρέπει να σκεφτείς ακριβώς τι θέλεις να κάνεις. Γιατί μπορεί:

• Το email που θα σου περάσουν να περιέχει ήδη το @duth.gr
• Το email που θα σου περάσουν να περιέχει subdomain του duth.gr, π.χ. @ee.duth.gr
• Το email που θα σου περάσουν να περιέχει κάποιο άλλο domain άσχετο με το duth, π.χ. @auth.gr
• To email που θα σου περάσουν να είναι παντελώς άσχετο με email, π.χ. "%$#^#===@@@"

Πρέπει λοιπόν να σκεφτείς αν θα λάβεις υπόψη τις παραπάνω περιπτώσεις καθώς και το με ποιόν ακριβώς τρόπο θα αντιμετωπίσεις την κάθε μία. Απο κει και πέρα, έχοντας μια ιδέα του πώς θα κινηθείς πας και κοιτάς το τι εργαλεία προσφέρει η std::string για να δεις πώς θα μπορούσες να το υλοποιήσεις.

 

Αν το κάνεις αυτό κι έχεις άλλες απορίες εδώ είμαστε.

 

 

 

Καθώς η string υποστηρίζει τον τελεστή + μπορείς να κάνεις

	  string getEmail(void) {
		return email + "@duth.gr";
	  }

Οπότε και το email παραμένει καθαρό (ως έχει) και η getEmail το επιστρέφει με "@duth.gr" όποτε χρειάζεται.

 

Δεν μπορεί γιατί η getEmail δεν είναι virtual, οπότε τη στιγμή που θα γυρίσεις από τύπο Teacher σε Person* θα σταματήσει να δουλεύει.

Επεξ/σία 28 Δεκεμβρίου 2012 από defacer

[Directx]

Δεν το πρόσεξα και εγώ το virtual, στην τελική πάντως αν θέλει τόσο πολύ το private member θα μπορούσε να κάνει friend το Teacher στο Person οπότε αποκτά πρόσβαση στο private Person::email ώστε να μην το τροποποιήσει (με το Person:setEmail -στην περίπτωση που είναι τόσο σημαντικό το email να μην τροποποιηθεί φυσικά) αλλά απλά να το χρησιμοποιήσει ως έχει στην υλοποίηση Teacher::getEmail (καταλήγοντας στο τυπικό: return email + "..").

[aris92]

 

• Το email που θα σου περάσουν να περιέχει ήδη το @duth.gr
•  
• Το email που θα σου περάσουν να περιέχει subdomain του duth.gr, π.χ. @ee.duth.gr
•  
• Το email που θα σου περάσουν να περιέχει κάποιο άλλο domain άσχετο με το duth, π.χ. @auth.gr
•  
• To email που θα σου περάσουν να είναι παντελώς άσχετο με email, π.χ. "%$#^#===@@@"
•  

Θεωρώ πως μου δίνουν  σωστά δεδομένα

Thnks για την βοήθεια θα κοιτάξω καλύτερα τις virtual συναρτήσεις για να τα καταλάβω

[defacer]

Δεν το πρόσεξα και εγώ το virtual, στην τελική πάντως αν θέλει τόσο πολύ το private member θα μπορούσε να κάνει friend το Teacher στο Person οπότε αποκτά πρόσβαση στο private Person::email ώστε να μην το τροποποιήσει (με το Person:setEmail -στην περίπτωση που είναι τόσο σημαντικό το email να μην τροποποιηθεί φυσικά) αλλά απλά να το χρησιμοποιήσει ως έχει στην υλοποίηση Teacher::getEmail (καταλήγοντας στο τυπικό: return email + "..").

 

Φιλοσοφικά μιλώντας...

 

Το private ή όχι είναι design choice. Από τη στιγμή που το βάζεις private σημαίνει ότι δεν θέλεις να το ακουμπάει κανείς προκειμένου γενικά να έχεις εγγυημένα τη δυνατότητα να διατηρείς τα invariants της class, ασχέτως που στην προκειμένη η class είναι πάλι by design φτιαγμένη για να είναι base class όπως είναι προφανές από την virtual method.

 

 

 

Το παραπάνω ακούγεται προφανές, αλλά το λεπτό σημείο είναι πως δεν κάνει η παρουσία μιας virtual method την class σχεδιασμένη για να είναι base (όπως εδώ) -- αντίθετα, η απουσία οποιασδήποτε virtual method κάνει την class ακατάλληλη για derivation τελεία και παύλα σχεδόν πάντα.

 

Γι' αυτό και όλες οι concrete classes που ας πούμε "είναι διαθέσιμες να γίνουν base" έχουν πάντα τουλάχιστον ένα virtual destructor (το "πάντα" είναι πολύ πολύ ελαφριά απλοποίηση -- σύντομη εξήγηση, λίγο πιο περιεκτική, πολύ hardcore) ακόμα και όταν δε νιώθει ο συγγραφέας την ανάγκη να τους δώσει κάποια "χρήσιμη" virtual method.

 

Εν τέλει αυτό που θέλω να πω είναι πως αν η setEmail δεν ήταν virtual τότε απαγορεύεται να κάνεις derive από την Person επειδή έτσι σε βολεύει. Αυτό βέβαια είναι εκτός scope της εργασίας.

 

 

 

Το να δώσεις friendship σε κάποια άλλη class έχει τρία προβλήματα. Το ένα είναι σχετικό με την παραπάνω παράγραφο: το private δείχνει design choice. Αν δεν ήθελες private ας έβαζες protected. Αυτό είναι βέβαια προφανές και στους 2 μας, αλλά στη συνέχεια το να έχεις ταυτόχρονα στη συγκεκριμένη περίπτωση και private και friend δείχνει ότι ο συγγραφέας της class και η έννοια object-oriented design δεν έχουν γνωριστεί ποτέ. Και αυτό είναι το πρώτο πρόβλημα, που κάνει την πρόταση του friend πολύ κακή στα μάτια μου: όταν κάποιος που δεν ξέρει την ακολουθήσει έχει μπει σε καλό δρόμο για να γίνει object oriented κάγκουρας (αν αυτός ο χαρακτηρισμός γίνει διάσημος, να ξέρετε ότι τον σκέφτηκα αυτόνομα ).

 

Το δεύτερο πρόβλημα με το friend είναι πως στη γενική περίπτωση δε μπορείς να ξέρεις ποιές είναι οι classes που θα κάνουν derive απο σένα, άρα δε μπορείς να τους κάνεις friend γιατί δεν ξέρεις τα ονόματά τους. Επομένως η "λύση του friend" γενικά δεν είναι λύση, είναι πατέντα που τυχαίνει να μπορεί να εφαρμοστεί στα πλαίσια της συγκεκριμένης εργασίας. Και ως πατέντα θα προτιμούσα να μη τη βλέπω να προτείνεται γιατί στην τελική έτσι δε μαθαίνει κανείς τίποτα καλό.

 

Το τρίτο και τελευταίο πρόβλημα είναι πως η σχέση friend είναι η πιο coupled σχέση που υπάρχει στη C++, ακόμα περισσότερο και από public inheritance. Less coupling = good, οπότε η friendship (θα πρέπει να) είναι κυριολεκτικά η λύση της τελευταίας επιλογής. Δε μπορώ να φανταστώ πρόβλημα που να μπορεί αρχάριος να το κατανοήσει πλήρως και ταυτόχρονα να μην έχει λύση προτιμότερη του friendship, άρα δε μπορώ να φανταστώ και λόγο για να προταθεί ως λύση υπό αυτές τις συνθήκες.

 

Ελπίζω να είναι κατανοητό πως όλα αυτά τα έγραψα επειδή είναι απαραίτητο να τα ξέρει όποιος θέλει να λέει ότι γνωρίζει C++, αλλά πετώντας μια friend δεν πρόκειται να μάθει ποτέ ούτε τα παραπάνω ούτε πόσο overkill ήταν αυτό που έκανε.

Επεξ/σία 28 Δεκεμβρίου 2012 από defacer

[Directx]

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

[defacer]

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

 

Εκεί ήταν η αντίρρησή μου, όχι στη χρήση της friend γενικότερα.

[Directx]

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

 

Εκεί ήταν η αντίρρησή μου, όχι στη χρήση της friend γενικότερα.

Ok, άλλα μπορούμε να πούμε στον νεοσύλλεκτο ότι ως "τελική λύση" υπάρχουν και τα "πυρηνικά" (αν και ως μεταφορά είναι μάλλον υπερβολική).

 

Anyway νομίζω ότι το εξαντλήσαμε το θέμα