Здравствуйте, McSeem2, Вы писали:
MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */?
Причина простая.
Вложенные комментарии это контескстно свободный язык.
Если запретить вложенность то получаем регулярный язык который можно разбирать простым конечным автоматом.
Классический способ разбора текста это разделение разбора на 2 уровня лексер и парсер.
Лексер разбирает регулярное надмножество языка. И реализуется очень эффективным конечным автоматом.
Парсер разбирает контекстно свободное надмножество языка. Тут все сложнее. Но есть несколько техник для эффективного разбора некоторого подмножества контекстно свободных грамматик. Их проблема в том что они работают только на потоке токенов которые выдает лексер. На потоке символов они просто не смогут работать. Ибо у них очень сильно ограничена возможность по заглядыванию вперед.
Собственно в расчете на эту схему языки и проектируют. Эта схема даже в стандартах языков видна.
Можно построить безлексерный парсер. Проблема в том что эти алгоритмы идут в разрез со всеми догмами классического компиляторостроения и как следствие почти не исследованы. Все приходится изобретать на ходу.
Я сейчас работаю над таким построителем парсеров.
На то что получается можно посмотреть тут http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/
В качестве основы взят PEG но от классического PEG'а он со временем уйдет
Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */?
Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Eugeny__, Вы писали:
E__>Если честно, то слабо представляю пользу в любых комментариях, кроме строчных.
Еще раз, для глухих танкистов — дело не в комментариях. Я сам никогда не использую блочные коменты для описания — только строчные. Дело в том, чтобы исключить из компиляции на время — либо пока не понадобится, либо до полного удаления. Извините, но Crtl-K-Ctrl-C — это костыль. #if 0 — еще больший костыль. А уж использовать репозиторий каждый раз — вообще хромой костыль. Я вообще стараюсь не клать всякую помойку туда. При этом, я понимаю, что в прдакшен-коде блочные коменты — это моветон. Но зачем запрещатьь?! Просто я много экспериментирую и мало быдлокодирую.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Так делать — дурной тон. Читаемости коду оставленые тобой обгрызки непонятно чего не добавят. Не нужно — смело удаляем. То, бесценное творение, что ты хотел закомментировать можно забрать из системы контроля версий.
Ой, какие все умные...
Что, ни кто, ни разу не сталкивался с исследовательскими задачами, которые вообще не ясно как решать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Muxa, Вы писали:
M>прочитал тему, и возник вопрос: M>а что, все кроме меня понимают необходимость наличия возможности пользоваться вложенными комментариями?
Это очень удобно для того чтобы закомментировать кусок кода в котором уже есть комментарии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
MS>Еще раз, для глухих танкистов — дело не в комментариях. Я сам никогда не использую блочные коменты для описания — только строчные. Дело в том, чтобы исключить из компиляции на время — либо пока не понадобится, либо до полного удаления. Извините, но Crtl-K-Ctrl-C — это костыль. #if 0 — еще больший костыль. А уж использовать репозиторий каждый раз — вообще хромой костыль. Я вообще стараюсь не клать всякую помойку туда. При этом, я понимаю, что в прдакшен-коде блочные коменты — это моветон. Но зачем запрещатьь?! Просто я много экспериментирую и мало быдлокодирую.
забавно, ты им — "глупое ограничение на вложенные комментарии", они тебе "нафиг не нужны вложенные комментарии, используй то, это, пятое, десятое, стукни в бубен здесь, тому, этому и т.п.". как будто на разных языках говорим.
Of course, the code must be complete enough to compile and link.
B>Обознался, признаю. B>У меня в 2005 никаких проблем с раскраской #if #endif нет.
это 2008. он тоже раскрасит, видимо, когда как-то неявно запустится препроцессор или еще что там. но в случае комментария он раскрашивает сразу. впрочем, неважно все это. можно обойтись без многострочных комментариев, с этим никто не спорит. просто те, что есть — "недоделанные".
Of course, the code must be complete enough to compile and link.
Здравствуйте, okman, Вы писали:
O>Потому что кто-нибудь обязательно воспользуется этим и понапишет вложенных на полсотни уровней комментов, потом сиди разгребай...
Их можно было бы подсвечивать разными цветами. ИМХО, для современных IDE это совсем несложно. Скажем, четная вложенность и нечетная — разными цветами, или цвет фона разный. Или завести, скажем, отдельные градации для 8 уровней вложенности.
Здравствуйте, WolfHound, Вы писали:
M>>а что, все кроме меня понимают необходимость наличия возможности пользоваться вложенными комментариями? WH>Это очень удобно для того чтобы закомментировать кусок кода в котором уже есть комментарии.
В наше прогрессивное время этот кусок кода уже можно тупо удалять. А потом сделать git checkout имяфайла или, если файл уже закоммичен, откатить тот коммит, которым этот блок удалён.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, McSeem2, Вы писали:
MS>>Я верю тебе как родному, но скажи пожалуйста, чем принципиально отличается конструкция /* */ от { }? Только тем, что там два символа? MS>>Ну и потом, современные языки, старше Си, принципиально не позволяют пользоваться потоковым конечным автоматом, хотя бы потому, что допускают ссылки вперед внутри классов. WH>Я вроде все объяснил. Ну ладно попробую еще раз.
WH>Класические компиляторы работают грубо говоря в 4 этапа: WH>1)Разбор текста на токены. На это этапе отбрасываются пробелы и коментарии. WH>Тут все разбирается ужасно эффективными конечными автоматами.
Нет никакой проблемы изменить реализацию препроцессора и учесть вложенность комментариев. Задача плёвая.
Здравствуйте, McSeem2, Вы писали:
MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? MS>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Eugeny__, Вы писали:
E__>>А нахрена, собственно? Я и сами-то комментарии /* */ использую раз в пятилетку, и то, когда нужно временно закомментить что-то в одной строке — довольно редки use-case.
MS>Я очень много экспериментирую с кодом, соответственно часто приходится копи-пастить и коментить большие куски. Я согласен, что для продакшена эти вложенные коменты нафиг не уперлись, но для экпериментов — напрягает.
директивы могут быть вложенными
попробуй
#if 0/1 // condition 1
....
#if 0/1 // condition 2
....
#end if // condition 2
....
#endif // condition 1
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Сталкивался. И сложность задачи ни разу не оправдание делать криво. С другой стороны сталкивался с теми, кому контроль версий кажется чем-то нереально сложным и лишним.
Ты похоже выдумал себе кучу каких то страшилок и с ними споришь.
А что касается версионника то: в чем смысл комитов с кучей неработоспособного мусора?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, McSeem2, Вы писали:
MS>Я верю тебе как родному, но скажи пожалуйста, чем принципиально отличается конструкция /* */ от { }? Только тем, что там два символа?
С синтаксической точки зрения -- ничем. Только вторая конструкция обычно разбирается синтаксическим анализатором, который работает на КС-грамматике, а первая -- это такой специальный токен, который лексер выделяет. Традиционно, языки токенов -- языки регулярныей, т.е. отношение иерархии не может быть реализовано. Вопрос в том, почему сложилась такая традиция -- лексический анализ проводить только над регулярными (читай автоматными) языками. Скажу честно -- не знаю. Скорее всего из простых соображений унификации. Лексический анализатор разделяет входной текст на слова, каждое из которых имеет совсем простой синтаксис (просто выражается в регулярности языка). Если считать словом то, что имеет синтаксис иерархии, то это не соответствует нашей интуиции. Ну слово -- это "acb", "3.123" или крайний случай "/* djdjdj */". Но назвать словом такую фигню:
/* dfsf
/* dsfsdfsdf
dfdsf
*/
*/
язык не поворачивается. Разметка уже наобходима, чтобы хорошо увидеть иерархию в слове -- это как раз и отражает сложность языка данного токена.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Лучше мусор держать прямо в исходнике. Ты — стратег.
Смысл в том чтобы удалять мусор перед комитом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
FR> MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? FR> MS>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
FR> В OCaml можно
Delphi, как всегда, рулит Там вообще три вида коментариев
E__>>А нахрена, собственно? Я и сами-то комментарии /* */ использую раз в пятилетку, и то, когда нужно временно закомментить что-то в одной строке — довольно редки use-case.
TSP>Для параметров по умолчанию использую.
TSP>
TSP>class Class1
TSP>{
TSP> ...
TSP> void Method1( int p1, int p2 = 1, int p3 = 0 );
TSP> ...
TSP>}
TSP>
TSP>
TSP>void Class1::Method1( int p1, int p2/* = 1*/, int p3/* = 0*/ )
TSP>{
TSP> ...
TSP>}
TSP>
TSP>Я считаю что удобно.
Ну, для плюсов, для которых нет нормальных IDE и зачем-то разделено определение и имплементация методов — может быть.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> H>Так разделение описания и имплементации это же благо (не о Си речь, а вообще). Нет нужды лопатить код пытаясь понять интерфейс класса
E> Для этого в нормальных IDE есть outline. Это гораздо более удобная штука, так как показывает и структуру(интерфейс) класса, и структуру билдфайла, и spring конфига, и еще сотен известных IDE форматов.
Я с кодом работаю не только в IDE. Иногда для чтения FAR использую, т.ч. эта жабашарповая свалочная модель кода просто капец какой-то. Кроме того, даже работая в IDE я предпочитаю читать код, а не графическое представление его внутренностей (тот самый аутлайн).
E> В плюсах это придумали из-за того, что тогдашние среды разработки были убогими, а сам язык для разбора структуры неудобен(да и тогдашние процы не позволили бы по плюсовому коду в реалтайме в процессе разработки генерить аутлайн).
Этот подход присущь не только Си (и уж тем более, я сильно сомневаюсь, что решение о разделении было продиктовано отсутствием "нормальных" IDE) Те же Delphi, Ada имеют раздельные части интерфейса и имплементации (в Delphi, правда, удобнее).
H>Да. Просто учитывай тот факт, что кому-то чаще работать приходится с классами нежели с интерфейсами.
Вобщем, завершаем. У нас принципиально разные подходы. Я гораздо чаще работаю именно с интерфейсами. А у ряда интерфейсов так вообще нет ни одной реализации — они создаются динамически(см. Proxy).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Eugeny__, Вы писали:
E__>>Если честно, то слабо представляю пользу в любых комментариях, кроме строчных.
MS>Еще раз, для глухих танкистов — дело не в комментариях. Я сам никогда не использую блочные коменты для описания — только строчные. Дело в том, чтобы исключить из компиляции на время — либо пока не понадобится, либо до полного удаления. Извините, но Crtl-K-Ctrl-C — это костыль. #if 0 — еще больший костыль. А уж использовать репозиторий каждый раз — вообще хромой костыль. Я вообще стараюсь не клать всякую помойку туда. При этом, я понимаю, что в прдакшен-коде блочные коменты — это моветон. Но зачем запрещатьь?! Просто я много экспериментирую и мало быдлокодирую.
Остынь чуть-чуть. В С++ препроцессор предназначен для управления кодом, в том числе, для включения/выключения блоков кода. Комментарии же имеют другое предназначение. Посмотри на свою аргументацию со стороны: ты пытаешься забить гвоздь отверткой, это у тебя плохо получается, и ты говоришь, что конструкция отвертки не та. Когда тебе советуют взять молоток, ты говоришь, что молоток -- это костыль.
Здравствуйте, McSeem2, Вы писали:
MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? MS>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
Вложенные куда? Давай пример
Здравствуйте, McSeem2, Вы писали:
MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? MS>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
Потому что кто-нибудь обязательно воспользуется этим и понапишет вложенных на полсотни уровней комментов, потом сиди разгребай...
Здравствуйте, DTB, Вы писали:
DTB>/* begin /*cmt1*/ end */
Ааа. Тогда в C# точно также.
DTB>кстати порой действительно вымораживает, приходится блок комментить //
Я чего-то вообще не использую /* */. Давно уже приноровился в Студии жать Ctrl+K, C.
Здравствуйте, MxMsk, Вы писали:
DTB>>кстати порой действительно вымораживает, приходится блок комментить // MM>Я чего-то вообще не использую /* */. Давно уже приноровился в Студии жать Ctrl+K, C.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Muxa, Вы писали:
M>>прочитал тему, и возник вопрос: M>>а что, все кроме меня понимают необходимость наличия возможности пользоваться вложенными комментариями? WH>Это очень удобно для того чтобы закомментировать кусок кода в котором уже есть комментарии.
Hotkeys не помогают?
Я, конечно, понимаю, что нужно сделать больше движений, но...
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, McSeem2, Вы писали:
MS>>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */?
WH>Причина простая. WH>Вложенные комментарии это контескстно свободный язык. WH>Если запретить вложенность то получаем регулярный язык который можно разбирать простым конечным автоматом.
Часто комментарий /* */ обрабатывается циклом По крайней мере всякие минимальные вхождения появились относительно недавно, раньше везде жил цикл (пример для паскаля)
"(*" |
"{" { register int c;
while ((c = input()))
{
if (c == '}')
break;
else if (c == '*')
{
if ((c = input()) == ')')
break;
else
unput (c);
}
else if (c == '\n')
line_no++;
else if (c == 0)
commenteof();
}
}
подправить его с учетом вложенности не такая уж большая проблема
Здравствуйте, McSeem2, Вы писали:
MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? MS>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
А нахрена, собственно? Я и сами-то комментарии /* */ использую раз в пятилетку, и то, когда нужно временно закомментить что-то в одной строке — довольно редки use-case.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>А нахрена, собственно? Я и сами-то комментарии /* */ использую раз в пятилетку, и то, когда нужно временно закомментить что-то в одной строке — довольно редки use-case.
Я очень много экспериментирую с кодом, соответственно часто приходится копи-пастить и коментить большие куски. Я согласен, что для продакшена эти вложенные коменты нафиг не уперлись, но для экпериментов — напрягает.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, WolfHound, Вы писали:
MS>>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? WH>Причина простая. WH>Вложенные комментарии это контескстно свободный язык. WH>Если запретить вложенность то получаем регулярный язык который можно разбирать простым конечным автоматом.
Я верю тебе как родному, но скажи пожалуйста, чем принципиально отличается конструкция /* */ от { }? Только тем, что там два символа?
Ну и потом, современные языки, старше Си, принципиально не позволяют пользоваться потоковым конечным автоматом, хотя бы потому, что допускают ссылки вперед внутри классов.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Я верю тебе как родному, но скажи пожалуйста, чем принципиально отличается конструкция /* */ от { }? Только тем, что там два символа? MS>Ну и потом, современные языки, старше Си, принципиально не позволяют пользоваться потоковым конечным автоматом, хотя бы потому, что допускают ссылки вперед внутри классов.
Я вроде все объяснил. Ну ладно попробую еще раз.
Класические компиляторы работают грубо говоря в 4 этапа:
1)Разбор текста на токены. На это этапе отбрасываются пробелы и коментарии.
Тут все разбирается ужасно эффективными конечными автоматами.
2)Разбор контекстно свободного надмножества языка.
Тут кучу вариантов LL(1), LL(k), LL(*), LR(0), LR(1), LALR, GLR,... и еще куча алгоритмов для разбора контекстно свободных язаков.
На этом этапе обрабатываются {}.
Коментарии до сюда не доходят.
3)Поиск имен, типизация, разрешение перегрузки,...
Тут некий рукопашный код.
Именно тут обрабатываются ссылки вперед.
Никакого текста на этом этапе уже нет.
WH>Классический способ разбора текста это разделение разбора на 2 уровня лексер и парсер.
Ты забыл, что речь идет о С++. Там прежде чем лексер с парсером запустить, должно препроцессирование выполниться. И в принципе во время препроцессирования убрать все комментарии вполне можно. Даже вложенные. Кстати, Borland C++ для DOS это умел. Так что ИМХО причины не в этом.
Здравствуйте, WolfHound, Вы писали:
WH>Это очень удобно для того чтобы закомментировать кусок кода в котором уже есть комментарии.
Так делать — дурной тон. Читаемости коду оставленые тобой обгрызки непонятно чего не добавят. Не нужно — смело удаляем. То, бесценное творение, что ты хотел закомментировать можно забрать из системы контроля версий.
MS>>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего.
L_L>наверняка, какие-нить кретинские заморочки компиляторов времен "Очакова и покоренья Крыма"
А впрочем, не кретинские, зря я так отцов Наверняка хотели попроще — вот начался коммент и все, скипать все, что внутри, пока не найдем */ и плеваааать на всякие там вложенности
Of course, the code must be complete enough to compile and link.
Здравствуйте, WolfHound, Вы писали:
WH>Что, ни кто, ни разу не сталкивался с исследовательскими задачами, которые вообще не ясно как решать?
Сталкивался. И сложность задачи ни разу не оправдание делать криво. С другой стороны сталкивался с теми, кому контроль версий кажется чем-то нереально сложным и лишним.
Здравствуйте, Head Ache, Вы писали:
HA>директивы могут быть вложенными HA>попробуй
Это называется костыль. И нужно это исключительно из-за того что прямые методы не работают.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Шахтер, Вы писали:
Ш>Нет никакой проблемы изменить реализацию препроцессора и учесть вложенность комментариев. Задача плёвая.
Такое впечатление что народ вообще не читает что я пишу. Я еще в первом сообщении показал как это сделать с использованием парвильных инструментов.
Меняем это
И еще поймите наконец что двустадийный разбор текста (регулярный лексер + контекстно свободный парсер) вдалбливался во всех вузах на протяжении десятков лет. Народу просто в голову не приходило что можно иначе.
А когда накапливался опыт и приходило прозрение что что-то тут не так были уже мегатонны кода и обратная совместимость во всей красе.
Научный mainstream страшная штука.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, McSeem2, Вы писали:
WH>1)Разбор текста на токены. На это этапе отбрасываются пробелы и коментарии. WH>Тут все разбирается ужасно эффективными конечными автоматами.
Не все, для комментариев /* */, (* *) часто используют циклы. По крайней мере, это несложно сделать. Конечный автомат определяет только начало комментария.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ты забыл, что речь идет о С++. Там прежде чем лексер с парсером запустить, должно препроцессирование выполниться. И в принципе во время препроцессирования убрать все комментарии вполне можно. Даже вложенные. Кстати, Borland C++ для DOS это умел. Так что ИМХО причины не в этом.
А кто сказал, что комментарии не нужны компилятору? Синтаксический анализ для проверки соответствия стилю -- вполне распространенная задача.
Здравствуйте, WolfHound, Вы писали:
WH>А что касается версионника то: в чем смысл комитов с кучей неработоспособного мусора?
Всё зависит от сложности — если проще накидать кода в комменты, чем в репозитарий, то надо накидывать. Если же с версионником проще, то зачем загромождать исходник?
Например, так — в мастер-ветке все коммиты рабочие, а исследования проводим в экспериментальных ветках. Т.е. ветки и rebase спасают в таких ситуациях.
Здравствуйте, mefrill, Вы писали:
M>А кто сказал, что комментарии не нужны компилятору? Синтаксический анализ для проверки соответствия стилю -- вполне распространенная задача.
А еще есть IDE... и по хорошему парсить код в IDE и компиляторе должен один и тот же код.
Вообще у меня бродит мысль научить свой генератор парсеров генерировать несколько AST.
Основное АСТ программы.
АСТ препроцессора.
АСТ коментариев.
При компиляции мы просто игнорируем два последних АСТ. А в случае с IDE мы можем получить из них всю информацию для подсветки, аутлайнининга, навигации, автокомплита,...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mystic, Вы писали:
M>Не все, для комментариев /* */, (* *) часто используют циклы. По крайней мере, это несложно сделать. Конечный автомат определяет только начало комментария.
Цикл это деталь раелизации конечного автомата.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Alexey931, Вы писали:
A>Каменты вида /* */ вообще оставлены только для совместимости с C. Они и там были сделаны не подумавши: A> a = b/*c; // Смысл выражения неприятно зависит от наличия или отсутствия пробела между / и *
Кстати о пробелах... http://blogs.msdn.com/b/ericlippert/archive/2010/10/04/no-backtracking-part-one.aspx
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mefrill, Вы писали:
M>А кто сказал, что комментарии не нужны компилятору? Синтаксический анализ для проверки соответствия стилю -- вполне распространенная задача.
Анализ комментариев ? На С++ ? Можно подробнее ?
Другое дело, что комментарии действительно используются. Например, для MFC программ их роль очень велика — по ним вставляется код мастером, их убирать нельзя. Но это все же дело не компилятора, а мастера вставки MFC-кода.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Анализ комментариев ? На С++ ? Можно подробнее ?
Лексический анализатор обычно строится так, чтобы его не нужно было переписывать для каждой локальной задачи. Основная задача лексера -- разбиение входного текста на поток токенов (участков текста, которым приписаны лексические типы: числа, идентфикаторы, операторы и т.д.). Кто может сказать заранее, какие токены понадобятся, т.е. как будет использоваться лексер? Для простой программы предположить это можно и можно возвращать только значимые токены для конкретного синтаксического анализатора, который использует данный лексер как клиент. Например, не возвращать комментарии и пробелы, хотя учитывать их как разделители. Например, для кода:
int main();
возвратить поток: (KEY_WORD, "int", 1, 3), (IDENTIFIER, "main", 5, 4), (LEFT_PARENT, "(",10, 1), (RIGHT_PARENT,")",11,1), (SEMICOLON,";",12,1). Один токен здесь проигнорирован -- это (WHITE_SPACE," ",4,1). Для компиляции C++ он не важен, а для программы проверки стиля -- это тоже синтаксический анализатор, необходим. Хорошая программа проверки понимает синтаксис языка программирования, но вдобавок проверяет еще и другие вещи.
Здравствуйте, mefrill, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Анализ комментариев ? На С++ ? Можно подробнее ?
Благодарю за популярное изложение, но я спрашивал не об этом, а о том, где именно и в каким образом некий компилятор с С++ анализирует комментарии, и что из этого получается. Если есть что сказать конкретно — жду.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Head Ache, Вы писали:
HA>>директивы могут быть вложенными HA>>попробуй WH>Это называется костыль. И нужно это исключительно из-за того что прямые методы не работают.
А где они работают?
Вроде как в Шарпе, Яве и т.п. то же самое?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Muxa, Вы писали:
M>>прочитал тему, и возник вопрос: M>>а что, все кроме меня понимают необходимость наличия возможности пользоваться вложенными комментариями? WH>Это очень удобно для того чтобы закомментировать кусок кода в котором уже есть комментарии.
хм? в емаксе команда для комментирования куска С кода приводит к добавлению "//" в начало каждой строки. Захотел еще больше закомментарить — добавился еще знак. И так по ходу. символы "/* */" вообще не используются.
Здравствуйте, March_rabbit, Вы писали:
M_>хм? в емаксе команда для комментирования куска С кода приводит к добавлению "//" в начало каждой строки. Захотел еще больше закомментарить — добавился еще знак. И так по ходу. символы "/* */" вообще не используются. M_>используем правильные IDE
Этот костыль встроен во все IDE.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, blackhearted, Вы писали:
B>А где они работают? B>Вроде как в Шарпе, Яве и т.п. то же самое?
Так я о том и говорю... двустадийный разбор текста вдолбили всем до такой степени что у людей даже мысли не возникает что можно делать по другому.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
VV>>Так делать — дурной тон. Читаемости коду оставленые тобой обгрызки непонятно чего не добавят. Не нужно — смело удаляем. То, бесценное творение, что ты хотел закомментировать можно забрать из системы контроля версий. WH>Ой, какие все умные... WH>Что, ни кто, ни разу не сталкивался с исследовательскими задачами, которые вообще не ясно как решать?
Часто нужно комментить здоровенные куски кода (к сожалению, тут так пишут у меня, что функции по тыще строк — нормальное явление). наличие в них тут и там многострочных комментариев, оставленных авторами, сильно затрудняет использование многострочных комментариев для _меня_
Of course, the code must be complete enough to compile and link.
Здравствуйте, WolfHound, Вы писали:
WH>Ты похоже выдумал себе кучу каких то страшилок и с ними споришь.
Ну дык. Отличный аргумент. Ты мне скажешь, что я выдумал, я тебе отвечу, что ты сам выдумал. Конструктив и Profit.
WH>А что касается версионника то: в чем смысл комитов с кучей неработоспособного мусора?
Лучше мусор держать прямо в исходнике. Ты — стратег.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Шахтер, Вы писали:
Ш>>Нет никакой проблемы изменить реализацию препроцессора и учесть вложенность комментариев. Задача плёвая. WH>Такое впечатление что народ вообще не читает что я пишу. Я еще в первом сообщении показал как это сделать с использованием парвильных инструментов. WH>Меняем это WH>
WH>и наслаждаемся вложенными комментариями.
WH>И еще поймите наконец что двустадийный разбор текста (регулярный лексер + контекстно свободный парсер) вдалбливался во всех вузах на протяжении десятков лет. Народу просто в голову не приходило что можно иначе.
Не надо так уж про весь народ. Особенно пишущий компиляторы.
WH>А когда накапливался опыт и приходило прозрение что что-то тут не так были уже мегатонны кода и обратная совместимость во всей красе. WH>Научный mainstream страшная штука.
Ещё раз, мегатонны кода тут не при чем. Было решено, что вложенные комментарии не нужны. И всё. Было бы решено по другому -- сделали бы по другому.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
VV>>>Так делать — дурной тон. Читаемости коду оставленые тобой обгрызки непонятно чего не добавят. Не нужно — смело удаляем. То, бесценное творение, что ты хотел закомментировать можно забрать из системы контроля версий. WH>>Ой, какие все умные... WH>>Что, ни кто, ни разу не сталкивался с исследовательскими задачами, которые вообще не ясно как решать?
L_L>Часто нужно комментить здоровенные куски кода (к сожалению, тут так пишут у меня, что функции по тыще строк — нормальное явление). наличие в них тут и там многострочных комментариев, оставленных авторами, сильно затрудняет использование многострочных комментариев для _меня_
Здравствуйте, McSeem2, Вы писали:
MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? MS>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
H>Delphi, как всегда, рулит Там вообще три вида коментариев
Остается только понять, нахрена??
Если честно, то слабо представляю пользу в любых комментариях, кроме строчных.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mystic, Вы писали:
M>>Не все, для комментариев /* */, (* *) часто используют циклы. По крайней мере, это несложно сделать. Конечный автомат определяет только начало комментария. WH>Цикл это деталь раелизации конечного автомата.
Неправильно. Сишный код (и циклы в нем) эквивалентен по мощности машине Тьюринга, но не конечному автомату.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, McSeem2, Вы писали:
MS>>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? MS>>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
E__>А нахрена, собственно? Я и сами-то комментарии /* */ использую раз в пятилетку, и то, когда нужно временно закомментить что-то в одной строке — довольно редки use-case.
Для параметров по умолчанию использую.
class Class1
{
...
void Method1( int p1, int p2 = 1, int p3 = 0 );
...
}
void Class1::Method1( int p1, int p2/* = 1*/, int p3/* = 0*/ )
{
...
}
Здравствуйте, Eugeny__, Вы писали:
E> H>Delphi, как всегда, рулит Там вообще три вида коментариев
E> Остается только понять, нахрена??
E> Если честно, то слабо представляю пользу в любых комментариях, кроме строчных.
Здравствуйте, McSeem2, Вы писали:
E__>>Если честно, то слабо представляю пользу в любых комментариях, кроме строчных.
MS>Еще раз, для глухих танкистов — дело не в комментариях. Я сам никогда не использую блочные коменты для описания — только строчные. Дело в том, чтобы исключить из компиляции на время — либо пока не понадобится, либо до полного удаления.
Ctrl+/ — в нормальных средах комментит/анкомментит выделенный кусок.
MS>Извините, но Crtl-K-Ctrl-C — это костыль. #if 0 — еще больший костыль. А уж использовать репозиторий каждый раз — вообще хромой костыль. Я вообще стараюсь не клать всякую помойку туда. При этом, я понимаю, что в прдакшен-коде блочные коменты — это моветон. Но зачем запрещатьь?! Просто я много экспериментирую и мало быдлокодирую.
Я вообще не понимаю, о чем вот сейчас ты говорил.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>Ну, для плюсов, для которых нет нормальных IDE и зачем-то разделено определение и имплементация методов — может быть.
Разделено и разделено. Теперь то не переделаешь. Это не самое неприятное в плюсах.
А вообще у меня Visual Assist стоит. Он сам генерит из определения болванку имплементации с такими комментами.
Здравствуйте, TimurSPB, Вы писали:
TSP> E__>Ну, для плюсов, для которых нет нормальных IDE и зачем-то разделено определение и имплементация методов — может быть. TSP> Разделено и разделено. Теперь то не переделаешь. Это не самое неприятное в плюсах. TSP> А вообще у меня Visual Assist стоит. Он сам генерит из определения болванку имплементации с такими комментами.
Так разделение описания и имплементации это же благо (не о Си речь, а вообще). Нет нужды лопатить код пытаясь понять интерфейс класса
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, TimurSPB, Вы писали:
TSP>> E__>Ну, для плюсов, для которых нет нормальных IDE и зачем-то разделено определение и имплементация методов — может быть. TSP>> Разделено и разделено. Теперь то не переделаешь. Это не самое неприятное в плюсах. TSP>> А вообще у меня Visual Assist стоит. Он сам генерит из определения болванку имплементации с такими комментами.
H>Так разделение описания и имплементации это же благо (не о Си речь, а вообще). Нет нужды лопатить код пытаясь понять интерфейс класса
Для этого в нормальных IDE есть outline. Это гораздо более удобная штука, так как показывает и структуру(интерфейс) класса, и структуру билдфайла, и spring конфига, и еще сотен известных IDE форматов.
В плюсах это придумали из-за того, что тогдашние среды разработки были убогими, а сам язык для разбора структуры неудобен(да и тогдашние процы не позволили бы по плюсовому коду в реалтайме в процессе разработки генерить аутлайн).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E>> H>Так разделение описания и имплементации это же благо (не о Си речь, а вообще). Нет нужды лопатить код пытаясь понять интерфейс класса
E>> Для этого в нормальных IDE есть outline. Это гораздо более удобная штука, так как показывает и структуру(интерфейс) класса, и структуру билдфайла, и spring конфига, и еще сотен известных IDE форматов.
H>Я с кодом работаю не только в IDE. Иногда для чтения FAR использую, т.ч. эта жабашарповая свалочная модель кода просто капец какой-то.
Зачем? Зачем использовать для работы с кодом инструмент, не заточенный под это?
H>Кроме того, даже работая в IDE я предпочитаю читать код, а не графическое представление его внутренностей (тот самый аутлайн).
Ну а я считаю, что код — это код. Это не просто текст. У него есть определенная структура, а текстовое представление оставлено для определенных целей(например, системы контроля версий). И работаю с ним максимально подходящими для этого средствами, которые многое упрощают.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> H>Я с кодом работаю не только в IDE. Иногда для чтения FAR использую, т.ч. эта жабашарповая свалочная модель кода просто капец какой-то.
E> Зачем? Зачем использовать для работы с кодом инструмент, не заточенный под это?
Потому что быстрее. Быстро поиском нашел, быстро глянул. Быстро и удобно.
E> H>Кроме того, даже работая в IDE я предпочитаю читать код, а не графическое представление его внутренностей (тот самый аутлайн).
E> Ну а я считаю, что код — это код. Это не просто текст. У него есть определенная структура, а текстовое представление оставлено для определенных целей(например, системы контроля версий). И работаю с ним максимально подходящими для этого средствами, которые многое упрощают.
Ты верно говоришь: код это код и у него есть структура. Только в нормальных языках я вижу структуру уже тогда, когда читаю этот код, а в других для этого идешные костыли нужны Кроме личных предпочтений существует еще один плюс отделяемой интерфейсной части — ты всегда можешь отдать оную коллеге, не беспокоясть о том, что он в своей работе завяжется на некие детали реализации.
E>> H>Я с кодом работаю не только в IDE. Иногда для чтения FAR использую, т.ч. эта жабашарповая свалочная модель кода просто капец какой-то.
E>> Зачем? Зачем использовать для работы с кодом инструмент, не заточенный под это?
H>Потому что быстрее. Быстро поиском нашел, быстро глянул. Быстро и удобно.
Поиск в IDE гораздо быстрее и удобнее.
Почему-то никто не старается вручную, в тексте менять rtf файлы. А вот код сишники предпочитают воспринимать как текст, хоть убей.
E>> H>Кроме того, даже работая в IDE я предпочитаю читать код, а не графическое представление его внутренностей (тот самый аутлайн).
E>> Ну а я считаю, что код — это код. Это не просто текст. У него есть определенная структура, а текстовое представление оставлено для определенных целей(например, системы контроля версий). И работаю с ним максимально подходящими для этого средствами, которые многое упрощают.
H>Ты верно говоришь: код это код и у него есть структура. Только в нормальных языках я вижу структуру уже тогда, когда читаю этот код, а в других для этого идешные костыли нужны Кроме личных предпочтений существует еще один плюс отделяемой интерфейсной части — ты всегда можешь отдать оную коллеге, не беспокоясть о том, что он в своей работе завяжется на некие детали реализации.
[черт, уже 4 раза я писал это сообщение, и каждый раз вырубало свет, не давая отправить ]
Для этого есть интерфейс. Как отдельный элемент, поддерживаемый на уровне языка и среды. И который не отправляется как кусок текста коллеге, а просто достается им из системы контроля версий. И который не обязан показывать все методы класса, а только нужные для взаимодействия. Коллеге(а уж тем более левому человеку, использующему твою либу) не нужен внутренний метод, используемый только тобою для определенных целей. Ему нужны только методы интерфейса, которые он может использовать. А так ты захотел поменять сигнатуру(или, что хуже, логику) метода, который логически извне не должен использоваться. А коллега нечаянно его использует. И все, привет проблема на ровном месте.
Разделение интерфейса взаимодействия и реализации — очень хорошая штука, на самом деле.
Просто пойми, что не нужно работать с кодом как с текстом, и открывать в текстовых редакторах. Хотя в случае Си, и тем более плюсов, это труднее, так как даже при наличие ассиста проще открыть фаром, и не париться. Ну, потому и появились жабошарпы.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> H>Потому что быстрее. Быстро поиском нашел, быстро глянул. Быстро и удобно.
E> Поиск в IDE гораздо быстрее и удобнее.
Имелся ввиду поиск по каталогам с файлами, где их может быть несколько тысяч.
E> Почему-то никто не старается вручную, в тексте менять rtf файлы. А вот код сишники предпочитают воспринимать как текст, хоть убей.
Все просто. RTF, помимо, собственно, текста, содержит нформацию для его форматирования. А вот исходники это plain text. Ваш К.О.
E> H>Ты верно говоришь: код это код и у него есть структура. Только в нормальных языках я вижу структуру уже тогда, когда читаю этот код, а в других для этого идешные костыли нужны Кроме личных предпочтений существует еще один плюс отделяемой интерфейсной части — ты всегда можешь отдать оную коллеге, не беспокоясть о том, что он в своей работе завяжется на некие детали реализации.
E> [черт, уже 4 раза я писал это сообщение, и каждый раз вырубало свет, не давая отправить ]
E> Для этого есть интерфейс. Как отдельный элемент, поддерживаемый на уровне языка и среды.
Интерфейсы, не всегда применимы, иногда требуются именно классы, а то и вовсе процедуры и функции.
E> И который не отправляется как кусок текста коллеге, а просто достается им из системы контроля версий.
Собственно и в случае раздельных частей никаких проблем с системами контроля версий нет
E> И который не обязан показывать все методы класса, а только нужные для взаимодействия. Коллеге(а уж тем более левому человеку, использующему твою либу) не нужен внутренний метод, используемый только тобою для определенных целей. Ему нужны только методы интерфейса, которые он может использовать.
Так в чем проблема? Ему доступны только public методы + protected если он наследуется. Все внутренности закрыты в private и доступа к ним он не получит. Зато есть другой момент. Ты сам можешь допустить оплошность/недосмотр в проектировании, а человек со стороны скажет: "О! я смотрю у тебя есть приватный метод XX, неплохо бы его сделать доступным в потомках с целью увеличения гибкости". Это, кстати, не такая уж редкая ситуация.
E> А так ты захотел поменять сигнатуру(или, что хуже, логику) метода, который логически извне не должен использоваться. А коллега нечаянно его использует. И все, привет проблема на ровном месте.
Если ты все внутренности по уму закрыл в привате такой проблемы даже не возникнет.
E> Разделение интерфейса взаимодействия и реализации — очень хорошая штука, на самом деле.
Вот только разделение выполняется не только интерфейсом, как языковой единицей. Модификаторы видимости суть то же самое разделение — все что публичное это твой интерфейс, все закрытое суть детали реализации к которым у тебя доступа нет и ничего с ними ты сделать не можешь.
E> Просто пойми, что не нужно работать с кодом как с текстом, и открывать в текстовых редакторах. Хотя в случае Си, и тем более плюсов, это труднее, так как даже при наличие ассиста проще открыть фаром, и не париться. Ну, потому и появились жабошарпы.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Head Ache, Вы писали:
HA>>директивы могут быть вложенными HA>>попробуй WH>Это называется костыль. И нужно это исключительно из-за того что прямые методы не работают.
ну и чем директива принципиально отличается от коммента?
и то и другое — по сути инструкция пропустить тот или иной фрагмент текста.
различие лишь в том, что коммент — это безусловное требование без параметров.
Здравствуйте, hattab, Вы писали:
E>> H>Потому что быстрее. Быстро поиском нашел, быстро глянул. Быстро и удобно.
E>> Поиск в IDE гораздо быстрее и удобнее.
H>Имелся ввиду поиск по каталогам с файлами, где их может быть несколько тысяч.
У меня почему-то это ассоциируется с копанием в мусорнике. Что это за файлы и каталоги? Это проект? Ну дык открой его как проект. Я слабо представляю, что это может быть за свалка каких-то исходников.
E>> Почему-то никто не старается вручную, в тексте менять rtf файлы. А вот код сишники предпочитают воспринимать как текст, хоть убей.
H>Все просто. RTF, помимо, собственно, текста, содержит нформацию для его форматирования. А вот исходники это plain text. Ваш К.О.
Исходники тоже ее содержат.
E>> H>Ты верно говоришь: код это код и у него есть структура. Только в нормальных языках я вижу структуру уже тогда, когда читаю этот код, а в других для этого идешные костыли нужны Кроме личных предпочтений существует еще один плюс отделяемой интерфейсной части — ты всегда можешь отдать оную коллеге, не беспокоясть о том, что он в своей работе завяжется на некие детали реализации.
E>> [черт, уже 4 раза я писал это сообщение, и каждый раз вырубало свет, не давая отправить ]
E>> Для этого есть интерфейс. Как отдельный элемент, поддерживаемый на уровне языка и среды.
H>Интерфейсы, не всегда применимы, иногда требуются именно классы, а то и вовсе процедуры и функции.
Примеры в студию.
E>> И который не обязан показывать все методы класса, а только нужные для взаимодействия. Коллеге(а уж тем более левому человеку, использующему твою либу) не нужен внутренний метод, используемый только тобою для определенных целей. Ему нужны только методы интерфейса, которые он может использовать.
H>Так в чем проблема? Ему доступны только public методы + protected если он наследуется. Все внутренности закрыты в private и доступа к ним он не получит. Зато есть другой момент. Ты сам можешь допустить оплошность/недосмотр в проектировании, а человек со стороны скажет: "О! я смотрю у тебя есть приватный метод XX, неплохо бы его сделать доступным в потомках с целью увеличения гибкости". Это, кстати, не такая уж редкая ситуация.
Класс может реализовывать несколько интерфейсов. И для одного модуля он будет одной сущностью, а для другого — другой. Но объект при этом будет один.
А по поводу случая с тем, чтобы сделать приватный метод публичным... Ну это подход через жопу какой-то. Инициатива должна исходить не из кода, а из требований. Ну, то есть, подходит ко мне коллега, и говорит: Жека, слушай, ты можешь мне предоставить такую-то инфу? Я понимаю, что да, и даже метод у меня такой есть. Добавлю его в интерфейс. А то так все пооткрывать можно — гибкость будет потрясающая. И проект потихоньку будет превращаться в нечто очень сильносвязанное, и уже попахивающее.
E>> А так ты захотел поменять сигнатуру(или, что хуже, логику) метода, который логически извне не должен использоваться. А коллега нечаянно его использует. И все, привет проблема на ровном месте.
H>Если ты все внутренности по уму закрыл в привате такой проблемы даже не возникнет.
А если есть паблики, которые нужно вызывать из других мест(тебе же), но желательно недоступные другим программерам? Городить прокси/фасад? А так просто реализовал/извлек интерфейс, и отдал на пользование только то, что нужно.
E>> Разделение интерфейса взаимодействия и реализации — очень хорошая штука, на самом деле.
H>Вот только разделение выполняется не только интерфейсом, как языковой единицей. Модификаторы видимости суть то же самое разделение — все что публичное это твой интерфейс, все закрытое суть детали реализации к которым у тебя доступа нет и ничего с ними ты сделать не можешь.
Да, но модификаторы для всех одинаковы.
E>> Просто пойми, что не нужно работать с кодом как с текстом, и открывать в текстовых редакторах. Хотя в случае Си, и тем более плюсов, это труднее, так как даже при наличие ассиста проще открыть фаром, и не париться. Ну, потому и появились жабошарпы.
H>Код это и есть текст
Код есть структурированный тескт. И работать со структурой гораздо удобнее, чем с текстом. Хотя кому как, конечно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Eugeny__, Вы писали:
E__>>Если честно, то слабо представляю пользу в любых комментариях, кроме строчных.
MS>#if 0 — еще больший костыль.
т.е. на 3 символа больше вначале и на 3 в конце — это костыль?
Здравствуйте, McSeem2, Вы писали:
MS>Вот скажите мне, убогому, почему в C++ запрещены вложенные коменты вида /* */? MS>Есть этому хоть какое-то разумное объяснение? На мой взгляд — ни малейшего. Чистый идиотизм. Я помню в Turbo-C было можно. Даже в PL/I было можно, хотя компилятор выдавал предупреждения. Кстати, в этих ваших C# и Java — можно?
И слава богу
У меня есть несколько трюков условной компиляции, которые как раз на этом свойстве основаны.
Хотя #if/#endif по-любому прямее, единственное неудобство — что все эти инструкции как минимум две строчки занимают.
Здравствуйте, Eugeny__, Вы писали:
E> H>Имелся ввиду поиск по каталогам с файлами, где их может быть несколько тысяч.
E> У меня почему-то это ассоциируется с копанием в мусорнике. Что это за файлы и каталоги? Это проект? Ну дык открой его как проект. Я слабо представляю, что это может быть за свалка каких-то исходников.
У меня это огромное количество сторониих библиотек в исходниках (1.3Gb на сегодняшний день). Большую часть я вообще не использую в текущем проекте, но это не мешает мне посматривать в их код, чтоб посмотреть, "как оно там делается".
E> H>Все просто. RTF, помимо, собственно, текста, содержит нформацию для его форматирования. А вот исходники это plain text. Ваш К.О.
E> Исходники тоже ее содержат.
Э-э-э... #region? Не смешно.
E> H>Интерфейсы, не всегда применимы, иногда требуются именно классы, а то и вовсе процедуры и функции.
E> Примеры в студию.
Далеко ходить не нужно. http://www.xml-rpc.net/ там библиотека. Вся работа с библиотекой является работой с классами а не с интерфейсами. Я больше скажу, так практически везде
E> H>Так в чем проблема? Ему доступны только public методы + protected если он наследуется. Все внутренности закрыты в private и доступа к ним он не получит. Зато есть другой момент. Ты сам можешь допустить оплошность/недосмотр в проектировании, а человек со стороны скажет: "О! я смотрю у тебя есть приватный метод XX, неплохо бы его сделать доступным в потомках с целью увеличения гибкости". Это, кстати, не такая уж редкая ситуация.
E> Класс может реализовывать несколько интерфейсов. И для одного модуля он будет одной сущностью, а для другого — другой. Но объект при этом будет один.
Это и так понятно, я же не о минусах интерфейсов говорю.
E> А по поводу случая с тем, чтобы сделать приватный метод публичным... Ну это подход через жопу какой-то. Инициатива должна исходить не из кода, а из требований. Ну, то есть, подходит ко мне коллега, и говорит: Жека, слушай, ты можешь мне предоставить такую-то инфу? Я понимаю, что да, и даже метод у меня такой есть. Добавлю его в интерфейс. А то так все пооткрывать можно — гибкость будет потрясающая. И проект потихоньку будет превращаться в нечто очень сильносвязанное, и уже попахивающее.
Т.е. ты всегда проектируешь идеально? Тогда к тебе вопросов нет. У меня так не получается. Бывает, что вследствии рефакторинга кода, я сам многие методы из привата в паблик вытаскиваю т.к. удается взгянуть на проблему с другой стороны (те самые, блин, требования)
E> H>Если ты все внутренности по уму закрыл в привате такой проблемы даже не возникнет.
E> А если есть паблики, которые нужно вызывать из других мест(тебе же), но желательно недоступные другим программерам? Городить прокси/фасад? А так просто реализовал/извлек интерфейс, и отдал на пользование только то, что нужно.
Ты не думай, что я вообще против интерфейсов. Там где они выгодны — они и используются.
E> H>Вот только разделение выполняется не только интерфейсом, как языковой единицей. Модификаторы видимости суть то же самое разделение — все что публичное это твой интерфейс, все закрытое суть детали реализации к которым у тебя доступа нет и ничего с ними ты сделать не можешь.
E> Да, но модификаторы для всех одинаковы.
Да. Просто учитывай тот факт, что кому-то чаще работать приходится с классами нежели с интерфейсами.
E> H>Код это и есть текст
E> Код есть структурированный тескт. И работать со структурой гораздо удобнее, чем с текстом. Хотя кому как, конечно.
Я работаю со структурой (которую сам же и определяю) в текстовом редакторе
Здравствуйте, Lorenzo_LAMAS, Вы писали:
B>>Как там студия C# раскрашивает — сам изучай.
L_L>а почему это ты решил, что это С#????? L_L>За совет изучать что-то там — спасибо, рекомендую тебе заняться тем же.
Обознался, признаю.
У меня в 2005 никаких проблем с раскраской #if #endif нет.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Здравствуйте, WolfHound, Вы писали:
WH>>Это очень удобно для того чтобы закомментировать кусок кода в котором уже есть комментарии.
VV>Так делать — дурной тон. Читаемости коду оставленые тобой обгрызки непонятно чего не добавят. Не нужно — смело удаляем. То, бесценное творение, что ты хотел закомментировать можно забрать из системы контроля версий.
Я уже раз обжигался на выбрасывание у себя в САПРе КД. Было сказано переделать кусок
разводки, а потом оказалось, что конструктор должен определять, по какому пути идти.
Хорошо, что старый вариант остался в архиве. Так что приходится кучу мест
комментировать из-за постоянной чехарды изменений в требованиях объемного монтажа.
Наверняка хотели попроще — вот начался коммент и все, скипать все, что внутри, пока не найдем */ и плеваааать на всякие там вложенности 
]
