Esiste un modo migliore per eseguire il debug evitando getter / setter?

0

Sto pensando a come eseguire il debug di meglio senza usare Getter / Setter. Se aiuta, programmo usando xcode.

Molte risposte in Stack Exchange hanno discusso contro Getters / Setters per mancanza di incapsulamento (leggi: Quando Jetters e Setters sono giustificati ), ma il mio ragionamento per ora è che li uso per facilitare il debugging; impostare un break-point al getter / setter è molto più semplice che cercare in ogni punto in cui si accede alla variabile.

La denominazione intelligente risolve parzialmente questo problema poiché posso cercare rapidamente il nome della variabile, ma non risolve il mio problema di dover trovare ogni accesso / modifica della variabile; Devo ancora impostare i breakpoint ovunque.

C'è un modo semplice per evitare getter e setter mentre scopri quando le mie variabili sono modificate / accessibili in modo semplice?

PS. Spero di non fare qualche stupido errore da principiante, o di essere ignaro di qualche trucco xcode economico e semplice qui.

Modifica: Forse dovrei elaborare un po 'di più. Spesso, le variabili che voglio controllare sono direttamente accessibili / modificate. Voglio solo sapere quando la variabile è accessibile / modificata facilmente.

    
posta Mark Ang 29.03.2016 - 09:37
fonte

5 risposte

1

PS. I hope I'm not making some stupid rookie mistake, or being ignorant of some cheap and simple xcode hack here.

Il debugger xcode supporta punti di interruzione quando una variabile viene modificata.

Is there an easy way to avoid getters and setters whilst discovering when my variables are modified/accessed in an easy way?

Generalmente non li scrive .

Avrai casi in cui hai bisogno di un getter o di un setter, ma questo è solo se il tuo oggetto ha la funzione esplicita di ottenere / impostare un valore (per esempi, vedi std :: unique_ptr :: get , o boost :: optional :: get).

Nella maggior parte degli altri casi, dovresti essere in grado di evitare di esporre una classe private .

    
risposta data 31.03.2016 - 10:36
fonte
0

Evitare getter / setter non riguarda l'accesso diretto alle variabili membro, ma decidere quale interfaccia esporre per la classe.

ad es. Per una classe Person, invece di avere un membro 'age' e un getter che restituisce semplicemente questa variabile, dovresti pensare a un modo migliore per rappresentare le operazioni sulla Persona. Un esempio potrebbe essere quello di memorizzare la data di nascita e quindi fornire un getter per l'età che lo calcola.

Quindi dovresti comunque avere un metodo per accedere alla tua classe, ma non un metodo senza cervello che corrisponde a ciascuna variabile membro.

    
risposta data 29.03.2016 - 09:54
fonte
0

Se hai bisogno di getter e setter a scopo di debug, puoi sempre avvolgere le tue variabili e rimuovere il wrapper in seguito (o semplicemente permetterle di essere elidato dall'ottimizzatore). Il wrapper ha bisogno di un costruttore di conversioni implicite, operatori di cast ecc., Qualcosa del genere (nota: codice completamente non testato):

template <typename T>
struct Wrapper {
  Wrapper() {}
  Wrapper(T v) : val_(v) {}
  // default all copy/move constructors and assignment operators
  operator T () const { return val_; }
  operator T&() { return val_; }
  // also assignment from T, and any other required operators
private:
  T val_;
};

Questo dovrebbe avere praticamente alcun effetto (almeno per i tipi primitivi), ma ti dà un posto dove impostare i breakpoint.

Se sei interessato a specifiche istanze puoi semplicemente utilizzare un watchpoint senza modifica del codice (qualcosa come questo , presumibilmente, anche se non uso xcode).

    
risposta data 29.03.2016 - 11:54
fonte
0

È specifico per l'implementazione, a seconda sia del compilatore (e delle opzioni di compilazione) sia del debugger (comandi di & debugger).

Con un recente compilatore GCC (GCC 5.3 o successivo a marzo 2016) utilizzando un debugger GDB recente (GDB 7.11 o successivo a marzo 2016, con supporto Python e Guile abilitato in fase di compilazione con opzioni appropriate a configure ) su Linux, potresti scrivere GDB in Python o in Guile, quindi personalizzarlo per soddisfare le tue esigenze (in modo che tu possa stampare piuttosto alcune classi o contenitori come desideri). Purtroppo, oggi non sono bravo (perché sono un po 'zoppo, e soprattutto perché la documentazione è incompleta). Probabilmente ti interesseranno anche i watchpoint GDB.

BTW, getter e setter sono spesso in linea, quindi potrebbe non avere importanza (prestazioni) nel codice di produzione.

    
risposta data 29.03.2016 - 13:57
fonte
0

XCode / lldb chiamano questo un punto di controllo.

Puoi impostare un punto di controllo sulla variabile in questione, quindi l'esecuzione si interromperà ogni volta che una variabile viene letta o scritta.

Puoi impostare un watchpoint in XCode andando alla vista Variables, facendo clic con il pulsante destro del mouse sulla variabile che ti interessa nell'elenco e nel menu a comparsa selezionando "Watch foo" (dove foo è sostituito dal nome della variabile in questione). Di default questo attiva solo le scritture su quella variabile.

Se vuoi un maggiore controllo, puoi aprire la finestra della console lldb e usare i comandi lldb per impostare il tuo punto di osservazione. Ciò ti consente di impostare un'interruzione durante la lettura oppure (ad esempio) interrompe solo quando viene scritto un valore specifico.

Se digiti "Help watchpoint" nella console lldb, dovrebbe darti maggiori dettagli. Potresti anche voler leggere la sezione "IMPOSTAZIONE DEI WATCHPOINTS" nel tutorial Lldb .

Aggiungo che, almeno a mio parere, questo non dovrebbe essere definito un "trucco".

Se usi la tua camicia come filtro per l'acqua che è (o almeno potrebbe qualificarsi come) un trucco.
Se indossi la tua camicia perché è stata progettata per essere indossata, indossa solo una maglietta.

Questo è più o meno lo stesso: non sta nemmeno tentando di inventare un nuovo modo intelligente per usare XCode o lldb per compiere qualche strana missione per la quale non erano realmente progettati. Piuttosto, è solo utilizzando una funzionalità del debugger esattamente come previsto per fare esattamente quello che è stato progettato per fare.

    
risposta data 29.03.2016 - 15:45
fonte

Leggi altre domande sui tag