Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Да, заимствование определенно не из C++, но особых... 22.08.07 20:12 Число просмотров: 5633
Автор: amirul <Serge> Статус: The Elderman
|
> Нет, в TP была своя схема объектных модулей (юнитов). Фокус
> был в том, что интерфейс и реализация объявлялись в одном
Да, заимствование определенно не из C++, но особых преиуществ (как и недостатков) такой системы не вижу. В C/C++ интерфейс физически вынесен в отдельный файл, здесь он просто логически отделен внутри одного файла. Во всяком случае этого недостаточно для того, чтобы говорить о том, что паскаль в отличие от плюсов - модульный.
> > Что такое оптимальная перекомпиляция? Ни гугль ни
> яндекс не
> > знают о таком.
>
> В Си любое изменение в .h файле приводит к перекомпиляции
> всех модулей, которые включили этот .h. Turbo Pascal же (и
> Delphi) проводил минимальную необходимую перекомпиляцию -
> это опять же упирается в его двичные форматы. Сейчас
Если меняется интерфейсная часть юнита в паскале, приходится ли перекомпилировать все файлы, использующие этот юнит? Скорее всего да. Это всего лишь говорит о том, что не стоит пихать все свои интерфейсы в один h-файл.
> подобные фокусы могут делать какие-то очень крутые
> Си-компиляторы, но в мейнстрим такая практика так и не
> вошла.
Да нет. Это не фокус. Один h-файл считается интерфейсом ОДНОГО модуля. Если меняется интерфейс, то все исходники, использующие (в т.ч. и реализующие) данный интерфейс необходимо перекомпилировать. Просто не стоит складывать все яйца в одну корзину и все.
> > Ну а в *NIX получится штук 20. Это не считая
> > бэкапа/рестора, подключения дополнительных хайвов,
> > использования удаленного реестра и пр.. Они появились
> не по
> > прихоти - кому то это понадобилось.
> В UNIX не получится 20, потому что они там уже есть. Бэкапы
Не совсем так. По аналогии с перегрузкой функций, даже если у функции одно и то же имя, но различные входные аргументы, физически они все равно остаются разными. Иногда такая перегруженность помогает, но все равно нужно помнить тонкости семантики при работе с разными типами "файлов".
> и удаленный доступ тоже получаются автоматически как с
> обычными файлами (tar, NFS), а в Windows для обеих функций
Ах да, в *NIX толком нет блокировок (flock-и это не блокировки - а ХЗ что), поэтому можно изменять, удалять и пр. совершенно не заботясь о тех, кто в данный момент читает или даже тоже изменяет тот же файл. Не знаю, может это и хорошо, но я видел слишком много race-ов чтобы так легкомысленно подходить к проблемам синхронизации.
> пишутся специфичные сервисы и специфичные GUI - еще один
> прекрасный пример раздувания задачи из ничего.
Да нет, backup/restore - это такой способ обхода блокировок. И я бы не сказал, что блокировки - это блажь.
> Но я уже хорошо знаком с write(), и мне не надо
> перечитывать документацию. В Windows же, мало того что надо
Да нет же. Вы помните семантику write-а при работе с plain файлом. Нигде не гарантируется, что она будет одинаковая для всех файлов, реализующих этот интерфейс. Более того, желание запихнуть в файлы совершенно все - это как раз и есть тот самый "golden hammer"
> помнить или же всякий раз заглядывать в документацию, плюс
Лично мне всегда хватает IntelliSense-а из IDE.
> к этому семантика этих функций тоже нетривиальна, что тоже
Она тривиальна, так же как и для write-а, но в случае с write-ом на одном названии висит целая куча (пусть и тривиальных) семантик. Не факт, что это вызовет проблемы, но не вижу чем раздувание семантики одного слова лучше раздувания количества слов.
> абсурд. Мне бы очень не хотелось загружать мозг такими
> пустяковыми вещами - у мозга ресурсы ограничены.
Вы загружаете мозг другими пустяковыми вещами :-)
> Я не понял почему нужны еще вызовы и почему утилиты не
Создание файла и создание каталога - разные вызовы.
> будут работать. Для утилит - это файлы, и им нет дела до
> того, что драйвер на самом деле отводит каждому файлу не
> полкило на диске, а гораздо меньше.
Я не о том сколько места. Я о том, что Вы посчитали неразмным хранение ключей и значений (директорий и файлов) и предложили обойтись одними директориями, которые могут иметь значение. Ни одна cmdline утилита не ожидает от директории такой подлости, и следовательно работать не будет.
> В статье я, правда, упустил enum, который в терминах FS на
> UNIX - это функции <dirent.h>, тоже знакомые. Ничего
> страшного.
Согласен, ничего. Но в конце концов интерфейс работы с UR будет не меньше 20 функций. Не так уж и меньше, чем в Windows варианте.
> В Майкрософте сидят не дураки - это самый плохой аргумент в
> защиту Майкрософта. А за раздуванием API кстати, стоит
Это не аргумент в защиту, это констатация факта, о котором почему то принято забывать (или более того, считать истинным противоположное утверждение). Жирный интерфейс никто не заставляет знать полностью, можно использовать его подмножество и реализовывать велосипеды самому. А вот если интерфейс неполный, то никакого выбора уже не остается: чего то не хватает - пиши сам.
> маркетинговый трюк, который заставляет людей посвятить себя
> целиком ихним технологиям, потому что ресурсов и времени на
> изучения "чужих" у программиста уже не остается. Этот
Мягко говоря необоснованное утверждение. Точно так же можно утверждать, что неполный *NIX интерфейсы - это способ привязки программистов, заставляющий их все свое время посвящать реализации необходимых велосипедов, а не учить что то другое, или не дай бог программировать.
> AJAX - это способ посылать HTTP запросы прямо из браузера,
> и XML тут вообще не при чем.
Строго говоря способ посылать запросы это XML-HTTP, а AJAX это JavaScript + XML-HTTP, но дело не этом. А в том, что XML стал интернет стандартом и первая рекомендация противоречит второй.
> XML по сути - это формат для записи древовидных структур
> данных. Во-первых в нем нет необходимости когда нет дерева,
Не дерева, а структуры. Есть только один неструктурированный текстовы тип данных - raw text. Для всего остального XML пригоден.
> и во-вторых его синтаксис избыточен. Например лиспоподобный
> синтаксис уже выглядел бы лучше и компактнее, его легче
> было бы парсить и легче редактировать вручную.
Не факт
> Шаблоны Си++ ухудшают читабельность, потому что их сложно
> понимать. Ими можно делать очень крутые фокусы, но в
> продакшн надо использовать в очень сдержанном количестве.
> Вобщем, это мнение не ново и не оригинально.
В целом согласен, но согласитесь, это немного более сдержанная формулировка, чем "никаких шаблонов и метапрограммирования".
> DCOM - это надстройка над RPC. Все бы ничего, но он слишком
> привязан к Access Rights в Windows, из-за чего возникает
> много мороки. Плюс его очень трудно или почти невозможно
Если не предполагается кросплатформенность, то никаких проблем с виндовыми правами нет.
> файерволить - вместо этого приходится открывать чуть ли не
> все порты. Нет возможности "общаться" через прокси, как в
> HTTP.
Уже ответили.
> О преимуществах HTTP: длинная история, для этого и правда
> нужна отдельная статья.
Мне этого говорить не надо :-) Я с этим и не спорю.
> Эта цитата о том, что большие системы должны быть разбиты
> на небольшие куски - вот и все. Из современных компиляторов
> только Си++ очень большой - так это говорит не в пользу
> языка. Turbo Pascal 5-ой версии занимал 70 килобайт (!),
> когда как сишные компиляторы - это мегабайты и даже десятки
> МБ.
Самый крутой язык - brainfuck? Тот вообще меньше килобайта весит
|
|
<site updates>
|
Клиника плохого кода 22.08.07 12:55
Publisher: dl <Dmitry Leonov>
|
Клиника плохого кода
Овик Меликян http://www.melikyan.com/dalshe/
Исходный код программ, которые создают программисты во всем мире, по качеству можно разделить на четыре категории: хороший код, плохой, ужасный и с трудом компилируемый хаос.
В последнее время мне пришлось иметь дело с исходным кодом одной исключительно, адски плохо спроектированной и хаотически реализованной программы, которую в течение шести лет писали люди, едва ли имеющие отношение к программированию, если забыть об их дипломах в Computer Science из разных авторитетных университетов мира. Все что должна была делать эта программка - это копировать файлы с одной Windows-машины на другую. Эта задача была решена в 80,000 строк кода на Си++ (функциональная часть) и в 55,000 строк кода на VB (GUI часть). Компиляция порождала примерно 10 файлов: 6 EXE и 4 DLL. На одном конце устанавливались 3 системных сервиса и две COM компоненты, а на другом - 2 сервиса, одна COM компонента и собственно графический интерфейс для управления этим монстром.
...
Полный текст
|
|
ИМХО, в статье ничего нет, кроме неаргументированной рекламы... 18.03.08 12:50
Автор: Estellehtaon Статус: Незарегистрированный пользователь
|
|
ИМХО, в статье ничего нет, кроме неаргументированной рекламы unix. Понятно, что есть плохой код и хороший код. Но чтобы писать хороший код совсем необязательно отазываться от программирования под винды. В любой операционной системе можно написать как плохой, так и хороший код. Конкретных же рекомендаций нет, только их обрывки.
|
| |
Re: ИМХО, в статье ничего нет, кроме неаргументированной рекламы... 09.05.08 17:50
Автор: Линда Кайе Статус: Незарегистрированный пользователь
|
|
Верно замечено. Особенно смутил упрощённый подход к реестру и вывод из этого что уж в UNIX оно было бы намного проще. А уж как по XML автор проехался, заявив, что это всё плохо, а загадочные текстовые файлы в стиле UNIX - это хорошо. W3C тихо плачет в уголке.
|
|
Опечатка в тексте 28.08.07 09:41
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
|
Вот в этом параграфе:
"Продолжая в том же духе, шаг за гашом, анализируя свои привычки и стиль, вы сможете привести его в гораздо более удобоваримый для нас, homo sapiens, вид."
За чем шаг? ;)
|
| |
fixed, спасибо 28.08.07 10:07
Автор: dl <Dmitry Leonov>
|
|
|
| | |
очепятка "по Фрейду"? ;-) 29.08.07 16:49
Автор: leo <Леонид Юрьев> Статус: Elderman
|
|
|
|
Даже хочется поблагодарить за тему. Сам хотел поднять... 23.08.07 13:04
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Клиника плохого кода
> Овик Меликян http://www.melikyan.com/dalshe/
Даже хочется поблагодарить за тему. Сам хотел поднять подобную, но все с мыслями не соберусь.
Сначала хочется сказать о маленьком минусе статьи, чтоб не забыть - тему Виндового реестра следовало бы вынести отдельно, как и все то, что не относится к программизму в чистом виде.
Среднее арифметическое неудачный пример из-за своей простоты и специфики. Здесь я бы аппонировал следующим правилом, самым первым, которому учат новичков: Правильно выбирайте тип переменной, так, чтобы при работе программы все возможные ее значения с запасом могли храниться и участвовать в вычислениях ("int", "long", "float", "double", ...)! Но не используйте "float" везде, особенно там, где достаточно будет "int".
Если уж писать про корни квадратного уравнения, то надо быть последовательным и не останавливаться на полпути, а то в статье упоминается про idiot proof, неочевидность результата и "поводные камни", связанные, что программист (как шахматист) не предусмотрел возможные варианты. Корни не всегда могут быть действительными. "Корней нет" - это "начальная школа". Надо бы чуть доработать статью. Наверняка в интернете можно найти всю инфу, которая покажет, насколько сложно написать программу вычисления корней кв. ур. без ошибок, что у многих кодеров волосы дыбом встанут и они почуствуют себя на месте микрософтовских программистов.
Ругают статью наверняка программеры, которых задело "за живое", которые себя узнали. Я похвалю, потому что читал статью как пользователь. Точнее не пользователь, пользователи в организациях сами с кривыми программами не борятся, они сразу к автоматизаторм обращаются, когда программа ведет себя неадекватно (выдает неожиданно непредсказуемый результат) в ответ на введеную информацию, характер которой не был предусмотрен программистом.
Когда я хотел поднять аналогичную тему, то думал о чуть другом, а именно не о том, что в программе не предусмотрена реакция на "внештатные" данные и результат ее неадекватен, а о скорости ее реакции. Порой программы слишком "тормозные", причем настолько, что это шокирует. Чаще всего я сталкивался с тормознутостью экономическими баз данных.
Я когда-то школьникам рассказывал - Соверменный процессор действительно может выполнять около двух простых арифметических операций за один такт, то есть 500Мгц проц может сложить 1000000000 чисел в секунду! Если записать эти числа в столбик, то высота этого столбика получится 10000000 метров или 10 тысяч километров, если число будет примерно сантиметровой величины. Сколько нужно человеку времени, чтобы проделать такое вычисление даже если он будет вооружен калькулятором? Так вот решение на таком компьютере определенных экономических задач занимает от нескольких десятков минут до нескольких часов времени в зависимости от разработчика ПО и загруженности базы. Я уверен, что вооружившись калькулятором, я бы обогнал компьютер, хотя комп должен был бы решить эту задачу за микросекунду. Как программерам удается писать такие тормозные программы?
|
| |
Абсолютно согласен. Но у меня даже желание как-то слабо выражалось. В действительности тема хороша, но реализация заставляет рыдать (. Чего стоит, уже разчавканный в комментах "пример про среднее". Суть: плохо плохо писать о плохом ;) 23.08.07 20:54
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | |
Ну не стОит так драматизаровать. Мне думается, что не взирая... 24.08.07 12:05
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 24.08.07 12:06 Количество правок: 1
|
Ну не стОит так драматизаровать. Мне думается, что не взирая на количество любых комментариев, как минимум один из трех задумается и сделает выводы, а это не так уж и мало в рядах программеров зоны ".ru".
Я, признаюсь, как то давно книжку купил, в которой описывались и "правила хорошего тона", и предостережения от ошибок, связанных со стилем, и аргументированно, хотя и не навязчиво объяснялось почему нужно именно так или подобным образом, а другим не следует. Ну приведу самый из "детских" примеров: "Нужно быть осторожнее с классами, одним из свойств которых является указатель, особенно на динамически выделяемую память. Нужно обязательно не забыть реализовать и оператор присваивания, и иницилизацию объектом этого же класса и ...". Книжка не с собой, ее реквизиты потом могу сюда вписать.
Сам за собой не уследишь, надо у юзеров спросить - сколько раз за последний год я горорил "Тем, кто писал эту программу, надо руки поотрубать", "Вешать надо таких программеров за ноги", а бывает и другая любимая фраза "Таким гениям нужно памятник при жизни ставить". Что поделать, без некоторых программ никуда, некоторые навязывают использовать без возможности выбора альтернатив, вот и приходится всеми правдами и неправдами биться с "ветрянными мельницами" и плясать с бубнами, чтоб заставить какую-то прогу работать. Пользователь то он в программировании не рубит, а для руководителя чем программа жирнее и дольше думает, тем она круче, дороже, ценнее. Когда же сам такое видишь, то стыдно немного становится, за людей, которые, видимо, не своим делом занимаются. Давайте писать красиво, во всех отношениях. Давайте писать качественно, на совесть. Давайте думать о тех, кто потом будет использовать эту программу.
|
|
*****!!! 23.08.07 05:54 [DamNet, Heller]
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| |
А можно подробнее? 23.08.07 16:47
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | |
5 респектов. 24.08.07 03:39
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| | |
Мат на форуме запрещен ). Имхо - у хороших авторов есть читатели, а у плохих - комментаторы. (т.е. кол-во сообщений кроме короткого "спасибо!" прямопропорционально кривизне статьи) 23.08.07 20:51
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | |
С имхо - полностью не согласен. Коротко и красиво ответить не смогу, поэтому рекомендую почитать АБС "Хромая судьба". Там этот вопрос подробно рассмотрен. Там где про Сорокина 24.08.07 17:03
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | | | |
Не согласен с несогласием ) Почитай Сократа. Тот поди постарше будет. И признан до сих пор. 15.09.07 20:38
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | | | |
Не согласен с Сократом. Он Стругацких не читал. :)) Опять же, кто сказал, что Сократ умнее каждого из нас? ;) 16.09.07 00:10
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| |
лаконично и понятно 23.08.07 07:38
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
|
[off] Очень понравилось предложение "Компиляция порождала примерно 10 файлов: 6 EXE и 4 DLL." 22.08.07 20:27
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 23.08.07 12:14 Количество правок: 1
|
|
|
|
Ну просто отлично. Я в шоке 22.08.07 18:49
Автор: smartov Статус: Незарегистрированный пользователь
|
Ну просто отлично. Я в шоке
>>int avg(int a, int b) { return a + (b - a) / 2; }
С каких пор int при делении на 2 стал на результате всегда выдавать int. Или средним арифметическим из 1 и 2 является int? О каких чужих ошибках мы тут говорим, когда свои не видим, еще и других пытаемся учить.
Более того, вместо того, чтобы не морочить себе и читателям голову с кучей условий
float my_avg(float a, float b) { return a/2 + b/2; }
и все! Никаких 28 условий! Никакого переполнения.
Статье незачет.
|
| |
Я бы вам не доверил реализацию двоичного поиска, например -... 22.08.07 19:51
Автор: crontab Статус: Незарегистрированный пользователь
|
> float my_avg(float a, float b) { return a/2 + b/2; }
Я бы вам не доверил реализацию двоичного поиска, например - а там как раз нужно постоянно вычислять среднее двух индексов. a/2 + b/2 - это было бы катастрофой для алгоритма, который должен быть очень быстрым. А надо бы представлять вообще во что это компилируется. Незачет :)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
