Кто что думает?

← →
Vga © (2007-06-06 21:43) [400]

> defunct © (06.06.07 18:18) [398]

Знание автором статьи по ссылке языка Delphi (в вступлении сказано. что в качестве Pascal рассматривается Delphi) вызывает сомнения.

← →
defunct © (2007-06-06 21:50) [401]

Vga © (06.06.07 21:43) [400]

Ну так в интернете есть другие ресурсы со статьями где можно взять более достоверные данные. Эта статья - первое что мне попалось при поиске в гугле по фразе "Раздельная компиляция". Привел ее просто чтобы показать уважаемому Однокамушкину, как обстоят дела с раздельной компиляцией в C/C++. А то его просто понесло..

Я бегло прочитал эту статью, вроде бы в ней все ок, может быть - немного устаревшие данные, но серьезных сомнений она не вызывает. (по крайней мере у меня)

← →
Vga © (2007-06-06 22:04) [402]

Явно неверны (AFAIK естественно) таблицы G, H, I для Delphi (в статье под именем Pascal). Вызывает сомнения таблица F. Более ранние таблицы тоже вызывали сомнения, но я их не запоминал.

← →
Однокамушкин (2007-06-06 22:10) [403]

> defunct © (06.06.07 18:18) [398]
> в коменте [379] - доказано, что препроцессор в Delphi есть.

Не доказано, там используются {$DEFINE} и {$IFDEF}, которые во всех источниках называются директивами компилятора...

> я привел ссылку где сравнивается раздельная компиляция в
> различных языках. Паскаль набрал там 6 очков, C++ - 8 очков,
> C - 5.

Посмотрел, с оценками не согласен:

1. По пункту "Раздел интерфейса модуля" паскаль получил одно очко, C и C++ два... видимо, имеется ввиду то, что в паскале interface и implementation находятся в одном файле, а в С всё строго: интерфейс в h-файле, реализация - в c- или cpp-файле... только это существует на уровне устных договорённостей, а так - ничего не мешает в h-файл вставить реализацию, а в #include написать cpp-файл... так что разделение модуля на интерфейсную и содержательную часть в C/С++ существует только до тех пор, пока программист согласен её соблюдать, а Паскаль программиста к этому обязывает, так что имхо у Паскаля по этому пункту оценка правильная, а С и С++ не заслуживают ни одного очка...

2. По пункту "Импорт модулей" не понял, почему С не получил ни одного очка, а С++ - одно... в чём между ними разница? сколько видел кода на С++, нигде ничего, кроме include, не встречал...

3. По пункту "Ограничения видимости" С++ получил одно очко, Паскаль - 0... видимо, имеется ввиду, что в интерфейсной части в C++ можно объявить, скажем, тип, который будет использоваться только приватными полями какого-то класса и не будет виден импортирующему модулю, а в паскале такого сделать нельзя... да, согласен, но есть и обратная сторона медали: в Паскале можно распространять один только dcu-файл, и тогда, например, о приватных членах класса извне узнать будет обычными методами невозможно, а в С++ достаточно просто открыть h-файл... так что по этому пункту очков должно быть поровну...

4. По пункту "Настраиваемые модули"... из пояснений ясно, что имеются ввиду шаблоны или обоббщения... тут мне сложно судить, потому что я не знаю, что делает компилятор С++ с шаблонами, в каком виде он запихивает их в obj-файл... Знаю только, что до конца их, откомпилировать, естественно, нельзя, а единственная известная мне теоретическая работа по частичной компиляции такой конструкции (я имею ввиду деревья Франца) появилась позже, чем С++, так что деревьев Франца там быть не может... так что шаблоны - это, конечно, удобно, но какое отношение они имеют к раздельной компиляции - не понимаю...

А вообще, профессионализм авторов этого сравнения вызывает большие вопросы... в пункте G Паскаль получил 0 очков за полиморфизм - это что, правда, что в Паскале нет полиморфизма? И это при наличии виртуальных конструкторов, обеспечивающих полиморфизм даже при создании объекта...

