C namespaces

Кому-то плюс, а кому-то бессмысленность. Мне вот плевать есть namespaces или нет. Так и целой куче разработчиков и системных и нет на это плевать. А то что не плевать делают. Вот непонятно почему некоторые думают, что раз у них в голове каша, то у других она тоже там?

Вот непонятно почему некоторые думают, что раз у них в голове каша, то у других она тоже там?
ixrws ★★

Лол.

Вместо glSomething писать gl::something? Два двоеточия — это типа профит такой, или что?

Нет, именно использование namespace'ов плюсовых. То есть если часто используешь gl::something пишешь

using gl::something;
something();

using gl;
something();

С теми же блоками видимости, что и в плюсах.

Я к тому, что библиотечныхПриставокПередИменемФункцииАЗатемНазваниеФункции - это можно было бы и избежать.

Будет использован bar::something, насколько помню. Т.к. ты указав

using bar;

using foo;

А это очень плохо. Потому что когда код был написан, bar::something могло и не быть вообще.

Это явно определено. Кроме того, рекомендуется указывать так именно те функции, которые хочешь использовать, а не весь namespace.

Кстати я ошибся немного, для импорта всего namespace требуется указать

using namespace gl;

Компилятор должен сказать что тут неоднозначность

Но вообще да, непонятно зачем эти неймспейсы в С. Перегрузка операторов, например, была бы полезнее

Надоедает писать приставка+имя функции иногда.

Функций тогда уж, зачем операторов?

Судя по Qt, namespace и в плюсовой среде не особо то популярны. QString вместо qt::string на что и показывает. Странно всё это, удобная фича так то.

А я не пойму, почему многим так хочется из простого С сделать С++. Один строки хочет, другой namespace, третий классы. У вас уже есть один С++, зачем второй?

Компилятор должен сказать что тут неоднозначность

В крестах? Насколько я помню, там действуют правила overloading-а имён, и компилятор укажет на неоднозначность только если не найдёт способа разрешить неоднозначность самостоятельно.

А в Си overloading-а нет, поэтому грабли будут заботливо расставлены очень часто. В этом проблема.

Но вообще да, непонятно зачем эти неймспейсы в С. Перегрузка операторов, например, была бы полезнее

Вот да. Без общих правил перегрузки (операторов/имён) неймспейсы не имеют смысла, т.к. поиск имени в namespace — это частный случай разрешения перегруженного имени.

А нужен ли overloading в Си — отдельный большой вопрос. Неоднозначный, имхо.

Не, я ООП в C не хочу. Просто C++ огромен и не особо то хорош в целом. Это куча отличных и просто хороших идей, которые вместе дают не особо хороший результат. Это как смешать арбуз, жаренные грибы и молоко: по отдельности вкусно, а вместе... Брр.

Если нужны namespace в С - пиши на С++ без классов, шаблонов и прочего, но с namespace, кто мешает?

1. Qt != C++

2. Посмотри на QT_BEGIN_NAMESPACE, QT_END_NAMESPACE

То что я могу писать на плюсах без того или иного функционала и так понятно. Вопрос в том, почему фича, которая не требует особого труда в реализации (реализована в родственном языке, на который и так обращают внимание при создании стандартов) не была включена в Си.

не требует особого труда в реализации

На самом деле, требует редизайна языка. (А иначе получится «арбуз, жаренные грибы и молоко».) См. мой предыдущий коммент про overloading.

Так ты не хочешь, другой хочет. Одному неймспейсы подавай, другому хочется все эти кишки объектов на подобии gobject и прочих подходов спрятать, то есть таки наворотить хотя бы простенькое ООП. Третьему конечно же нужны шаблоны, потому что макросы это ой как плохо.

В итоге из языка, реализация которого пишется конечно не так просто как для форта, но достаточно просто и почти для любой платформы мы получаем язык, который как и С++ хрен куда портируешь, особенно без ОС и при портировании возникают всякие пожелания: не используй это, не используй то и тд.

Хм, не особо. Многие фичи добавляются в современные языки вроде С++ и Java без редизайна, а наоборот с максимальной оглядкой на совместимость. Поидее к C даже модули можно прикрутить в стиле Java, просто добавить новое ключевое слово import, которое будет импортировать уже модули, а не заголовочные файлы. Только вот зачем?

