Expansion problem caused by the use of generics in C++

高洛峰
Release: 2016-11-22 17:33:41
Original
1375 people have browsed it

A few days ago, a blogger read an article criticizing C++'s generics for causing bloated code in the generated executable file.

The blogger has been engaged in C++ software development for many years. Since the previous development environment was a server with sufficient resources, there was no need to consider the issue of disk space. Recently, I plan to use C++ for development on the embedded platform of the smart home host. FLASH storage space is limited, this is a factor that must be considered and must be paid attention to.

Define two lists as follows, with different element types:

list<int> l1;
list<string> l2;
Copy after login

What should I do if I use C language? It will write one set of code for list, and another set for list. Each set has the same member functions, just different variable types.

The following is the C language implementation of list:

//! code-1struct list_int_item {
    int value;
    struct list_int_item *next;
};struct list_int {
    struct list_int_item *head;
    size_t size;
};

void list_int_insert(struct list_int *p, int value);int  list_int_sort(struct list_int *p);bool list_int_empty(struct list_int *p);
...
Copy after login

The following is the C language implementation of list:

//! code-2
struct list_string_item {
    string value;
    struct list_string_item *next;
};

struct list_string {
    struct list_string_item *head;
    size_t size;
};

void list_string_insert(struct list_int *p, string value);
int  list_string_sort(struct list_int *p);
bool list_string_empty(struct list_int *p);
...
Copy after login

The difference between the two is the type. So many times, in C language, we use macros to replace its types, as follows:

//! code-3
#define LIST_DECLARE(TYPE) \
    struct list_##TYPE##_item { \
        TYPE## value; \
        struct list_##TYPE##_item *next; \
    }; \
    \
    struct list_##TYPE { \
        struct list_##TYPE##_item *head; \
        size_t size; \
    }; \
    \
    void list_##TYPE##_insert(struct list_##TYPE *p, ##TYPE## value); \
    int  list_##TYPE##_sort(struct list_##TYPE *p); \
    bool list_##TYPE##_empty(struct list_##TYPE *p); \
    ...
Copy after login

Then list is defined in the header file like this:

//! code-4

LIST_DECLARE(double)
Copy after login

Therefore, it is impossible to generate redundant code with generics Avoidable, at least using C to do such generics is unavoidable.

Since it is unavoidable, let’s see how to avoid the above problems as much as possible. There is a chapter in "Effective C++" that specifically mentions: Do not use unnecessary parameters in templates. Because the compiler will generate a corresponding set of codes for each different parameter.

If there is only one data type in the code, even if multiple variables are defined using this type, will the compiler only generate a set of related codes? (It should be like this).

Write an example for comparison: (omitting unnecessary code)

test1.cpp, which only has map, but m1, m2, m3 are defined.

//! code-5

    map<int, string> m1;
    map<int, string> m2;
    map<int, string> m3;

    m1.insert(std::make_pair(1, "hello"));
    m2.insert(std::make_pair(1, "hi"));
    m3.insert(std::make_pair(1, "lichunjun"));
Copy after login

test2.cpp, compared with test1.cpp, there are three types:

//! code-6    map<int, string> m1;
    map<int, double> m2;
    map<int, int> m3;

    m1.insert(std::make_pair(1, "hello"));
    m2.insert(std::make_pair(1, 1.2));
    m3.insert(std::make_pair(1, 44));
Copy after login

As a result, the size comparison of the compiled executable file:

[hevake_lcj@Hevake tmp]$ ll test1 test2
-rwxrwxr-x. 1 18784 Mar 19 22:01 test1
-rwxrwxr-x. 1 35184 Mar 19 22:03 test2
Copy after login

test2 is twice as big as test1. Needless to say the reason.


Another question: Are pointers considered a type?

The above list and list cannot share the same set of codes. The reason is that the two types of int and string are different in terms of space size and assignment methods. Therefore, two sets of codes must be generated to achieve this.

And pointers, no matter what they are, they are the same. We can use void* to represent all pointer types.

So we changed the above code and tested it again:

//! code-7    map<int, string*> m1;
    map<int, string*> m2;
    map<int, string*> m3;

    m1.insert(std::make_pair(1, new string("hello")));
    m2.insert(std::make_pair(1, new string("hi")));
    m3.insert(std::make_pair(1, new string("lichunjun")));
Copy after login

and

//! code-8    map<int, string*> m1;
    map<int, double*> m2;
    map<int, int*> m3;

    m1.insert(std::make_pair(1, new string("hello")));
    m2.insert(std::make_pair(1, new double(1.2)));
    m3.insert(std::make_pair(1, new int(44)));
Copy after login

The results are like this:

-rwxrwxr-x. 1 18736 Mar 19 23:05 test1
-rwxrwxr-x. 1 35136 Mar 19 23:05 test2
Copy after login

The expected results test1 and test2 are similar, but there is no optimization from the results. A bit disappointing~


Thinking: Are there any parameters in C++ that can optimize this?

If not, in order to save space, we can only define all pointers as void* type, and then cast them when using them.

//! code-9    map<int, void*> m1;
    map<int, void*> m2;
    map<int, void*> m3;

    m1.insert(std::make_pair(1, new string("hello")));
    m2.insert(std::make_pair(1, new double(1.2)));
    m3.insert(std::make_pair(1, new int(44)));

    cout << *static_cast<string*>(m1[1]) << endl;
    cout << *static_cast<double*>(m2[1]) << endl;
    cout << *static_cast<int*>(m3[1]) << endl;
Copy after login

The above code is based on code-8, defining all specifications as void*, and using static_cast to force conversion into the corresponding pointer type when used.

Compared with code-7, the code size obtained in this way is only 16 bytes more.

But this approach is very undesirable. After void* pointers must be used, the compiler no longer checks the type, and it is easy to confuse the type.


Related labels:
c++
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template