c++ - Do repetitive calls to member functions hurt? -

i have programmed in both java , c, , trying hands dirty c++.

given code:

class booth {  private :           int tickets_sold; public :           int get_tickets_sold();           void set_tickets_sold(); }; 

in java, wherever needed value of tickets_sold, call getter repeatedly.

for example:

if (obj.get_tickets_sold() > 50 && obj.get_tickets_sold() < 75){      //do } 

in c value of particular variable in structure:

if( obj_t->tickets_sold > 50 && obj_t->tickets_sold < 75){     //do } 

so while using structures in c, save on 2 calls otherwise make in java, 2 getters is, not sure if actual calls or java somehow inlines calls.

my point if use same technique used in java in c++ well, 2 calls getter member functions cost me, or compiler somehow know inline code? (thus reducing overhead of function call altogether?)

alternatively, better off using:

int num_tickets = 0;  if ( (num_tickets = obj.get_ticket_sold()) > 50 && num_tickets < 75){     //do } 

i want write tight code , avoid unnecessary function calls, care in java, because, well, know why. but, want code readable , use private , public keywords correctly reflect done.

if you're learning language, shouldn't worry this. consider fast enough until proven otherwise. said, there lot of misleading or incomplete answers here, record i'll flesh out few of subtler implications. consider class:

class booth {   public:     int get_tickets_sold();     void set_tickets_sold();   private:     int tickets_sold; }; 

the implementation (known definition) of , set functions not yet specified. if you'd specified function bodies inside class declaration compiler consider have implicitly requested inlined (but may ignore if they're excessively large). if specify them later using inline keyword, has safe effect. summarily...

class booth {   public:     int get_tickets_sold() { return tickets_sold; }     ... 

...and...

class booth {   public:     int get_tickets_sold();     ... };  inline int booth::get_tickets_sold() { return tickets_sold; } 

...are equivalent (at least in terms of standard encourages expect, individual compiler heuristics may vary - inlining request compiler's free ignore).

if function bodies specified later without inline keyword, compiler under no obligation inline them, may still choose so. it's more if appear in same translation unit (i.e. in .cc/.cpp/.c++/etc. "implementation" file you're compiling or header directly or indirectly included it). if implementation available @ link time functions may not inlined @ all, depends on way particular compiler , linker interact , cooperate. not matter of enabling optimisation , expecting magic. prove this, consider following code:

// inline.h: void f();  // inline.cc: #include <cstdio> void f() { printf("f()\n"); }  // inline_app.cc: #include "inline.h" int main() { f(); } 

building this:

g++ -o4 -c inline.cc g++ -o4 -o inline_app inline_app.cc inline.o 

investigating inlining:

$ gdb inline_app  ... (gdb) break main breakpoint 1 @ 0x80483f3 (gdb) break f breakpoint 2 @ 0x8048416 (gdb) run starting program: /home/delroton/dev/inline_app   breakpoint 1, 0x080483f3 in main () (gdb) next single stepping until exit function main,  has no line number information.  breakpoint 2, 0x08048416 in f () (gdb) step single stepping until exit function _z1fv,  has no line number information. f() 0x080483fb in main () (gdb)  

notice execution went 0x080483f3 in main() 0x08048416 in f() 0x080483fb in main()... not inlined. illustrates inlining can't expected because function's implementation trivial.

notice example static linking of object files. clearly, if use library files may actually want avoid inlining of functions can update library without having recompile client code. it's more useful shared libraries linking done implicitly @ load time anyway.

very often, classes providing trivial functions use 2 forms of expected-inlined function definitions (i.e. inside class or inline keyword) if functions can expected called inside performance-critical loops, countering consideration inlining function force client code recompiled (relatively slow, possibly no automated trigger) , relinked (fast, shared libraries happens on next execution), rather relinked, in order pick changes function implementation.

these kind of considerations annoying, deliberate management of these tradeoffs allows enterprise use of c , c++ scale tens , hundreds of millions of lines , thousands of individual projects, sharing various libraries on decades.

one other small detail: ballpark figure, out-of-line get/set function typically order of magnitude (10x) slower equivalent inlined code. vary cpu, compiler, optimisation level, variable type, cache hits/misses etc..