Миграция GCC с 4.1.2 на 6.2.0 и с RHEL 5.5 на CentOS 7.2

У меня есть RHEL с GCC 4.1.2, и мой код C++ компилируется, как и ожидалось. Но тот же код, когда я пытаюсь скомпилировать CentOS 7.2 с GCC 6.2.0, завершается ошибкой ниже:

compiling UpcSummarization.o ...
UpcSummarization.cpp: In member function âvoid UpcSummarization::LoadUpcList(std::__cxx11::string)â:
UpcSummarization.cpp:480:40: error: âmemsetâ was not declared in this scope
         memset(&pBuffer, 0, sizeof(100));
                                        ^

Я включаю ниже заголовочный файл:

string

Если я включу string.h или cstring, это пройдет.

Есть идеи, как заставить его работать только с string включаемым файлом? Миграция кодовой базы для включения string.h или cstring невозможна.

ИЗМЕНИТЬ

Да, это была струна.

Возможно, мне следовало сформулировать это как второй вариант вместо не вариант

Прежде чем начать миграцию кода, мне нужно исключить любую возможность параметров компилятора, чтобы заставить его работать как есть.

Я могу установить дополнительные библиотеки, если это необходимо, и изменить способ их компиляции. На самом деле не редактируя код.


person Krish Sanj    schedule 25.01.2017    source источник
comment
Ну, memset находится в cstring. Почему включение правильного заголовка не вариант?!   -  person Biffen    schedule 25.01.2017
comment
Не имеет отношения, но вы уверены, что sizeof(100) это то, что вам здесь нужно?   -  person Moshe Gottlieb    schedule 25.01.2017
comment
@Biffen, я не уверен, правильно ли я компилирую. и не уверен, что мне действительно следует изменить код. Поскольку он работает на более старой версии ОС и GCC, мне нужно понять, можно ли это исправить, изменив способ его компиляции.   -  person Krish Sanj    schedule 25.01.2017
comment
@KrishSanj Вероятно, это работает с более ранней версией, потому что некоторый заголовок случайно включает какой-то другой заголовок. Это не значит, что это правильно. Что правильнее, так это включать cstring, когда вы хотите использовать memset (или, возможно, прекратить использование memset).   -  person Biffen    schedule 25.01.2017
comment
@KrishSanj На самом деле не редактирует код - в этом случае вы, скорее всего, не сможете перенести на 6.2, извините.   -  person yugr    schedule 25.01.2017


Ответы (1)


Я включаю ниже заголовочный файл: sting

нить?

Есть идеи, как заставить его работать только с строковым включаемым файлом?

Вы можете создать фиктивный файл string и сохранить его вместе с другими заголовками. Внутри string вы делаете, например

#include <string.h>

Миграция кодовой базы для включения string.h или cstring невозможна.

Обратите внимание, что вы, скорее всего, не сможете перенести свой код на 6.2, если не сможете изменить его даже в такой небольшой степени. Между версиями 4.1 и 6.2 разница составляет 10 лет, поэтому ваш код определенно потребует изменений/исправлений для работы с более новым компилятором.

person yugr    schedule 25.01.2017
comment
@KrishSanj Если вы можете исправить свой код, чтобы использовать string.h, это, конечно, предпочтительнее. - person yugr; 25.01.2017
comment
В C++ используйте cstring, а не string.h. - person Biffen; 25.01.2017
comment
@Biffen Есть ли от этого какая-то особая польза? - person yugr; 25.01.2017
comment
Я пытался найти источник, но он кажется более спорным, чем я думал. Во всяком случае, здесь кое-что. - person Biffen; 25.01.2017
comment
@yugr с ‹cstring› символы гарантированно находятся в пространстве имен std::, что затрудняет случайное обращение к неправильным символам. - person Galik; 25.01.2017
comment
@Galik Да, я знаю о std::, но мне интересно, насколько это полезно на практике (кто-нибудь когда-нибудь случайно ссылался на memset?). - person yugr; 25.01.2017
comment
Если вы ссылаетесь на свои символы, используя std:: или using std::symbol; и т. д. (как и следует), то включение <string.h> может привести к повреждению кода, если вы измените/обновите компилятор. С другой стороны, <cstring> гарантирует, что ваши ссылки std::... всегда будут там. - person Galik; 25.01.2017
comment
Но если вы не используете std::, включение <cstring> также приведет к поломке кода :) - person yugr; 25.01.2017