Ну, перегрузка функций не так уж полезна, и придется как-то решать вопрос с линковкой и name mangling.

А вот с перегруженными операторами было бы определенно проще.

Для строк можно было бы спрятать все эти strcat/strcpy/strdup за операторы и свысока смотреть на убогий std::string.

SIMD и другой векторно-матричный код тоже можно было бы упростить. Меня эти интринсики слегка угнетают, вместо понятного a = (b + c) * d; приходится писать практически на ассемблере.

Если дать возможность перегрузить оператор взятия индекса, можно получить ассоциативные массивы (и тоже смотреть свысока на std::map/multimap)

Но это так, теоретические рассуждения. Понятно, что никто этого делать не будет. Даже вероятность того что добавят неймспейсы, наверное, повыше

Недавно натыкался, кстати, на перехлёст имён функций. В библиотеке SDL есть массив inputs и тут есть массив inputs.

С namespace'ами не было бы проблем.

Нет, именно использование namespace'ов плюсовых.

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

В крестах неймспейсы — бонус, полученный от введения классов. В няшной все с нуля городить придется, а смысл усложнять компилятор ради мелочи такой? А если нагородят что-то свое, так еще и совместимость с крестами станет еще хуже.

Из-за нэймспейсов придётся придумывать name mangling, а это просто ворох проблем.

без редизайна

Ага, в жабу добавили дженерики, до сих пор плюются. В шарп вон когда добавляют что-то, ломают совместимость.

namespace-ы тоже могут теоретически совпасть. Но вообще это все не такая уж и большая проблема. C динамическими библиотеками (dlopen/dlsym) вообще никаких проблем нет с этими пересечениями

Глобальный using - говнокод.

Как тут уже говорили, придётся вводить манглирование имён, а это порушит вообще всё. Манглирование значительно усложняет работу с языком, хотя при этом является весьма полезным инструментом (при грамотной архитектуре языка можно и без него, но это не про Си).

Кстати, я ошибся по поводу using'ов. Цитирую:

Предположим, что в пространствах имён NS1 и NS2 имеются определения функции myFunction, другие же определенные в них имена не конфликтуют. Тогда следующие директивы

using namespace NS1;
using namespace NS2;

не вызовут конфликта при условии, что в области их действия нет ссылок на функцию myFunction.

Так что да, при наличии одинаковых - будет конфликт.

name mangling

Вот это.

gl::something

В какой символ это скомпилируется? Будет такой же омск, как в крестах, и все равно все будут писать extern C, иначе никто не сможет пользоваться такой библиотекой

Хочется наворотов в Си? Напиши свой фронтенд, в котором просто генерируй Си-код.

Надоедает писать приставка+имя функции иногда.

#include "bar.h"
#define barOftenUsedFunction OftenUsedFunction

int main() {
  barInit();
  OftenUsedFunction();
  barEnd();
}

?

Но тогда это будет уже не Си?..

Тогда это будет Vala! :3 (ну или то, что скармливалось в Cfront)

Ну или можно спросить KivApple, будут ли у него неймспейсы. А то тут или тут с ходу не нашёл ничего про них.

Но тогда это будет уже не Си?

Конечно нет. Но какая разница? Совместимо с Си это всё равно не сделать.

почему в новом стандарте C11 не ввели namespaces

Потому что это уже будет не C.
Хотя, вобщем-то, C11 и так уже не тот ламповый и адекватный C.

Ну дык он хочет в стандарт протолкнуть.

Интересно, почему в новом стандарте C11 не ввели namespaces в Си?

В том числе, потому что с появлением mangling-а нельзя будет так просто взять и найти функцию по имени в разделяемой библиотеке.

SIMD и другой векторно-матричный код тоже можно было бы упростить. Меня эти интринсики слегка угнетают, вместо понятного a = (b + c) * d; приходится писать практически на ассемблере.

google: gcc vector extension

gcc vector extension

А эти расширения покрывают все инструкции? Можно ими сделать что-то типа a = abs(b) + c;, например? У меня вот так не получилось, и не нагугливается как правильно. Ну, в идеале хотелось бы все-таки иметь возможность самому чего-нибудь перегрузить

я подозреваю, это может поломать ABI и экспортируемые имена символов