В пункте H Паскаль получил ноль за наличие исключений... а как же тогда try/except? да ещё и try/finally, которого мне всегда в C++ не хватало? Я уж думал, что речь идёт о каком-то другом диалекте Паскаля, но нет - для PASCAL использовалась реализация языка в компиляторах фирмы Borland (Objective Pascal системы Delphi)...

В пункте B С и С++ получили больше очков, чем остальные языки, за цикл for... ну да, он гибче, хотя из-за этого хуже оптимизируется... там же Паскаль, С и С++ получили по два очка за оператор break, а Ада - только одно, хотя в Аде break гибче - он позволяет выходить сразу из нескольких вложенных циклов... за блок опреаторов Паскаль не получил ни одного очка, хотя чем begin-end не блок - непонятно... к тому же отсутствие блоков, например, в Обероне относится к достоинствам языка, что авторы теста косвенно признали, подняв баллы за наличие elseif и endif в оценке оператора if... printf и WriteLn являются не операторами вывода, а стандартными процедурами (функциями) вывода... оператора new в Паскале нет, есть функция New, менее гибкая, кстати, чем в C, потому что нет аналога new[]...

В пункте C Паскаль не получил очков за неограниченный массив в параметрах функций, хотя открытые массивы есть со времён TP7... необязательные параметры тоже есть, хотя появились, если не ошибаюсь, только в пятёрке, возможно, этот рейтинг просто старый... хотя нет, очки за перегрузку процедур там у Паскаля есть, а она точно появилась не раньше, чем необязательные параметры... а вот откуда у Паскаля очко за inline-функции, тоже надо спросить у авторов...

В пункте D Паскаль получил только одно очко за скалярный тип и отрезок, а С и С++ по два... в то время как аналога паскалевского типа-диапазона в этих языках я что-то не припомню, а вот возможность назначать свои значения константам скалярного типа тоже уже есть, правда, я это достоинством не считаю... массив с переменной границей в Паскале тоже давно есть, и тоже появился не позже, чем перегрузка процедур, причём динамические массивы имхо удобнее массивов с переменной границей в С и С++... почему Оберон и Паскаль получили поровну за множество, я тоже не понимаю, в Обероне Вирт решил существенно упростить этот тип, так что обероновский SET - это аналог паскалевского set of 0..31, а других множеств в Обероне нет...

В пункте E Паскаль наравне с C и C++ не получил ни одного очка за контроль границ индекса массива, хотя в Паскале этот контроль можно включить, а в С и это невозможно...

В общем, это не тот рейтинг, которому можно доверять... думаю, что если бы я знал лучше Джаву, Модулу и Аду, нашёл бы ещё ошибки...

← →
Vga © (2007-06-06 22:17) [404]

> Однокамушкин (06.06.07 22:10) [403]

+1. Но по Модуле-2 - врядли, этот язык автор похоже знает лучше всех. В том числе и упоминаемый "Странник" представляет собой компилятор Модулы-2, Модулы-2 с синтаксисом С и Модулы-2 с синтаксисом Паскаля, написан ессно на Модуле-2 и компилится сам собой.

← →
Anatoly Podgoretsky © (2007-06-06 22:23) [405]

> Однокамушкин (06.06.2007 22:10:43) [403]

> в Обероне Вирт решил существенно упростить этот тип, так что обероновский SET - это аналог паскалевского set of 0..31, а других множеств в Обероне нет...

Как он посмел, а еще математик

← →
Vga © (2007-06-06 22:24) [406]

Ни паскалевые, ни сишные исходники, не предназначенные специально для "Страника" (я считаю, такое название больше подходит - это пираты удачно опечатались) на нем не компилируются.

← →
Vga © (2007-06-06 22:26) [407]

Вообще "Страник" напоминает ситуацию с языками на .NET на данный момент - языки, не являющиеся С# не реализуют полную функциональность ни .NET, ни самих себя.

← →
Однокамушкин (2007-06-06 22:28) [408]

> Anatoly Podgoretsky © (06.06.07 22:23) [405]
> Как он посмел, а еще математик

А разве Вирт математик? Насколько я помню, он закончил факультет электротехники...
http://www.inr.ac.ru/~info21/wirth/wirth_avia.htm

← →
Vga © (2007-06-06 22:43) [409]

