Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Есть закон неограниченности потребностей. В том плане, что... 26.12.03 14:53 Число просмотров: 1895
Автор: amirul <Serge> Статус: The Elderman
|
> а зачем все время сменять? есть монитор под OS1 и...
> скажем, OS2 ;) и под платформы. надо что-то дописать -
> дописывается. переносить смысла не вижу.
Есть закон неограниченности потребностей. В том плане, что потребности постоянно меняются. И именно потому, что можно убить два года на проект средней крупности, а он уже будет не нужен появилось eXtreme Programming. Это не только в программировании есть. Любая система, которая пытается останвится в развитии очень быстро начинает деградировать.
> именно. да я вообще с линуксом дел не имею и стараюсь не
> иметь... мне компромиссы не по душе. ;) (личная точка
> зрения)
Ой ли. Компромиссы не по душе. А по моему обычный снобизм фрибсд-шников. :-) Я тут недавно ссылку кидал с реальными бенчмарками фри и линуха. Не в пользу BSD-систем вообще кстати (хотя фря из BSD систем действительно оказалась лучше всех)
> я и не собирался об этом говорить, я не настолько повернут
> на девелоперстве. слова твои понятны поодиночке, а в
Я тоже не повернут, между прочим. Не такие уж это и сложные понятия. Ну да ладно. :-)
> когда во время компиляции и даже выполнения контролируются
> допустимые значения для переменных? да кто ж с этим
> поспорит, только до стандартного стародоброобучающего
> паскаля си все равно не дотягивает в этом контроле - во
> всяком случае ощущение правильности исходника у меня
> отсутствует. си, т.о. не изящен и нечитабелен. объявить int
> x и присвоить ему 'a' - ну где еще такое проканает, кроме
> сей. также радует и логический тип задавать целочисленным,
> опупенный расклад, особенно если вспомнить о разнице
> выполнения операций NOT, AND, OR, XOR etc над логическими и
> цифровыми величинами.
Написал же. Что и там не без косяков, большинство из которых запросто обходятся в самом C, а в C++ уже внесены в язык.
> я думаю именно на выходе твоего компилятора получается
> чрезмерная избыточность кода, когда 100 байт инструкций
> обрамляются 100 килобайтами MFC и прочей срани.
Не обязательно линковаться с MFC, необязательно линковаться даже с рантаймом.
> и комментариям ты тоже не обучен? ;)
Ага. Комментировать каждый цикл, если это можно выразить средствами самого языка. Кстати, все более-менее сведущие программисты говорят, что этот вид комментариев - один из самых плохих. Не стоит комментировать то, что выражено в самом языке:
a = b + c; // Заносим в a сумму b и c
---
> а, мышление функциями, одна из убогостей сишного взгляда на
> программирование, в ассемблере нет функций вообще. хотя
> скорее тут расхождение во мнениях терминологическое, если
> не думать о том что скорее всего ты забываешь, что
> результат функции - одна величина некоторого типа,
> результатом процедуры может быть от нуля до множества
> величин.
Точно так же деление вызвов на процедуры и функции - одна из убогостей паскалевского взгляда на вещи. А функциональная декомпозиция - всего лишь один из шагов в ЭВОЛЮЦИИ методологии программирования. Скажу лишь, что вся эта эволюция сводится к уменьшению зависимостей между частями программы. В объектной декомпозиции связей еще меньше.
> фетиш и на деле действительно - на мой взгляд -
> оправдывается только если приносит удовольствие автору.
Вот с этим, пожалуй, соглашусь.
> всегда хуже - как минимум из-за обрамления ненужными
> кусками двоичного кода в объектных и исполняемых файлах,
Либы можно не подключать, стековые фреймы не генерировать. Тогда C просто превратится в асм. А вот асм в C не превратится никогда.
> ненужной масштабируемостью, и прочей фигней, которую даже
> днем с огнем всю не выключишь. я сейчас говорю на примере
> борландовского и мелкософтовского компилятора, про другие
> тонкостей не помню.
Не уверен, что Вы знаете тонкости борландовского и мелкософтовского компилятора, раз говорите такое.
> > зачастую и лучше) человека. В самых крайних случаях
> есть
>
> ну если настолько неграмотен человек - место ему в
> вебмастерах, а не в программерах.
Ой ли. Паровать инструкции и выравнивать по границе кеш-строки в 100000 строках ИМХО лучше это удовольствие оставить компилятору. А ведь это МИНИМУМ, который делает оптимизирующий компилятор. Мне когда то пытались привести в пример VTune, который ищет возможности для оптимизации и говорит человеку, что подправить. Вот только до сих пор не понимаю зачем в этой цепочке человек.
> > inline-ассемблер.
> об этом и речь. про тот же монитор можно уверенно сказать
> что наиболее популярные проверяющие циклы он крутит не
> эффективно из-за пренебрежения такой возможностью, лени, а
> возможно и простой неграмотности разработчиков.
А вот тут не согласен. Преждевременная оптимизация - корень всех бед. НАЧИНАТЬ ручную оптимизацию следует только после того, как программа основательно погонялась под профайлером и выявлены РЕАЛЬНЫЕ бутылочные горлышки.
> > на марафонных дистанциях (>1000 строк) компилятор
> всегда побеждает.
>
> в скорости и комфорте разработки, но не в результате.
Именно в результате.
> типичная беда нашего времени - сделать все впопыхах.
> сграбить фильм с DVD, неэффективно пожать его в divx, криво
> перевести название на русский язык и записать его
> траснлитом в имя файла - утверждая что компилятор всегда
> побеждает. смешно.
Эх. Чем-то мне эта дискуссия напоминает Urix-а. Тот тоже любил заявлять что со времен PDP ничего хорошего не придумали. И все только деградирует. Смею предположить что Вы уже весьма немолоды и как следствие боитесь новизны.
> настолько же нелепо делать гуй из монитора, которому
> сервисом положено было бы работать, а темы XP лепить в виде
> сервиса.
Не будет спорить о необходимости гуя вообще. Скажу лишь, что XP, где графическая подсистема вынесена в ядро, работает все таки быстрее чем X.
> PS. ну и опять же повторюсь - мы только о проблемах
> девелоперов рассуждаем, а проблема юзера в том что он зазря
> гоняет байтики в памяти по причине ленивой криворукости
> девелопера. я в своих попытках что-то сдевелопить поражаюсь
Ленивость и криворукость девелопера между прочим никак не относится к удобству среды разработки. Можно даже сказать наоборот: чем удобнее работается девелоперу, тем лучше будет юзеру в конце концов.
> тоже, я бы с большим удовольвием отредактировал конфиг
> фаром - по образу и подобию того как я редактирую фаром
> конфиги freebsd.
Поздравляю. Во первых не забывайте о позиционировании. Во вторых вспомните, сколько всего вынесено в реестр (опять таки не станем спорить зачем столько настроек) и подумайте с какой скоростью выполнялся бы поиск по текстовой базе. Реестр - это база данных. А БД для эффективной работы просто обязана быть бинарной.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
