Тут ещё бывает кто-нибудь, кто знаком с 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 июня 2023 года в 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
Я так понял речь идет о чем-то таком
//————————————————————
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
В тех же исходниках gcc-4.7 есть файл gcc/stor-layout.c, что предусматривает всевозможные варианты
Хотя просмотрев все конфиги для разных архитектур получилось
Очень много архитектур экзотичных, но вот значимые
Собственно мы далеко отошли от темы. При оригинальной постановке вопроса однозначный ответ «Нет».
А так, то теоретически можно остаться с простреленой ногой даже не имея пистолета :)
Тут я понимаю следующее. Ядро собрано с таким 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.