> Однокамушкин (06.06.07 22:28) [408]
> > Anatoly Podgoretsky © (06.06.07 22:23) [405] > Как он
> посмел, а еще математикА разве Вирт математик? Насколько
> я помню, он закончил факультет электротехники...http://www.
> inr.ac.ru/~info21/wirth/wirth_avia.htm

Круто. Жаль, о выступлении Вирта в нашем универе я узнал постфактум :(

← →
Defunct © (2007-06-06 23:54) [410]

> Не доказано, там используются {$DEFINE} и {$IFDEF}, которые во всех
> источниках называются директивами компилятора...

http://en.wikipedia.org/wiki/Preprocessor

остальное в ответе на письмо

← →
Однокамушкин (2007-06-07 07:09) [411]

Чтобы окончательно лично для себя решить вопрос с препроцессором в Delphi, провёл эксперимент - написал такой вот код:

procedure TForm1.Button1Click(Sender: TObject); var a: Integer; begin a := 10; if a{$IF Less}<{$ELSE}>{$IFEND}=20 then ShowMessage("Yes") else ShowMessage("No"); end;

Суть в том, что спорная директива разбивает на части лексему... код не компилируется, компилятор останавливается на символе "=" и пишет "Expression expected but "=" found"... если выкинуть символ "=", всё компилируется... отсюда вывод: директивы компилятора можно вставлять в любом месте между лексемами, но нельзя разбивать ими лексему на части...

Если бы в Delphi был настоящий препроцессор, который, соласно определению, обрабатывает текст перед компилятором, ему было бы всё равно, разбиваются лексемы на части или нет... компилятору тоже было бы всё равно, потому что на входе он получал бы код, в котором лексема была бы слита... возникновение в данной ситуации ошибки означает одно: директивы компилятора обрабатываются лексическим анализатором, а лексический анализатор - это часть компилятора, а не то, что выполняется до компилятора, так что препроцессора в дельфях всё же нет...

И ещё одна аналогия в голову пришла... тут в соседней ветке недавно выкладывались ссылки на статьи о том, насколько плохо наши интуитивные представления подходят для понимания основ классической механики... из людей приходится буквально выбивать интуитивные представления, чтобы они всё-таки смогли понять, как же будет двигаться тело... Имхо, то же самое и с программированием: наши интуитивные представления очень плохо походят для написания надёжных программ, из людей надо выбивать сконность к трюкачеству и заставлять писать нормальный код... и Паскаль лучше С в этом отношении, потому что на С можно писать и так и этак, а Паскаль всё-таки подталкивает от инстинктов к стргости, и в этом его достоинство...

И ещё одна мысль, которая пришла в голову... много раз от разных людей я слышал примерно такие слова: "Я ...дцать лет занимаюсь программировнием, за это время мне ни разу не понадобилось использовать goto, но если вдруг понадобится, я сделаю это не задумываясь, и никакая теория меня не переубедит"... причём во всех случаях это говорили программисты, чья квалификация не вызывала у меня сомнений - например, однажды я услышал такое от заслуженно уважаемого здесь Юрия Зотова... И меня это всегда удивляло, на мой взгляд, цепочка рассуждений должна быть совсем другая: я знаю, что есть теоретическое обоснование ненужности goto и ...дцать лет на практике я получал подтверждение того, что оно действительно не нужно, и если я столкнусь с ситуацией, когда мне захочется применить goto, то я остановлюсь и крепко подумаю, не сделал ли я где-то серьёзной ошибки... вот и в С очень много таких конструкций, что если возникает желание их применить, то нужно искать ошибку, а такие конструкции в языке имхо не нужны...

← →
C+- (2007-06-07 09:45) [412]

А можно вопрос?

int some(int a){return a+5;}

int b=3;
int c=some(b++);

Чему будет равно с?

← →
Bless © (2007-06-07 10:14) [413]

> Чему будет равно с?

Восьми. А в чем подвох?

← →
C+- (2007-06-07 10:25) [414]

>>>Bless © (07.06.07 10:14) [413]

А подвоха нет. Только правильный ответ - "8 или 9, смотря чем компилировать"

← →
tesseract © (2007-06-07 10:39) [415]

> Если бы в Delphi был настоящий препроцессор, который, соласно
> определению, обрабатывает текст перед компилятором,

Borland всегда гордился однопроходным компилятором pascal.

← →
Bless © (2007-06-07 10:42) [416]

> C+- (07.06.07 10:25) [414]
> Только правильный ответ - "8 или 9, смотря чем компилировать"

А чем компилировать, чтоб получить 9?

← →
tesseract © (2007-06-07 10:45) [417]

> А чем компилировать, чтоб получить 9?

Watcomm попробуй.

← →
Bless © (2007-06-07 10:45) [418]

Это я так деликатно выражаю сомнение в том, что "c" может равняться 9 вообще :) На мой взгляд, как раз в этом примере нет неоднозначностей.

