информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Spanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Есть закон неограниченности потребностей. В том плане, что... 26.12.03 14:53  Число просмотров: 1721
Автор: 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.
Поздравляю. Во первых не забывайте о позиционировании. Во вторых вспомните, сколько всего вынесено в реестр (опять таки не станем спорить зачем столько настроек) и подумайте с какой скоростью выполнялся бы поиск по текстовой базе. Реестр - это база данных. А БД для эффективной работы просто обязана быть бинарной.
<site updates> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach