Ну, выкладывай, что у тебя там...
N_>А я тебя уверяю, что я ничего не напутал.
N_>То-есть аргументированно возразить уже не можешь?
Не просто доказывать подобные банальности. Да и не очень разумно. Я тебе уже говорил погугли по этому поводу. Например, так синтаксическим разбором называется.
Лучше уж ты даказывай свои гипотизы.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Массив не инициализирован и превышает размеры стэка.
А где сказано, что это Win32?
VD>Дык, ты результат верни и погляди что получится. А так он просто выбрасил с дури код и все.
А зачем? Разговор шел про конкретно ЭТУ программу.
VD>Думаю, что смысла в таком коде еще мешьше чем в заявлениях сделанных на его основе.
Про код согласен, а о заявлениях огласите весь список, пожалуйста! (что-то я не припомню никаких заявлений...)
VD>О! Умища палата. Вот только достаточно переменную в классик вынести или малейшие зачатки разума в алгоритм заложить и вся прыть компилятора куда-то улитучивается.
А нет никаких "если". Я говорил про конкретно ЭТУ программу и все!
VD>Вот именно по этому синтетические тесты не имеют смысла. У тебя даже заведомо бессмысленный код скомпилируется. А на рельныйкод это ровным счетом никакого влияние не окажет. Дак я это и хотел сказать!
Я привел эти тесты как раз для того, чтобы продемонстрировать бессмысленность бенчмарков на тривиальных задачах, когда у компиля
тора имеется возможность "жульничать". Пожалуйста, читай внимательнее мои посты...
Здравствуйте, Nick_, Вы писали:
N_>В такой обстановке, когда пиписьками машут, как-то уже не хочется...
Ну, ты давай на разные органы то не сваливай. Сморозил фигню... с кем не бывает. Скажи: "ишибся, извни". А то сразу на чужие органы ссылки.
Если серьезно, то какой ты еще хотел реакции на слова "Почитай на досуге грамматику С++ или С." человеку который последние пол года только этой темой и занимался?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если серьезно, то какой ты еще хотел реакции на слова "Почитай на досуге грамматику С++ или С." человеку который последние пол года только этой темой и занимался?
OK. Обьясняю еще раз. на этот раз разжовываю как совсем чайнику.
Берем стандарт С++. Читаем Appendix A: Grammar summary
Компилятор разбирает выражение (hello.... перед ним стоит открывающая скобка.
Дальше он может идти по одному из двух путей
Если hello — тип:
expression->...->cast-expression->(->type-id->...->type-name->hello.
Если hello — идентификатор(переменная):
expression->...->cast-expression->...->primary-expression->(->expression->...->id-expression->hello.
Ну и как определить по какому пути делать синтаксический разбор, не зная hello тип или не тип?
Еще в качестве примера могу привести приоритет операций. То, что умножение имеет более высокий приоритет чем сложение выясняется уже на этапе синтаксического анализа, а не семантического.
Здравствуйте, Nick_, Вы писали:
N_>OK. Обьясняю еще раз. на этот раз разжовываю как совсем чайнику. N_>Берем стандарт С++. Читаем Appendix A: Grammar summary
N_>Компилятор разбирает выражение (hello.... перед ним стоит открывающая скобка.
Ну, это 100%-ный вызов функции.
N_>Дальше он может идти по одному из двух путей
N_>Если hello — тип: N_>expression->...->cast-expression->(->type-id->...->type-name->hello. N_>Если hello — идентификатор(переменная): N_>expression->...->cast-expression->...->primary-expression->(->expression->...->id-expression->hello.
Ты наверно имешь в виду двусмысленность в трактовании выражения в скобках идущее перед идентификатором или другими скобками.
Дык тут в станадрте должно быть написано, что имеет место двусмысленность (ambiguities). Под рукой плюсового стандарта нет, так что точную формулировку привести не могу.
Так вот, чтобы разрешить эту двусмысленность компилятору нужно провести семантический анализ и определить является ли выражение в скобках типом или нет. Ситуация вроде "(Type)id" решается и без анализа. Но "(Type)-id" уже двусмысленна.
Это нормально. И не в коем случае не противоречит моим словам. Синтаксический разбор при этом остается синтаксическим рабзбором, а семантический анализ — семантическим анализом который проходит исключительно после стадии синтаксического разбора (иначе как собственно установить, был ли вообще объевлян Type?). Просто С++ довольно древний язык и в нем используемый тип обязан быть объявлен (продекларирован) до его использования. В C#, например, все намного сложнее. В нем тип не обязан быть объявлен до использования. По этому для начала семантического анализа требуется полностью закончить стадию синтаксического разбора. Именно по этому в C# данная неодназначность (к сожалению повзаимствованная из С++) решается более топорно. В C# введены эвристические правила позволяющие трактовать выражение в скобках как приведение типов:
The grammar for a cast-expression leads to certain syntactic ambiguities. [Example: The expression (x)–y could either be interpreted as a cast-expression (a cast of –y to type x) or as an additive- ression combined with a parenthesized-expression (which computes the value x – y). end example] To resolve cast-expression ambiguities, the following rule exists: A sequence of one or more tokens (§9.4) sed in parentheses is considered the start of a cast-expression only if at least one of the following are true:
• The sequence of tokens is correct grammar for a type, but not for an expression.
• The sequence of tokens is correct grammar for a type, and the token immediately following the closing
parentheses is the token “~”, the token “!”, the token “(”, an identifier (§9.4.1), a literal (§9.4.4), or any 13
keyword (§9.4.3) except as and is.
The term “correct grammar” above means only that the sequence of tokens shall conform to the rticular grammatical production. It specifically does not consider the actual meaning of any ituent identifiers. [Example: If x and y are identifiers, then x.y is correct grammar for a type, even if x.y doesn’t actually denote a type. end example]
[Note: From the disambiguation rule, it follows that, if x and y are identifiers, (x)y, (x)(y), and (-y) are cast-expressions, but (x)-y is not, even if x identifies a type. However, if x is a keyword identifies a predefined type (such as int), then all four forms are cast-expressions (because such a
N_>Ну и как определить по какому пути делать синтаксический разбор, не зная hello тип или не тип?
Только проведением семантического анализа. Но он может быть проведен только для части кода разобранной с помощью синтаксического разбора.
N_>Еще в качестве примера могу привести приоритет операций. N_> То, что умножение имеет более высокий приоритет чем сложение выясняется уже на этапе синтаксического анализа, а не семантического.
Это выясняется на этапе составления граматики языка. А парсер всего лишь отражает спецификацию. К семантике приоритеты не имеют ни малейшего отношения.
N_>После того как я тебе еще раз попытался разжевать, может ты потрудишься обьяснить что ты имел в виду в N_>сообщении http://rsdn.ru/Forum/Message.aspx?mid=840770&only=1
когда заявил, что "Да пофигу для синтаксического разбора чем будет эта конструкция. Тип, не тип — это уже семантика."
В приведенном тобой примере никакой двусмысленности нет и семантический анализ не трелуется. Из контекста четко видно, чем должен быть идентификатор. Так что код будет спокойно распарсен в АСТ и кога пойдет воплощение шаблона просто будет проверено, что данный идинтификатор действительно существует и является типом. А для разрешения неоднозначностей как раз и был введен typename.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Nick_, Вы писали:
N_>>OK. Обьясняю еще раз. на этот раз разжовываю как совсем чайнику. N_>>Берем стандарт С++. Читаем Appendix A: Grammar summary
N_>>Компилятор разбирает выражение (hello.... перед ним стоит открывающая скобка.
VD>Ну, это 100%-ный вызов функции.
Ты бредишь?
N_>>Дальше он может идти по одному из двух путей
N_>>Если hello — тип: N_>>expression->...->cast-expression->(->type-id->...->type-name->hello. N_>>Если hello — идентификатор(переменная): N_>>expression->...->cast-expression->...->primary-expression->(->expression->...->id-expression->hello.
VD>Ты наверно имешь в виду двусмысленность в трактовании выражения в скобках идущее перед идентификатором или другими скобками.
Это как? Выражение в скобках (exp) идущее перед идентификатором или другими скобками...
(expr)id или (expr)(...
Слушай, я об одном, а ты о другом. Попробуй еще раз почитать что я написал.
Я о двусмысленности трактования идентификатора в скобках, при разборе выражения.
(hello)...
Это может быть либо c-style-cast либо переменная в скобках.
VD>Дык тут в станадрте должно быть написано, что имеет место двусмысленность (ambiguities). Под рукой плюсового стандарта нет, так что точную формулировку привести не могу.
Найди и почитай стандарт. Никакой двусмысленности нет, если компилятор знает, что тип а что не тип.
VD>Так вот, чтобы разрешить эту двусмысленность компилятору нужно провести семантический анализ и определить является ли выражение в скобках типом или нет. Ситуация вроде "(Type)id" решается и без анализа. Но "(Type)-id" уже двусмысленна.
О том я и говорю. Так вот в шаблоне, компилятор не может определить тип или не тип стоит в скобках.
Я уже приводил пример с (T::x)+1; Поэтому компилятор не может сделать синтаксический разбор. А семантический разбор может быть проведен только при инстанциации. Никакие эвристики тут не помогут. Некоторые компиляторы С++ стоят AST в предположении что T::x это переменная, а потом выкидывают эти результаты и парсят заново шаблон при инстанциации. Некоторые вообще не парсят шаблон до инстанциации.
Если не веришь, то можешь попробовать взять сановский компилятор С++ Forte и проверить.
template<class T>
class A
{
this is a test;
};
Скомпилируется без ошибок.
VD>Это нормально. И не в коем случае не противоречит моим словам. Синтаксический разбор при этом остается синтаксическим рабзбором, а семантический анализ — семантическим анализом который проходит исключительно после стадии синтаксического разбора (иначе как собственно установить, был ли вообще объевлян Type?). Просто С++ довольно древний язык и в нем используемый тип обязан быть объявлен (продекларирован) до его использования. В C#, например, все намного сложнее. В нем тип не обязан быть объявлен до использования. По этому для начала семантического анализа требуется полностью закончить стадию синтаксического разбора.
Еще пример:
01 typedef int free;
02 void main()
03 {
04 free(ptr);
05 }
Компилятор не может сделать семантический анализ четвертой строки до синтаксического анализа четвертой строки. Это как ты утверждаешь и я с этим согласен.
Но компилятор не может сделать синтаксический анализ четвертой строки до семантического анализа первой.
Ну не может для такой программы семантический анализ быть "исключительно после" синтаксического.
N_>>Ну и как определить по какому пути делать , не зная hello тип или не тип?
VD>Только проведением семантического анализа. Но он может быть проведен только для части кода разобранной с помощью синтаксического разбора.
Тоесть в одном месте ты пишешь: "семантическим анализом который проходит исключительно после стадии синтаксического разбора", а теперь ты отвечаешь мне, что синтаксический разбор можно сделать только после семантического. "Но он может быть проведен только для части кода разобранной с помощью синтаксического разбора."
Ты похоже не только не читаешь что люди пишут, но и не читаешь что пишешь сам...
N_>>Еще в качестве примера могу привести приоритет операций. N_>> То, что умножение имеет более высокий приоритет чем сложение выясняется уже на этапе синтаксического анализа, а не семантического.
VD>Это выясняется на этапе составления граматики языка. А парсер всего лишь отражает спецификацию. К семантике приоритеты не имеют ни малейшего отношения.
Ну почему же? Кто мешает составить грамматику так, что бы в ней не отражался приоритет операций? Тогда приоритет будет делом семантического анализа. И такие языки есть, в которых можно менять приоритеты операций. Например пролог.
N_>>После того как я тебе еще раз попытался разжевать, может ты потрудишься обьяснить что ты имел в виду в N_>>сообщении http://rsdn.ru/Forum/Message.aspx?mid=840770&only=1
когда заявил, что "Да пофигу для синтаксического разбора чем будет эта конструкция. Тип, не тип — это уже семантика."
VD>В приведенном тобой примере никакой двусмысленности нет и семантический анализ не трелуется. Из контекста четко видно, чем должен быть идентификатор. Так что код будет спокойно распарсен в АСТ и кога пойдет воплощение шаблона просто будет проверено, что данный идинтификатор действительно существует и является типом. А для разрешения неоднозначностей как раз и был введен typename.
В каком из примеров нет двусмысленности? В этом?
template<class T>
class A
{
int x = (T::x)+1;
};
А если пойдет воплощение шаблона, и окажется что идентификатор — не то о чем компилятор подумал при первом проходе?
А вот например, если бы параметров у шаблона было 5, то вариантов разбора было бы 2^5 = 32. Зачем запоминать AST, при первом проходе, а потом проверять при инстанциации, если скорее всего он никогда не понадобится и придется заново делать разбор?
Короче, у меня складывается впечатление, что ты не вникаешь в то, что люди пишут... Попробуй прочитать с чего все началось еще раз и выписать с чем конкретно ты несогласен. А то одному все разжевал, и тут приходит второй и начинается заново.
Здравствуйте, Nick_, Вы писали:
N_>Я о двусмысленности трактования идентификатора в скобках, при разборе выражения. N_>(hello)... N_>Это может быть либо c-style-cast либо переменная в скобках.
Пожобная двусмысленность не может быть обработана на этаме синтаксического анализа, так как на данном этапе происходит разбор выражнния исключительно по КОНТЕКСТНО СВОБОДНОЙ грамматике. А описанная тобой двусмысленность может быть обработана контекстно зависимой грамматикой, а следовательно это может произойти только на этапе семантического анализа.
Здравствуйте, prVovik, Вы писали:
V>Пожобная двусмысленность не может быть обработана на этаме синтаксического анализа, так как на данном этапе происходит разбор выражнния исключительно по КОНТЕКСТНО СВОБОДНОЙ грамматике. А описанная тобой двусмысленность может быть обработана контекстно зависимой грамматикой, а следовательно это может произойти только на этапе семантического анализа.
Грамматика Си — контекстно зависима. То, что Си парсится LL парсером ничего не говорит, потому что это не честный LL или LR парсер. при чтении символа лексическим анализатором проверяется, является ли этот символ типом. А синтаксический анализатор заносит новые типы определенные c gjvjom. ензувуа в таблицу типов, которой пользуется лексический анализатор.
Такая обратная связь выходит за рамки LL разбора и позволяет разобрать контекстно зависимую грамматику языка Си.
Еще раз приведу пример:
int main()
{
free(ptr); // это вызов функции или определение переменной?
}
Для вызова функции и определения переменной используются разные синтаксические конструкции.
И в данном случае, это зависит от контекста: встретилось ли ранее typedef int free;
Я нет. А ты вот хамишь.
VD>>Дык тут в станадрте должно быть написано, что имеет место двусмысленность (ambiguities). Под рукой плюсового стандарта нет, так что точную формулировку привести не могу. N_>Найди и почитай стандарт. Никакой двусмысленности нет, если компилятор знает, что тип а что не тип.
Даже не собираюсь искать. Компилятор не одущевленное существо, чтобы что-то знать. Есть конфликт граматики (двусмысленность) которая разрешается семантическими средствами. И это совсем другой случай.
N_>О том я и говорю. Так вот в шаблоне, компилятор не может определить тип или не тип стоит в скобках. N_>Я уже приводил пример с (T::x)+1; Поэтому компилятор не может сделать синтаксический разбор.
Для решения пдобных двусмысленностей и существует typename. В приведенном же тобой тогда примере никаких двусмысленностей нет. И компилятор может сделать четкий вывод.
N_>Если не веришь, то можешь попробовать взять сановский компилятор С++ Forte и проверить. N_>template<class T> N_>class A N_>{ N_> this is a test; N_>}; N_>Скомпилируется без ошибок.
Каким-то компилятором без ошибок. А каким-то и с ошибками. Согласен, что контрольк производится во многих случаях поздновато. Но в этом есть дополнительная гибкость.
Кстати, вот именно этот тест показывает, что тот же VC разбор делает:
То есть подобные ситуации распарсиваются им, но не в конкретные, в более общие АСТ-структуры. Ну, а окончательный семантический контроль проводится уже на стадии воплощения шаблона.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Каким-то компилятором без ошибок. А каким-то и с ошибками. Согласен, что контрольк производится во многих случаях поздновато. Но в этом есть дополнительная гибкость.
VD>Кстати, вот именно этот тест показывает, что тот же VC разбор делает: VD>
VD>То есть подобные ситуации распарсиваются им, но не в конкретные, в более общие АСТ-структуры. Ну, а окончательный семантический контроль проводится уже на стадии воплощения шаблона.
Об этом и речь, что окончательный разбор шаблона делается уже при инстанциации.
Обсуждать остальные разногласия я считаю уже бессмысленым делом.
Здравствуйте, Nick_, Вы писали:
N_>Сначала программа переводится в SSA форму, над которой потом делаются оптимизации. N_>Так вот сюрпиз! SSA форма — это функциональная программа N_>http://citeseer.ist.psu.edu/appel98ssa.html
Для подобных оптимизаций достаточно АСТ. Где ты взял что МС использует именно этот SSA?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nick_, Вы писали:
N_>Просто так оптимизации в компиляторы не вставляют. Для любой оптимизации надо сначала доказать, что она не меняет семантику кода.
К сожалению в том же VC часто можно встретить оптимизации таки меняющие семантику и способные вызвать проблемы. Ну, да к ФЯ изменение семантики вряд ли имеет прямое отношение.
N_> А для этого в свою очередь нужен способ, который бы позволил сказать, что два разных алгоритма делают одно и то же. В общем случае, эта задача алгоритмически неразрешима. Но для более узких типов эквивалентности алгоритмов это можно сделать. Кроме того алгоритм должет быть как-то записан. Для некоторых форм записи провести доказательство правильности оптимизации проще чем для других. SSA — это уже де-факто стандартная форма записи алгоритмов. Большинство доказательств корректности оптимизаций делается для оптимизайций SSA формы. В большинстве современных компиляторов используется SSA форма, как внутреннее представление программы.
N_>PS: Ну а gcc для меня не авторитет.
А как на счет байткода Явы, МСИЛ-а дотнета, промежуточного кода Фекниса? Они вроде к этому SSA отношения не имеют. Но тем не менее оптимизации поддаются в лучшем виде. Те же джиты делают кучу оптимизаций при генерации исполняемого кода.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nick_, Вы писали:
N_>Еще раз приведу пример:
N_>int main() N_>{ N_> free(ptr); // это вызов функции или определение переменной? N_>}
Это вообще безконфликтый случай. Это никак не может быть определением переменной. Тут конфликта нет. А вот в приведении типов конфликт действительно есть, и без привлечения семантического анализа определить конкретный тип конструкции нельзя.
N_>Для вызова функции и определения переменной используются разные синтаксические конструкции. N_>И в данном случае, это зависит от контекста: встретилось ли ранее typedef int free;
В данном случае ничего повлиять уже не может. Приведи, плиз, пример где бы твоя конструкция была бы корректно распознана парсером как объявление переменной.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nick_, Вы писали:
N_>Об этом и речь, что окончательный разбор шаблона делается уже при инстанциации. N_>Обсуждать остальные разногласия я считаю уже бессмысленым делом.
Ты утверждал, что разбор вообще не делается.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nick_, Вы писали:
N_>В каком из примеров нет двусмысленности? В этом? N_>template<class T> N_>class A N_>{ N_> int x = (T::x)+1; N_>}; N_>А если пойдет воплощение шаблона, и окажется что идентификатор — не то о чем компилятор подумал при первом проходе?
Ты бы пошол станларт почитал чтоли.
14.6/2
A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword typename.
14.6/3
A qualified-name that refers to a type and that depends on a template-parameter (14.6.2) shall be prefixed by the keyword typename to indicate that the qualified-name denotes a type, forming an elaborated-type-specifier (7.1.5.3).
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eugals, Вы писали:
E>Здравствуйте, FR, Вы писали:
FR>>Питон (c psyco) не может упереся в память, плохие у него массивы(вернее их и нету вовсе) E>см. module array
Здравствуйте, VladD2, Вы писали:
N_>>Еще раз приведу пример:
N_>>int main() N_>>{ N_>> free(ptr); // это вызов функции или определение переменной? N_>>}
VD>Это вообще безконфликтый случай. Это никак не может быть определением переменной. Тут конфликта нет. А вот в приведении типов конфликт действительно есть, и без привлечения семантического анализа определить конкретный тип конструкции нельзя.
N_>>Для вызова функции и определения переменной используются разные синтаксические конструкции. N_>>И в данном случае, это зависит от контекста: встретилось ли ранее typedef int free;
VD>В данном случае ничего повлиять уже не может. Приведи, плиз, пример где бы твоя конструкция была бы корректно распознана парсером как объявление переменной.
Я считаю, что с тобой уже обсуждать что-то бессмысленно. Мало того, что ты Си не знаешь, так еще и не удосужился проверить.
typedef int free;
int main()
{
free(ptr); /* обьявление переменной int ptr */
}
Здравствуйте, WolfHound, Вы писали:
WH>Ты бы пошол станларт почитал чтоли.
Вот не надо придираться к фразам выранным из контекста. Если бы читал о чем была речь ранее, то обратил бы внимание на "...unless the applicable name lookup finds a type name..."