← →
palva © (2007-06-07 10:52) [419]

> Watcomm попробуй.
А разве есть такой компилятор? Это я так деликатно выражаю сомнение в том, что название компилятора написано правильно.

← →
Bless © (2007-06-07 11:08) [420]

> tesseract © (07.06.07 10:45) [417]
>
> Watcomm попробуй.

Мне напряжно качать десятки мегабайт (Open Watcom), чтоб просто попробовать. Готов поверить на слово. Проверял? Дает 9?
А еще лучше объясни словами, с какой стати пример в принципе может давать 9? Операция постинкремента подразумевает увеличение аргумента ПОСЛЕ подстановки его в выражение. В данном случае выражение примитивно и не допускает разночтений. Разве нет?

← →
Bless © (2007-06-07 11:08) [421]

> tesseract © (07.06.07 10:45) [417]
>
> Watcomm попробуй.

Мне напряжно качать десятки мегабайт (Open Watcom), чтоб просто попробовать. Готов поверить на слово. Проверял? Дает 9?
А еще лучше объясни, с какой стати пример в принципе может давать 9? Операция постинкремента подразумевает увеличение аргумента ПОСЛЕ подстановки его в выражение. В данном случае выражение примитивно и, имхо, не допускает разночтений. Разве нет?

← →
Bless © (2007-06-07 11:10) [422]

Прошу прощения за дубль

← →
C+- (2007-06-07 12:03) [423]

А так скока будет?

int some(int a,b){return a/b;}
int a=1;
int c=some(a++,a++);

← →
Vendict © (2007-06-07 12:17) [424]

здесь по-моему в любом случае 1ца

← →
C+- (2007-06-07 12:26) [425]

>здесь по-моему в любом случае 1ца

Ага, тока наоборот. Все кроме 1.

← →
clickmaker © (2007-06-07 12:28) [426]

> [423] C+- (07.06.07 12:03)

calling convention?

← →
Bless © (2007-06-07 12:29) [427]

> C+- (07.06.07 12:03) [423]
>
> А так скока будет?

Вот так по-разному :)

← →
Evgeny V © (2007-06-07 13:02) [428]

C+- (07.06.07 12:26) [425] Пример интересный:-)
А скомплировать под VS 2005 c поддержкой CLR??:-)))

← →
_Слоник (2007-06-07 13:43) [429]

> C+- (07.06.07 12:03) [423]
> А так скока будет?
> int some(int a,b){return a/b;}
> int a=1;
> int c=some(a++,a++);

не помню как в с++ проходит пребразование к флоату, скорее всего будет 0 (результат точно 0.5). т.е. если бы в функции было b/a, то ответ 2.

> Однокамушкин (07.06.07 07:09) [411]
Если бы в Delphi был настоящий препроцессор, который, соласно определению, обрабатывает текст перед компилятором, ему было бы всё равно, разбиваются лексемы на части или нет... компилятору тоже было бы всё равно, потому что на входе он получал бы код, в котором лексема была бы слита... возникновение в данной ситуации ошибки означает одно: директивы компилятора обрабатываются лексическим анализатором, а лексический анализатор - это часть компилятора, а не то, что выполняется до компилятора, так что препроцессора в дельфях всё же нет...

Я же ж сразу сказал что он немного кастрированный.
Но теперь то вы согласны, что он есть?

> C+- (07.06.07 10:25) [414]
>> int some(int a){return a+5;}

>> int b=3;
>> int c=some(b++);

