Здравствуйте, Аноним, Вы писали:
А>Подскажите для чего в plain C (не C++) используются статические функции. Какой смысл в объявлении static Когда нет ни объектов ни классов
static в С виден тока в одной единице трансляции (где объявлен)
Здравствуйте, Аноним, Вы писали:
А>Подскажите для чего в plain C (не C++) используются статические функции. Какой смысл в объявлении static Когда нет ни объектов ни классов
Статическая функция доступна только в том же модуле, где и определена. Более того, в другом моделе может быть другая статическая функция с таким же именем.
это популярный вопрос на собеседованиях: рассказать зачем в С/C++ используется ключевое слово static, потому что оно может означать несколько разных вещей.
Здравствуйте, Аноним, Вы писали:
А>Подскажите для чего в plain C (не C++) используются статические функции. Какой смысл в объявлении static Когда нет ни объектов ни классов
Такая функция имеет внутреннее связывание, и доступна только в одной единице трансляции (только в том .c — файле, в котором она определена).
Здравствуйте, Conr, Вы писали:
C>Здравствуйте, Аноним, Вы писали:
А>>Подскажите для чего в plain C (не C++) используются статические функции. Какой смысл в объявлении static Когда нет ни объектов ни классов C>Статическая функция доступна только в том же модуле, где и определена. Более того, в другом моделе может быть другая статическая функция с таким же именем.
а если функция объявлена в хедере? Тогда как?
Здравствуйте, March_rabbit, Вы писали:
А>>>Подскажите для чего в plain C (не C++) используются статические функции. Какой смысл в объявлении static Когда нет ни объектов ни классов C>>Статическая функция доступна только в том же модуле, где и определена. Более того, в другом моделе может быть другая статическая функция с таким же именем. M_>а если функция объявлена в хедере? Тогда как?
Естественно, будет дубликат в каждой единице трансляции, в которую включен этот хедер.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, dilmah, Вы писали:
D>это популярный вопрос на собеседованиях: рассказать зачем в С/C++ используется ключевое слово static, потому что оно может означать несколько разных вещей.
Кто-то на сей счет заметил, что, судя по всему, авторы языка должны были платить за каждое слово
Здравствуйте, Аноним, Вы писали:
А>Подскажите для чего в plain C (не C++) используются статические функции. Какой смысл в объявлении static Когда нет ни объектов ни классов
В двух целях: Чтобы не засорять глобальное пространство имен (то, которое видно линкеру)
Чтобы функция, которая не предназначенна для вызова кем попало снаружи файла, была для вызова недоступна
Первое нужно, чтобы не было необходимости следить, что все функции, в т.ч. внутренние, имеют разное название в масштабах проекта. Для большого проекта это может быть достаточно хлопотно.
Второе нужно, чтобы ясно разделить, какие функции являются публичным интерфейсом вашего модуля, а какие — нет.
Вообще, хорошим стилем является объявлять все символы (функции и локальные переменные), которые не должны торчать из модуля, статическими. К сожалению, по дефолту они не static.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кто-то на сей счет заметил, что, судя по всему, авторы языка должны были платить за каждое слово
Да и за каждый символ тоже.
Иначе не было бы такого изврата, как ~ для деструктора и =0 для абстрактной функции.
Только не говорите, что это ускоряет лексер... это, в первую очередь, оттормаживает парсер, которому надо следить за именем деструктора, а заодно считать =(compile_time_const_expression_equal_to_zero_of_any_type).
Последнее — вообще крышесносящая идея
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Кто-то на сей счет заметил, что, судя по всему, авторы языка должны были платить за каждое слово
К>Да и за каждый символ тоже. К>Иначе не было бы такого изврата, как ~ для деструктора и =0 для абстрактной функции. К>Только не говорите, что это ускоряет лексер... это, в первую очередь, оттормаживает парсер, которому надо следить за именем деструктора, а заодно считать =(compile_time_const_expression_equal_to_zero_of_any_type). К>Последнее — вообще крышесносящая идея
И? Объяви #define pure_virtual_kodt_syntax =0 и не хнычь
А аргументы про скорость работы парсера устарели еще лет 10 назад, т.к. тормоза идут, в основном, от дисковой подсистемы.
Здравствуйте, пыщьх, Вы писали:
К>>Да и за каждый символ тоже. К>>Иначе не было бы такого изврата, как ~ для деструктора и =0 для абстрактной функции. К>>Только не говорите, что это ускоряет лексер... это, в первую очередь, оттормаживает парсер, которому надо следить за именем деструктора, а заодно считать =(compile_time_const_expression_equal_to_zero_of_any_type). К>>Последнее — вообще крышесносящая идея П>И? Объяви #define pure_virtual_kodt_syntax =0 и не хнычь
Всё уже украдено до нас, я пишу abstract — благо, компилятор VC унифицирован для C++/MC++/C++CLI
И не хнычу, а прихожу в недоумение — как такой бред придти в голову авторам языка. Или напротив, не придти, а возникнуть, как дыра в стандарте, которую пришлось поддерживать авторам компиляторов.
П>А аргументы про скорость работы парсера устарели еще лет 10 назад, т.к. тормоза идут, в основном, от дисковой подсистемы.
Здравствуйте, пыщьх, Вы писали:
К>>Последнее — вообще крышесносящая идея П>И? Объяви #define pure_virtual_kodt_syntax =0 и не хнычь П>А аргументы про скорость работы парсера устарели еще лет 10 назад, т.к. тормоза идут, в основном, от дисковой подсистемы.
Глупость какая. Скажите мне, почему g++ раза в 2 медленнее, чем gcc? Что, файлы с расширением .cpp медленнее читаются с диска?
MSVC, кстати, еще медленнее, так что вместо ожидаемого ответа, что это проблемы gcc, скажите что-нибудь еще
Здравствуйте, Pzz, Вы писали:
Pzz>Глупость какая. Скажите мне, почему g++ раза в 2 медленнее, чем gcc? Что, файлы с расширением .cpp медленнее читаются с диска? Pzz>MSVC, кстати, еще медленнее, так что вместо ожидаемого ответа, что это проблемы gcc, скажите что-нибудь еще
Потому что запуская gcc после g++ на одном и том же файле, второй раз он читается из кэша
Здравствуйте, пыщьх, Вы писали:
Pzz>>Глупость какая. Скажите мне, почему g++ раза в 2 медленнее, чем gcc? Что, файлы с расширением .cpp медленнее читаются с диска? Pzz>>MSVC, кстати, еще медленнее, так что вместо ожидаемого ответа, что это проблемы gcc, скажите что-нибудь еще П>Потому что запуская gcc после g++ на одном и том же файле, второй раз он читается из кэша
А если я g++ запускаю после gcc, он что, назад из кеша на диск заталкивается?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, пыщьх, Вы писали:
Pzz>>>Глупость какая. Скажите мне, почему g++ раза в 2 медленнее, чем gcc? Что, файлы с расширением .cpp медленнее читаются с диска? Pzz>>>MSVC, кстати, еще медленнее, так что вместо ожидаемого ответа, что это проблемы gcc, скажите что-нибудь еще П>>Потому что запуская gcc после g++ на одном и том же файле, второй раз он читается из кэша
Pzz>А если я g++ запускаю после gcc, он что, назад из кеша на диск заталкивается?
Pzz>Hint: не надо считать других совсем уж идиотами
Приведи тогда конкретный воспроизводимый пример, а не абстрактные рассуждения.
Здравствуйте, пыщьх, Вы писали:
Pzz>>Hint: не надо считать других совсем уж идиотами П>Приведи тогда конкретный воспроизводимый пример, а не абстрактные рассуждения.
$ time gcc -o test.o -c -O2 -Wall -g -c -I ../include `pkg-config --cflags opencv glib-2.0 gtk+-2.0 gmodule-2.0` test.c
real 0m1.668s
user 0m1.504s
sys 0m0.132s
$ time gcc -o test.o -c -O2 -Wall -g -c -I ../include `pkg-config --cflags opencv glib-2.0 gtk+-2.0 gmodule-2.0` test.cpp
real 0m4.517s
user 0m4.264s
sys 0m0.236s
Файлы test.c и test.cpp одинаковые. Содержимое, sorry, не приведу по разным причинам. Считайте, что это абстрактная, довольно незамысловатая программа размером 633 строки. Времена такие большие потому, что процессором там работает Intel Atom , но на нормальном процессоре соотношение между C и C++ такого же плана.
Кстати, обратите внимание, что на ввод-вывод времени ушло немного. Под C++ больше, но там и объектник получился в 2 раза больше (видимо из-за дополнительной отладочной информации).
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, пыщьх, Вы писали:
Pzz>>>Hint: не надо считать других совсем уж идиотами П>>Приведи тогда конкретный воспроизводимый пример, а не абстрактные рассуждения.
Pzz>
Pzz>Файлы test.c и test.cpp одинаковые. Содержимое, sorry, не приведу по разным причинам. Считайте, что это абстрактная, довольно незамысловатая программа размером 633 строки. Времена такие большие потому, что процессором там работает Intel Atom , но на нормальном процессоре соотношение между C и C++ такого же плана.
Pzz>Кстати, обратите внимание, что на ввод-вывод времени ушло немного. Под C++ больше, но там и объектник получился в 2 раза больше (видимо из-за дополнительной отладочной информации).
Согласен, есть доля правды. Но тут еще вопрос, сколько времени уходит на инициализацию внутренних структур, а сколько — на парсинг. На атоме ничего большого gcc не компилял, но студия там довольно сильно тормозит... Но это — плата за 10 часов от батарейки... На нормальных CPU разница будет а-ля 100 мс или 200 мс, которую никто не заметит...
Здравствуйте, пыщьх, Вы писали:
П>Согласен, есть доля правды. Но тут еще вопрос, сколько времени уходит на инициализацию внутренних структур, а сколько — на парсинг. На атоме ничего большого gcc не компилял, но студия там довольно сильно тормозит... Но это — плата за 10 часов от батарейки... На нормальных CPU разница будет а-ля 100 мс или 200 мс, которую никто не заметит...
Ээээ. Ну у меня в типичном проекте не один такой файл Так что и разница будет соответствующая...
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, пыщьх, Вы писали:
П>>Согласен, есть доля правды. Но тут еще вопрос, сколько времени уходит на инициализацию внутренних структур, а сколько — на парсинг. На атоме ничего большого gcc не компилял, но студия там довольно сильно тормозит... Но это — плата за 10 часов от батарейки... На нормальных CPU разница будет а-ля 100 мс или 200 мс, которую никто не заметит...
Pzz>Ээээ. Ну у меня в типичном проекте не один такой файл Так что и разница будет соответствующая...
Разница полной перекомпиляции — да. Дальше — make спасет. Плюс, на написание руками void init_mystruct(mystruct *p) {p->f1 = &mystruct_f1;} вместо virtual void f1{} уйдет гораздо больше времени, чем на чтение "более сложного" синтаксиса компилятором.
Перекуём баги на фичи!
