Re[20]: Опциональные типы
От: fddima  
Дата: 08.03.17 23:46
Оценка:
Здравствуйте, vdimas, Вы писали:

F>>Интересно какие парсеры используются в icc и msvc.

V>Я же сказал, сегодня практически ВСЕ коммерческие компиляторы С, С++, шейдерные диалекты С, встраиваемые диалекты С и С++ — все они пользуют EDG С/C++ front end.
Шейдерные диалекты пожалуйста спусти в унитаз. Там размеры ультракрошечные и никомуненужечные почти
И пальцы этой откровенной херней которая пишеться за неделю в лоб — гнать не надо. EDG же пишет что MS вроде как их юзают в IDE но никак ни в компиляторе. Насчет icc — ещё более пространственные намёки.
Я хер не знаю что такое EDG, И знать не хочу как он устроен, если эти дибилы его сделали на GLR и ты там работаешь — вы сами себе доктор. Если эти дибилы его просто сделали на GLR — то опять дибилы. Пойми, что в современных процах исключительно все data-dependent algorithms — сосут адски по скорости потому что предсказание ветвлений будет обламываться часто. Хотите скорости... изучайте матчасть проца. Т.е. развопачивайте. Что вручную и делают. В конкретных (т.е. целый язык — ситуациях).
Если ты инсайдер EDG и вы используете GLR — тогда давайте результаты. Как ясно из FAQ EDG — оно с трудом годиться для IDE. Мэйнстрим нахер о таком не знает потому что icc и мэйнстрим — это вообще вещи несвязные. Им всё очень очень хочется, но не получается.А то что умеет icc — или умеют и другие — или оно нахер не нужно. Они лучше бы clang развивали а не своей херней якобы на основе EDG страдали.
В общем или обрисуй прямо выкладками или давай примем то, как оно есть — в C++ мэйнстриме пока, что побеждают рукописники RD/LL. Никаких альтернатив тут нет. Причину я уже выше озвучил почему табличники в наиве сосут. Неужели это не было ясно с самого начала?
Тем более одно дело если у нас шарп илиЯва. А C++ с его forced forward declarations — там RD/LL просто делает это.
Вот распрасить тот же шарп — посложнее. Немерле — ещё сложнее. А вот плюсы — в том то и дело что за счёт forward declarations — тривиально.
Где вы там собралисб поменять GLR?!... Исходники главно ж под рукой и gcc и clang. Я перед прршлыми ответами — внимательно поизучал clang на неучтенный случай. Ну хватит. 1.5мб с++ — это много. Но подъемно. Более того — кол реально простой. На то он и рукописник.
Тут раньше фронт msvc исчезнет как таковой. А ты рассуждаешь как реально работаншь в своём EDG.

Ток без обид. Объяснись нормально и народ потянеться. Но херню не говори — GLR не может быстрее работать. У него худший что лучший случаи если по честному делать — дороги однаково. Классический просто порождает херову ненужную тучу (ага, а всё равно не бесплатную) вариантов. Статьи наглядно показывают соотношения вариантов и единственного правильного пути. 1/30К по сути. Гуляйте и пользуясь местной терминологией — принудительно отстранить от программирования и отдать на лечение. Вот и всё.

WH, в отличие от тебя хоть как-то пытается аргументировать. Ты же аппплируешь к вещам никому неизвестным. Тот же EDG. Аппелировать к чёрному ящику — это неспортивно. Во-вторых — в коммерческих продуктах как ты говоришь "ВСЕХ" оно точно не используется. Мда. Шейдерные языки. Посмеши нас ещё раз пожалуйста. Шейдерные языки или мегабайты парсинга.

Ты то в целом прав. Как и WH в целом прав. Но завираться — точно не надо. Я легко читаю и приемлю твои свободные определения некотоых вещей. Но странно — от других ты резко требуешь классику. С чего бы. Короче — надоели.

Вот VD2 vs WH — это круто. Тож спорят ниочём. Но хотя б пластинка была новая.

Я эт к чему. Не потому что умный. Наоборот. Хочу новых страстей почитать.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.