>> Чему будет равно с?
> А подвоха нет. Только правильный ответ - "8 или 9,
> смотря чем компилировать"

Неправда ваша. Здесь однозначный ответ 8.

А пример с неоднозначностью может быть например таким:
int i; int x; i = 5; x = ++i + ++i;

← →
Однокамушкин (2007-06-08 09:33) [432]

> tesseract © (07.06.07 10:39) [415]
> Borland всегда гордился однопроходным компилятором pascal.

Однопроходность не отменяет деления на подзадачи... например, лексический, синтаксический и семнатический анализаторы в однопроходном компиляторе всё равно разделены, просто работают пошагово по очереди...

← →
Однокамушкин (2007-06-08 10:28) [433]

> defunct © (07.06.07 16:35) [430]
> Я же ж сразу сказал что он немного кастрированный.
> Но теперь то вы согласны, что он есть?

Нет, не согласен... просто в Delphi часть той функциональности, которая в С реализуется препроцессором, берёт на себя лексический анализатор, а это не совсем одно и то же, и в тонких сулчаях разницу можно заметить... а сам факт наличия такой функциональности я никогда не отрицал, я эти директивы ещё в Турбо Паскале использовал...

Также я по-прежнему не согласен, что в С есть раздельная компиляция... Поймите меня правильно, я не отрицаю, что С и С++ умеют перекомпилировать только часть исходников, а не весь проект, и даже согласен с тем, что в большинстве случаев умеет правильно определять, какая именно часть исходников должна быть перекомпилирована... не согласен я с тем, что этого достаточно, чтобы называть компиляцию раздельной, она не раздельная, она независимая, хотя и более совершенная, чем незавивимая компиляция в Фортране... К сожалению, эти понятия действительно часто путают...

И, если позволите, немного философии... Фундаментальное образование в области программирования у нас большая редкость, большинство программистов в той или иной степени самоучки... очень способные, до многого дошли сами, могут писать сложный, надёжный и безошибочный код, но всё это на полуинтуитивном уровне, знание общетеоретических основ обычно сильно хромает... Простейший пример - мало кто из знакомых мне программистов может объяснить, что такое инвариант цикла... между тем, если посмотреть их код, становится ясно, что до этого понятия они давно самостоятельно дошли, успешно и правильно им пользуются при написании кода... Но инвариант цикла - понятие простейшее, нет ничего удивительного в том, что до него почти каждый своим умом доходит... А есть гораздо более сложные вещи, которые, тем не менее, должны бы составлять основу знаний любого программиста, но - не составляют... среднестатистический посетитель форумов вообще обычно не понимает, о чём идёт речь, если попытаться с ним поговорить об этом... А между тем в С и С++ обычно поражает не просто расхождение с теоретически обоснованными концепциями, а даже сознательное пренебрежение ими... поражает, конечно тех, кто знаком с этими концепциями... :)

Но стоит ли строго следовать теории, если мы можем писать код проще, быстрее, а иногда и эффективнее, отсутпая от него? Думаю, понятно, что вопрос этот вызывает споры... Я лично вот что думаю по этому поводу... вот, например, существует умножение в столбик - хорошо обоснованный формализм, который позволяет человеку умножить любое число на любое другое... но кто пользуется этим формализмом при умножении на 10? Никто - легче просто приписать нолик... а в школе у нас, помниться, была даже тема такая, "Формулы сокращённого умножения"... учили, что при умножении некоторого двузначного числа на 11 получается трёхзначное число, первая и последняя цифра которого совпадают с первой и последней в исходном числе, а средняя является суммой этих чисел... а если надо умножить на 25, то проще умножить на 100, а потом разделить на 4... Оправдано ли применение этих правил человеком? Да, оправдано, т.к. сокращает время вычислений, а проверка условий применимости и ветвление человеческому мозгу в смысле времени почти ничего не стоят... но представьте, например, что вы пишете библиотеку вычислений больших чисел - будете вы их использовать или ограничитесь универсальным формальным методом? Думаю, что ограничитесь формальизмом, потому что он даёт гарантированный результат при любых исходных данных и не требует многчисленных проверок условий применимости и ветвлений - код получается намного понятнее, его проще удержать в голове при написании и легче потом сопровождать...

