Тут ещё бывает кто-нибудь, кто знаком с C++?
Вопрос тут такой возник… Различны ли size_t и unsigned для механизма перегрузки функций в C++? При условии, что sizeof(size_t) == sizeof(unsigned) и size_t тоже беззнаковый. Короче, при условии, что size_t объявлен typedef’ом как unsigned int.
Если вопрос не совсем понятен, я могу пример привести, допустим есть функция int foo(unsigned); Допустимо ли перегрузить её таким образом: int foo(size_t)?
Вопрос может быть достаточно ламерский, но мне просто лень искать какую-нибудь документацию на стандарт C++. Тем более что стандартов много, а какой именно мне нужен — я не знаю, я с C++ завязал лет десять назад, и сегодня совершенно не в курсе.
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Я так понял речь идет о чем-то таком
//————————————————————
typedef int some;
int func(int i) {
return i*2;
};
int func(some i) {
return int(i)*2;
};
int main(int argc, char *argv[]) {
int i = 1;
some j = 1;
int res = func(i);
int res2 = func(j);
return 0;
}
//————————————————————
На попытку компиляции g++ ответил следующим образом
т.е. для механизма перегрузки это одинаковые типы, а значит перегрузить не получиться.
P.S. Из личного опыта скажу, что в подобных «непонятках» часто помогают коротенькие тестовые примерчики. Не всегда то что написано в стандартах воспринимается по прочтению.
Копнув немного глубже нашел www.learncpp.com/cpp-tutorial/76-function-overloading/ описано весьма неплохо механизм выбора функции при перегрузке.
Ну и на любимом www.cplusplus.com нашел хорошее объяснение почему через typedef не работает:
typedef does not create different types. It only creates synonyms of existing types. ( www.cplusplus.com/doc/tutorial/other_data_types/ )
Спасибо за исследование. =)
Тем не менее:
$ cat test.cpp:
$ g++ -o prog test.cpp
$ ./prog
PS
Это если вопрос про size_t. Он никак не unsigned int.
Но как бы там ни было, главный вывод в том, что «typedef does not create different types». Достаточно очевидная вещь, если подумать, но меня видимо lisp’овский deftype с толку сбил. Он немного иначе себя ведёт, но в C (с которым я постоянно сталкиваюсь) разница не заметна. Сказывается лишь в C++.
На утверждение что «Это если вопрос про size_t. Он никак не unsigned int.» можно утверждать, что это зависит от платформы. Если скомпилировать Ваш же пример, но как
То получим ту же ошибку переопределения
Так что может где size_t идет как unsigned int, это еще неизвестно.
Ну это в ембеде где-нить может можно делать. На обычных системах 4гига файлик — не очень приятно. В линухе size_t объявлен как long в ядреном коде (а выстрелить в ногу можно и другими, не менее прекрасными методами :D )
Что-то я не совсем понял Ваш ответ. Если Вы про то, что я особо извратился — отнюдь, просто для некоторых аппаратных платформ это может быть может быть по-умолчанию. А вот size_t объявлен не в ядреном коде, где лишь используется, а в самом GCC, а там уж что в нем прописано — как повезет. Я думаю что не зря size_t определяется не напрямую, а через дополнительные макросы со значением по-умолчанию, в файле gcc/c-family/c-common.c
builtin_define_with_value ("__SIZE_TYPE__", SIZE_TYPE, 0);В тех же исходниках gcc-4.7 есть файл gcc/stor-layout.c, что предусматривает всевозможные варианты
/* Get sizetypes precision from the SIZE_TYPE target macro. */ if (strcmp (SIZE_TYPE, "unsigned int") == 0) precision = INT_TYPE_SIZE; else if (strcmp (SIZE_TYPE, "long unsigned int") == 0) precision = LONG_TYPE_SIZE; else if (strcmp (SIZE_TYPE, "long long unsigned int") == 0) precision = LONG_LONG_TYPE_SIZE; else if (strcmp (SIZE_TYPE, "short unsigned int") == 0) precision = SHORT_TYPE_SIZE; else gcc_unreachable ();Хотя просмотрев все конфиги для разных архитектур получилось
Очень много архитектур экзотичных, но вот значимые
Собственно мы далеко отошли от темы. При оригинальной постановке вопроса однозначный ответ «Нет».
А так, то теоретически можно остаться с простреленой ногой даже не имея пистолета :)
Тут я понимаю следующее. Ядро собрано с таким size_t, который является стандартным для когнфига GCC (ну предположим что собираем для платформы на которой работаем и не играем в темные игры). ТОгда не очень весело компилить свои бинари, переопределив size_t. Поскольку можно слегка нарваться при выполнении системного вызова.
Да не говорю я что его нужно обязательно переопределять. Я просто категорически не согласен с Вашим высказыванием:
«В линухе size_t объявлен как long в ядреном коде»
Он не обязательно long и задается не в коде ядра, а скорее уж в libc, а именно в stddef.h, который у меня содержит код
А вот __SIZE_TYPE__ по-умолчанию как раз и есть SIZE_TYPE, который далеко не всегда unsigned long int, что было изложено выше. И это все без «тёмных игр» и чего либо подобного.
Вот с чем соглашусь, так это то, что особо не стоит менять и переопределять стандартные вещи, если это не является необходимостью.
Не поленился и поставил chroot с i486 Debian testing. Итог
g++-4.7 test.cpp
и результат sizeof(size_t) — 4.
size_t — это для измерения буферов в оперативной памяти и всегда работает такое: sizeof(size_t) <= sizeof(void*). На 32-х битной платформе больше 32-бит size_t не будет. А для файликов больше 4Gb libc объявляет тип off_t. Который, кстати, тоже может быть 32-бита (и, вероятно, он всегда 32-бита на 32-х битной платформе), но чтобы исправить это, существует ещё off64_t.