I wonder if there is some theory/tool available to replace a piece of code that contains function calls, into code where all function call has been replaced by their respective code.
like
main()
{
fun();
}
fun()
{
int i;
fun2();
}
fun2()
{
int j;
}
into
main()
{
int i;
int j;
}
I know there is a lot to take care of, like local variable names, recursive calls, external function calls etc etc. .. ..
I also know that it may not be at all useful, but still does something like this exist? even in theory?
should I call it advance per-processor unit :)
The compiler can usually tell when it's a good idea to do this, and already automatically does inlining whenever needed. You can also suggest that a function should be inlined using the inline keyword before a function (note that it still doesn't actually force it, and the compiler might decide to avoid the inlining).It's generally not such a good idea to do this manually, as modern compilers tend to figure out the best possible inlinings on their own. This article explains inline functions really well, I found it very helpful
Edit 1:
There are several reasons why one might want to do that inlining you speak of. If you feel like your code is divided into many different functions reducing its clarity and making it overly verbose, you could try a refactoring tool, such as the one provided by the VAssist X Visual Studio plugin. Though this plugin doesn't really do what you suggest (I can't think of a tool that does), it can help move functions/ methods around with ease, allowing you to clean up your code.
Related
Take for example:
int main(void){
numberComparator comparator1;
comparator1.setA(78.321);
comparator1.showA();
comparator1.setB('c');
comparator1.setB("Yes");
comparator1.setB(124.213);
comparator1.showB();
comparator1.setB(12);
return 0;
}
Instead of saying comparator1 over and over again, can I do something shorter?
I understand that this doesn't really change much about how the program works, but it does make it easier to work around with testing a class I make.
I am doing overloading so that for an assortment of inputs into my comparator, my program can handle them without making the results go crazy. In this case, I want the input to be an int, but what if the input isn't?
The answer could be lying around the internet, but as my title may infer, I do not know how to state the question.
You are looking for something like with keyword which is part of, for example, Pascal language.
Unfortunately, C++ doesn't provide similar feature. Using the references, one can shorten the name of the class and somewhat alleviate the pain, i.e.
Comparator comparator1;
...
{
Comparator& cr = comparator1;
cr.a();
cr.b();
cr.c();
}
It depends. If numberComparator has a "fluent" interface, then each member function will return a reference to *this, and you can write:
comparator1
.setA(78.321)
.showA()
.setB('c')
.setB("Yes")
.setB(124.213)
.showB()
.setB(12);
Note that this is a bitch to debug by step-into (you have to step into every function until you get to the one you are interested in).
The alternative of course is "use a shorter name".
int main(void){
numberComparator c1;
c1.setA(78.321);
c1.showA();
c1.setB('c');
c1.setB("Yes");
c1.setB(124.213);
c1.showB();
c1.setB(12);
return 0;
}
There is really no point in having a particularly long name if it is limited in scope to a few lines. For a local variable, if it isn't limited in scope to a few lines, your function is probably too long.
Is there a way to tell g++ more about a type, function, or specific variable (other than attributes) that I might know is safe to preform.
Example:
TurnLedOn();
TurnLedOn();
Only the first function actually turns the LED on the second function does not actually do anything....so would it be possible to tell g++ more about the function so that it gets rid of a second call if it knows that the LED is on (because it knows that a corresponding TurnLedOff() function has not been called)....
The reason I do not want to use g++ attributes is because I want to arbitrarily define optimizations, which is really not possible with attributes (and I believe the optimization I am trying here is not actually possible to begin with using attributes)
These are optimisations you need to code. Such as:
class LedSwitch {
bool isOn{false};
public:
inline void turnLedOn(){
if (!isOn) {
isOn = true;
// ...
}
}
// ...
}
// ...
If the code inlines then the compiler might then notice the bool negated in the second hardcoded sequential call, but why do that in the first place?
Maybe you should revisit design if things like this are slowing down your code.
One possibility is to make it so that the second TurnLedOn call does nothing, and make it inline and declare it in a header file so the compiler can see the definition in any source file:
extern bool isLedOn; // defined somewhere else
inline void TurnLedOn()
{
if(!isLedOn)
{
ActuallyTurnLedOn();
isLedOn = true;
}
}
Then the compiler might be able to figure out by itself that calling TurnLedOn twice does nothing useful. Of course, as with any optimization, you have no guarantees.
Contrary to your thinking, the answer by #immibis is what you were expecting.
This way to describe the complex behavior of the function TurnLedOn (i.e. needn't be called twice in a row unless unlocked by some other action) is indeed how you tell the compiler to perform this "optimization".
Could you imagine other annotations such as
#pragma call_once_toggle_pair(TurnLEDOn, TurnLEDOff)
with innumerable variants describing all your vagaries ?
The C++ language has enough provisions to let you express arbitrarily complex situations, please don't add yet a layer of complexity on top of that.
Assuming this is my library. And it is a very huge library:
library.hpp
template<class usertype> void function_name(usertype aaa)
{
}
This is my main
int main()
{
int x=3;
function_name(x);
double y=3.5;
function_name(y);
return 0;
}
I do not know what is going inside the library. What I want is to convert the library to adapt my code. In fact, reducing the template into real code.
I need the library code above be converted into:
void function_name(int aaa)
{
}
void function_name(double aaa)
{
}
So I can manipulate the library according to my needs instead of manipulating the general code that works for everybody. How can this conversion from template to real code be done (without manual effort, but in automatic way)?
Edit:
I want to convert the whole file library.hpp into library_2.hpp which contains no template. Instead with two real implemented functions. This is what happens in the middle of the compilation.
I am not looking for reducing the compilation time. I am dealing with a huge library made of 196 files. Among those many functions in the library, I will need a few of them related to my work. I intend to hack and extend this library. Extending the whole library has huge effort cost for me. I just want to extend only what I need. So, it is very important for me to reduce the code and simplify it and remove all templates replacing them with explicit code.
I am not good at C++ and it compiler errors. So, in such a huge library, I prefer to use automatic methods rather than involving manual code manipulation. I am also not good at understanding this library. To understand the library, better to convert its complicated functions into explicit implemented code related to what I really need. Then I can understand someones else code better. I will remove the functions not related to my needs. I also do not care about updates coming to the library. Once I establish new library, its maintenance is my duty. And the new library would be much smaller and easier for maintenance. Comments show that some people looking at my aim from different view. I hope this explanation is clear.
In case of curiosity, the library I am going to manipulate is odeint related to mathematical computations with rarely change or bug inside.
I'm not entirely sure what you want to achieve but from reading the comments, I think that your major concern is that you are trying to reduce compile times and get less template-related error messages. You are not trying to specialize library functions for your own types.
If you only instantiate the templated functions from the library with a handful of types, there is a simple recipe to get templates out of your picture. But it will force you to write two lines of code for each combination of templated function and type you want to use it with.
Create your own header file library_wrapper.hpp. There, you declare non-template versions of the functions you want to use.
library_wrapper.hpp
#ifndef LIBRARY_WRAPPER_H
#define LIBRARY_WRAPPER_H
#include <vector> // just an example
namespace library_wrapper
{
void
function_name(int);
void
function_name(double);
int
another_function(const std::vector<double>&, bool);
}
#endif
And then “implement” them once and for all using your so-little-loved template library.
library_wrapper.cpp
#include "library_wrapper.hpp"
#include <library.hpp> // the template library
namespace library_wrapper
{
void
function_name(const int arg1)
{
return library::function_name(arg1);
}
void
function_name(const double arg1)
{
return library::function_name(arg1);
}
int
another_function(const std::vector<double>& arg1, const bool arg2)
{
return library::function(arg1, arg2);
}
}
You compile library_wrapper.cpp once, fight the templates, and then continue using only your wrapper which provides the non-templated functions.
Be aware that this approach jeopardizes one of the major reasons templates can be so fast: inlining. Your wrapper functions cannot be inlined at compile-time because you are hiding their definitions from the compiler. This is on purpose and, on the other hand, buys you shorter compile times. Link-time inlining might give you some inlining back but you shouldn't take it as granted.
Note that this solution does not work quite as well with types (as opposed to functions). You could try writing some pimpl-wrappers but I don't recommend this. Maybe the best thing would be to become friends with your template library…
Update addressing your updated question
I am dealing with a huge library made of 196 files. Among those many functions in the library, I will need a few of them related to my work.
In case of curiosity, the library I am going to manipulate is odeint related to mathematical computations with rarely change or bug inside.
This seems like the above approach could indeed help.
Extending the whole library has huge effort cost for me. I just want to extend only what I need. So, it is very important for me to reduce the code and simplify it and remove all templates replacing them with explicit code.
I don't think that this is a good approach. Instead, use the library as a black box and build your own on top of it. Concentrate your developer effort on the new features and benefit from updates for the underlying library.
I assume that the library in question is free software (otherwise, what you want to do would be illegal anyway) and free software project should support each other. If you are building an awesome library Y on top of library X, both
projects, X and Y, can benefit. On the other hand, if you rip out only a part of that other library and add other functionality, your two rivalling projects might both end up as something incomplete and incompatible which is frustrating for both, you and your users.
To understand the library, better to convert its complicated functions into explicit implemented code related to what I really need. Then I can understand someones else code better.
I don't think that you can reasonably expect that some machine-generated code will be more readable than the original human-written code of the library. After all, human coders are taught to write code for humans but compilers are optimized for other aspects.
I am not good at C++ and it compiler errors. […] I am also not good at understanding this library.
I intend to hack and extend this library.
I also do not care about updates coming to the library. Once I establish new library, its maintenance is my duty.
I don't want to seem rude but … do you see the problem?
by specialization
template<>
void function_name(int aaa)
{
}
template<>
void function_name(double aaa)
{
}
sample code
#include <iostream>
template<class usertype>
void function_name(usertype aaa)
{
std::cout << "default\n";
}
template<>
void function_name(int aaa)
{
std::cout << "int value = " << aaa << '\n';
}
template<>
void function_name(double aaa)
{
std::cout << "double value = " << aaa << '\n';
}
int main()
{
int x = 3;
function_name(x);
double y = 3.5;
function_name(y);
struct Z{} z;
function_name(z);
return 0;
}
I have programmed in both Java and C, and now I am trying to get my hands dirty with C++.
Given this code:
class Booth {
private :
int tickets_sold;
public :
int get_tickets_sold();
void set_tickets_sold();
};
In Java, wherever I needed the value of tickets_sold, I would call the getter repeatedly.
For example:
if (obj.get_tickets_sold() > 50 && obj.get_tickets_sold() < 75){
//do something
}
In C I would just get the value of the particular variable in the structure:
if( obj_t->tickets_sold > 50 && obj_t->tickets_sold < 75){
//do something
}
So while using structures in C, I save on the two calls that I would otherwise make in Java, the two getters that is, I am not even sure if those are actual calls or Java somehow inlines those calls.
My point is if I use the same technique that I used in Java in C++ as well, will those two calls to getter member functions cost me, or will the compiler somehow know to inline the code? (thus reducing the overhead of function call altogether?)
Alternatively, am I better off using:
int num_tickets = 0;
if ( (num_tickets = obj.get_ticket_sold()) > 50 && num_tickets < 75){
//do something
}
I want to write tight code and avoid unnecessary function calls, I would care about this in Java, because, well, we all know why. But, I want my code to be readable and to use the private and public keywords to correctly reflect what is to be done.
Unless your program is too slow, it doesn't really matter. In 99.9999% of code, the overhead of a function call is insignificant. Write the clearest, easiest to maintain, easiest to understand code that you can and only start tweaking for performance after you know where your performance hot spots are, if you have any at all.
That said, modern C++ compilers (and some linkers) can and will inline functions, especially simple functions like this one.
If you're just learning the language, you really shouldn't worry about this. Consider it fast enough until proven otherwise. That said, there are a lot of misleading or incomplete answers here, so for the record I'll flesh out a few of the subtler implications. Consider your class:
class Booth
{
public:
int get_tickets_sold();
void set_tickets_sold();
private:
int tickets_sold;
};
The implementation (known as a definition) of the get and set functions is not yet specified. If you'd specified function bodies inside the class declaration then the compiler would consider you to have implicitly requested they be inlined (but may ignore that if they're excessively large). If you specify them later using the inline keyword, that has exactly the 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 what the Standard encourages us to expect, but individual compiler heuristics may vary - inlining is a request that the compiler's free to ignore).
If the function bodies are specified later without the inline keyword, then the compiler is under no obligation to inline them, but may still choose to do so. It's much more likely to do so if they appear in the same translation unit (i.e. in the .cc/.cpp/.c++/etc. "implementation" file you're compiling or some header directly or indirectly included by it). If the implementation is only available at link time then the functions may not be inlined at all, but it depends on the way your particular compiler and linker interact and cooperate. It is not simply a matter of enabling optimisation and expecting magic. To prove this, consider the 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 the inlining:
$ gdb inline_app
...
(gdb) break main
Breakpoint 1 at 0x80483f3
(gdb) break f
Breakpoint 2 at 0x8048416
(gdb) run
Starting program: /home/delroton/dev/inline_app
Breakpoint 1, 0x080483f3 in main ()
(gdb) next
Single stepping until exit from function main,
which has no line number information.
Breakpoint 2, 0x08048416 in f ()
(gdb) step
Single stepping until exit from function _Z1fv,
which has no line number information.
f()
0x080483fb in main ()
(gdb)
Notice the execution went from 0x080483f3 in main() to 0x08048416 in f() then back to 0x080483fb in main()... clearly not inlined. This illustrates that inlining can't be expected just because a function's implementation is trivial.
Notice that this example is with static linking of object files. Clearly, if you use library files you may actually want to avoid inlining of the functions specifically so that you can update the library without having to recompile the client code. It's even more useful for shared libraries where the linking is done implicitly at load time anyway.
Very often, classes providing trivial functions use the two forms of expected-inlined function definitions (i.e. inside class or with inline keyword) if those functions can be expected to be called inside any performance-critical loops, but the countering consideration is that by inlining a function you force client code to be recompiled (relatively slow, possibly no automated trigger) and relinked (fast, for shared libraries happens on next execution), rather than just relinked, in order to pick up changes to the function implementation.
These kind of considerations are annoying, but deliberate management of these tradeoffs is what allows enterprise use of C and C++ to scale to tens and hundreds of millions of lines and thousands of individual projects, all sharing various libraries over decades.
One other small detail: as a ballpark figure, an out-of-line get/set function is typically about an order of magnitude (10x) slower than the equivalent inlined code. That will obviously vary with CPU, compiler, optimisation level, variable type, cache hits/misses etc..
No, repetitive calls to member functions will not hurt.
If it's just a getter function, it will almost certainly be inlined by the C++ compiler (at least with release/optimized builds) and the Java Virtual Machine may "figure out" that a certain function is being called frequently and optimize for that. So there's pretty much no performance penalty for using functions in general.
You should always code for readability first. Of course, that's not to say that you should completely ignore performance outright, but if performance is unacceptable then you can always profile your code and see where the slowest parts are.
Also, by restricting access to the tickets_sold variable behind getter functions, you can pretty much guarantee that the only code that can modify the tickets_sold variable to member functions of Booth. This allows you to enforce invariants in program behavior.
For example, tickets_sold is obviously not going to be a negative value. That is an invariant of the structure. You can enforce that invariant by making tickets_sold private and making sure your member functions do not violate that invariant. The Booth class makes tickets_sold available as a "read-only data member" via a getter function to everyone else and still preserves the invariant.
Making it a public variable means that anybody can go and trample over the data in tickets_sold, which basically completely destroys your ability to enforce any invariants on tickets_sold. Which makes it possible for someone to write a negative number into tickets_sold, which is of course nonsensical.
The compiler is very likely to inline function calls like this.
class Booth {
public:
int get_tickets_sold() const { return tickets_sold; }
private:
int tickets_sold;
};
Your compiler should inline get_tickets_sold, I would be very surprised if it didn't. If not, you either need to use a new compiler or turn on optimizations.
Any compiler worth its salt will easily optimize the getters into direct member access. The only times that won't happen are when you have optimization explicitly disabled (e.g. for a debug build) or if you're using a brain-dead compiler (in which case, you should seriously consider ditching it for a real compiler).
The compiler will very likely do the work for you, but in general, for things like this I would approach it more from the C perspective rather than the Java perspective unless you want to make the member access a const reference. However, when dealing with integers, there's usually little value in using a const reference over a copy (at least in 32 bit environments since both are 4 bytes), so your example isn't really a good one here... Perhaps this may illustrate why you would use a getter/setter in C++:
class StringHolder
{
public:
const std::string& get_string() { return my_string; }
void set_string(const std::string& val) { if(!val.empty()) { my_string = val; } }
private
std::string my_string;
}
That prevents modification except through the setter which would then allow you to perform extra logic. However, in a simple class such as this, the value of this model is nil, you've just made the coder who is calling it type more and haven't really added any value. For such a class, I wouldn't have a getter/setter model.
Consider this piece of code:
class A {
void methodX() {
// snip (1 liner function)
}
}
class B {
void methodX() {
// same -code
}
}
Now other way i can go is, I have a class(AppManager) most of whose members are static, (from legacy code, don't suggest me singleton ;))
class AppManager {
public:
static void methodX(){
// same-code
}
}
Which one should be preferred?
As both are inlined, there shouldn't be a runtime difference, right?
Which form is more cleaner?
Now first of all, this is a concern so minuscule that you would never have to worry about it unless the functions are called thousands of times per frame (and you're doing something where "frames" matter).
Second, IF they are inlined, the code will be (hopefully) optimized so much that there is no sign whatsoever of the function being non-static. It would be identical.
Even if they were not inlined, the difference would be minor. The ABI would put the "this" pointer into a register (or the stack), which it wouldn't do in a static function, but again, the net result would be almost not measurable.
Bottom line - write your code in the cleanest possible way. Performance is not a concern at this point.
In my opinion Inline way would be faster.
because inline functions are replaced in code in compile time and therefor there is no need to save registers, make a function call and then return again. but when you call a static function it's just a function call and it has much overhead than the inline one.
I think that this is most common optimisation problem. At first level when you writing a code you try every single trick that would help compiler so if compiler can not optimise code well, you already have. This is wrong. What are you looking for in first stage of optimisation during writing code is just clean and understandable code, design and structure. That will make by far better code, that "optimised" by hand.
Rule is:
If you do not have resources to benchmark code, rewrite it and spend lot of time for optimisation than you do not need optimised code. In most cases it is hard to gain any speed boost whit any kind optimisation, if you structured your code well.