К чему я всё это? К достоинствам С и С++ традиционно относят именно то, что они легче других языков позволяют программисту отказаться от формализма и реализовать более эффективные в конкретном случае частные правила... Но если писать действительно надёжный код, то во многих случаях окажется, что надо проверять довольном много условий применимости частного правила, чего обычно не делают, так как это сводит на нет преимущества в производительнсти... Условия применимости частных правил обычно только подразумеваются программистом - например, подразумевается, но не проверяется, что индекс массива не превысит его верхней границы... Но, с другой стороны, есть ситуации, когда применение частных правил позволяет получить более высокую производительность без снижения надёжности кода - за это С и С++ и любят...

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

ЗЫ ой как букф многа, сам нипанимаю как асилил :))))))))

C+- (07.06.07 12:03) [423]
так кто-нибудь объяснит, почему ?

← →
Однокамушкин (2007-06-10 07:21) [435]

> palva © (06.06.07 15:24) [386]
> Что-то непонятно. Вы пишете пример, в котором просите сделать
> компилятор то-то и то-то. Он делает именно то, что вы пишете.
> Вы же сами написали для функции разные прототипы. Вполне
> возможно, что в этом заложен глубокий смысл. Вы хотите чтобы
> компилятор на этапе компиляции увидел, что прототипы разные?
> Так напишите тогда код по-другому. Но если программисту
> взбредет в голову использовать разные прототипы, то у него
> есть такая возможность.

Прототип функции это такой же важный признак, как имя... с вашей логикой можно дойти до того, что если объявлена функция с одним именем, а реализована с другим, компилятор всё равно должен вызвать функцию с другим именем, потому что так написан код - а вдруг в этом заложен глубокий смысл?

← →
Algol (2007-06-10 09:28) [436]

> оправдано, но только тогда, когда действительно нужно выжать
> максимум производительности, а таких ситуаций благодаря
> совершенствованию железа и оптимизаторов становится всё
> меньше

Отнюдь. Да, железо совершенствуется, но и задачи усложняются. Причем если производительность имеет тенденцию расти линейно, то сложность задач как правило растет совсем нелинейно. Поэтому какое бы железо не было, всегда найдутся задачи, которые требуют еще большей производительности. А времена, когда компьютеры считали только корни квадратного уравнения - давно прошли.

← →
Algol (2007-06-10 09:32) [437]

> C+- (07.06.07 12:03) [423]
> так кто-нибудь объяснит, почему ?

После передачи первого параметра в функцию some(a++,a++) , значение a увеличивается на единицу, и в качестве второго параметра передается уже 2. Внутри функции происходит деление 1/2, но поскольку оба аргумента - целые, то происходит целочисленное деление, которое дает 0.

← →
@!!ex_ (2007-06-10 09:34) [438]

Ничто так не раздувает ветку, как очередной холивар...

> Algol (10.06.07 09:32) [437]
> Внутри функции происходит деление 1/2, но поскольку оба
> аргумента - целые, то происходит целочисленное деление,
> которое дает 0
>

Это не так. Стандарт не определяет порядок вычисления аргументов.
Цитата из "ISO/IEC 14882:1998 - C++ Final Draft" касаемо аргументов функций:
The order of evaluation of arguments is unspecified. All side effects of argument expression evaluations take effect before the function is entered. The order of evaluation of the postfix expression and the argument expression list is unspecified.

То есть допустим ряд вариантов, дающих разный результат, каждый из которых будет соответствовать стандарту. Например, первым будет вычислен второй аргумент (1), затем сработает его ++ и посчитается первый аргумент (2). В результате работы функции получим 2. Также допустима такая ситуация (если я правильно трактую второе из процитированных предложений, в чем я не совсем уверен): посчитается первый аргумент (1), второй аргумент (1), и лишь после этого выполнятся два ++. В результате функция вернет 1. :)

Не то процитировал у Algol-а. Мое возражение конечно же относится к предложению

> После передачи первого параметра в функцию some(a++,a++)
> , значение a увеличивается на единицу, и в качестве второго
> параметра передается уже 2.
>

Кто что думает? Найти похожие ветки