Здравствуйте, eao197, Вы писали:
E>Смотря какая программа. Если программа не обращается к WinAPI, то почему бы и нет.
"в общем случае" я для кого писал? В любом случае смысла в работе программы для Windows на стиральной машинке не много.
E>Заблуждение.
А объяснения? Или будем просто так друг друга дураками обзывать?
E>Если платформа поддерживает стандарт POSIX, то ее изучение может существенно упроститься.
А если нет? И намного ли? Смысл новой платвормы в том что в ней есть что-то новое, т.е. выходящее за рамки стандарта. Много стиральных машинок поддерживают POSIX?
Здравствуйте, Left2, Вы писали:
L>Не скажи, толк есть.
L>1. Есть довольно много базовых библиотек написаных на чистом C которые с минимальными усилиями прикручиваются на любую платформу — jpeglib, libzip, и т.д. Наличие таких вещей очень сильно облегчает (и удешевляет) разработку.
L>2. Наличие стандартизованного языка позволяет довольно большие части системы, не завязанные на платформу, тестировать и отлаживать на программерском PC. Это тоже порядком ускоряет разработку.
L>Ну и в целом наверное ноги у пунктов 1 и 2 растут из одного и того же места
В целом согласен.
Но для того чтобы использовать эти библиотеки, система не обязана быть написана на C. =))
Здравствуйте, vdimas, Вы писали:
V> ... Я просто показал как можно на С++ эмулировать замыкания с помощью функциональных объектов. Разумеется, лучше пусть за нас эту работу делает компилятор...
Типичная ситуация на мой взгляд. Если на C++ нельзя что-нибудь сделать при промощи специально предназначенных для этого средств языка, то это как правило все-равно можно сделать, хотя бы и с заднего входа. На каком еще языке есть аллокаторы?
Здравствуйте, Zuka, Вы писали:
Z>"в общем случае" я для кого писал? В любом случае смысла в работе программы для Windows на стиральной машинке не много.
Дело в том, что понятие "общего случая" в вопросе о портировании программы на другую платформу это... Ну не подходит это понятие, поскольку, когда реально приходится свою программу на новую платформу тянуть, то нет общих случаев Одни частности в виде очень часто разбросанных граблей, да еше в темной комнате, да еще в поисках черной кошки
E>>Заблуждение. Z>А объяснения? Или будем просто так друг друга дураками обзывать?
Первое заблуждение: "Так что доступность языка на любой платформе имеет очень низкую ценность." Если у меня на языке C написана система в N сотен тысяч строк, то отсутствие на нужной мне новой платформе языка C будет означать, что все эти N сотен тысяч строк идут в /dev/null, а всю систему для этой платформы придется переписывать заново. Причем, если существующий язык будет сильно отличаться от C (например, если потребуется использовать Java), то значит придется не просто переписывать под кальку, а перепроектировать с учетом идеологии Java.
Второе заблуждение: изучить новый язык проще, чем новую платформу. Могу ответственно заявить, что изучение C и даже Ruby (не говоря уже про C++) в достаточной степени, чтобы писать на них серьезный production код, не опасаясь случайно занесенных в программу косяков (по элементарному) -- дело не одного месяца.
E>>Если платформа поддерживает стандарт POSIX, то ее изучение может существенно упроститься.
Z>А если нет? И намного ли? Смысл новой платвормы в том что в ней есть что-то новое, т.е. выходящее за рамки стандарта. Много стиральных машинок поддерживают POSIX?
За стиральные машинки сказать не могу.
Но вот встраиваемые системы на основе Linux или других клонов Unix-а от POSIX-а не так уж далеко ушли.
И на счет смысла новой платформы. Новых программных платформ не так уж и много. Из того, что у меня на слуху -- это различные варианты Linux-а и Unix-ов (BSD, Solaris, HP-UX, AIX, Darvin), Windows и Windows CE, Symbian OS, Palm OS (состояние которой оставляет больше вопросов), HP NonStop Kernel и различные real-time OS для встраиваемых систем (которые так же во многом растут из Unix-ов), и совсем уж специфические j2me платформы для смарт-карт и прочей мелюзги . Разработка новой программной платформы -- это слишком фантастический шаг, на который мало кто отваживается. Более реальный сценарий -- это создание новой аппаратной платформы и адаптация к ней уже существующей программной среды (про портирование Linux-а или NetBSD на разные новые платформы лично я слышу чаще всего). И стандарт POSIX как раз предназначен для того, чтобы OS на разных аппаратных средствах предлагала прикладным программам и пользователям один и тот же интерфейс.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AndrewVK wrote: > A>sourceforge имеет сервер с cvs на портах 80 и 443 (http/https), > которые открыты на firewall'ах > Эээ, как бы тебе объяснить. Вобщем частенько ситуация такая — есть > только http-прокси и настроить ее нельзя. Так вот — через нее к CVS не > сходишь. А фаерволы да, таким манером обойти можно.
А как раз для таких людей у них есть ежедневные CVS-snapshot'ы.
ANS>Хватит, он и так слишком детален. Ведь на самом деле задача одна — написать эффективную программу, то есть ту которая утилизирует все доступніе ресурсы. Например, программа под дос — может использовать только 640К (я немножко упрощаю, конечно) и один проц. А у нас есть 2 проца и один гиг. Значит это малоэффективная программа. А эффективной, в данных условиях, была бы программа, которая утилизировала оба проца, весь гиг физической памяти, и пару — виртуальной. При том, если программа утилизирует каждый проц меньше чем на 100% это минус программисту, и на этот процент и должна уменьшаться его зарплата. Если ваша программа не способна утилизировать проц более чем на 1-2%, то вам стоит задуматься о своей профпригодности.
Попробуйте проверить это утверждение на программах, не являющихся компиляторами и не считающих pi с точностью до N знака, а работают с устройствами ввода/вывода (сеть и/или диск) например на дефрагментаторах...
Здравствуйте, Шахтер, Вы писали:
Ш>Ну, вообще-то это достаточно сложно устроенные внутри функции. Ш>Фактически, printf -- это простейший интерпретатор строки формата.
gcc, например, умеет оптимизировать и разворачивать его примитивные использования:
а ля,
Здравствуйте, vdimas, Вы писали:
VD>>У функциональщиков как раз есть замыкания и "массы очень коротких" функций они объявляют по месту используя контекст методов в которые они вложены.
V>Чего гадать? Возьми любые исходники на Схеме ...
Спасибо за бесценный совет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> ... Не "с заднего входа", а "через задний проход".
Это да. Зато если в C# аллокаторы не предусмотрены, то определить их не получится ни через задний, ни через какой. Или unsafe дает какую-нибудь возможность?
Здравствуйте, igna, Вы писали:
I>Это да. Зато если в C# аллокаторы не предусмотрены, то определить их не получится ни через задний, ни через какой. Или unsafe дает какую-нибудь возможность?
На фиг не упали никакие "аллокаторы" в языках с ЖЦ. ЖЦ порвет все "аллокаторы" как Тузик грелку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
igna wrote: > Это да. Зато если в C# аллокаторы не предусмотрены, то определить их не > получится ни через задний, ни через какой. Или unsafe дает какую-нибудь > возможность?
В теории — дает. В unsafe можно использовать указатели на объекты вне
GC-кучи. Вот только все объекты вне GC-кучи рассматриваются как
opaque-type'ы, и работать с ними будет ооооооочень неудобно.
VladD2 wrote: > I>Это да. Зато если в C# аллокаторы не предусмотрены, то определить их > не получится ни через задний, ни через какой. Или unsafe дает > какую-нибудь возможность? > На фиг не упали никакие "аллокаторы" в языках с ЖЦ. ЖЦ порвет все > "аллокаторы" как Тузик грелку.
Ага, точно. "Нам думать не надо — MS уже подумала за нас! Ураа!"
Здравствуйте, vdimas, Вы писали:
V>Чего гадать? Возьми любые исходники на Схеме чего-нить (полно в сети) да посмотри. Локальные замыкания в Паскалевском стиле не так уж часто используются.
Берем slib и находим там эти самые локальные замыкания сотнями. А те исходники (которых полно в сети) скорее всего написаны бывшими сишниками.
Здравствуйте, VladD2, Вы писали:
VD>На фиг не упали никакие "аллокаторы" в языках с ЖЦ. ЖЦ порвет все "аллокаторы" как Тузик грелку.
Аллокаторы это еще и возможность персистентно хранить контейнеры в файлах используя file mapping, что может использоваться в словарях и энциклопедиях. В таких программах данные нередко read only, сами программы однопользовательские, базы данных тут явно из пушки по тараканам.
Здравствуйте, igna, Вы писали:
I>Аллокаторы это еще и возможность персистентно хранить контейнеры в файлах используя file mapping, что может использоваться в словарях и энциклопедиях. В таких программах данные нередко read only, сами программы однопользовательские, базы данных тут явно из пушки по тараканам.
а потом понадобится портировать прогу на другую платформу — и всё, понеслась...
Здравствуйте, Дарней, Вы писали:
I>>Аллокаторы это еще и возможность персистентно хранить контейнеры в файлах используя file mapping, что может использоваться в словарях и энциклопедиях. В таких программах данные нередко read only, сами программы однопользовательские, базы данных тут явно из пушки по тараканам.
Д>а потом понадобится портировать прогу на другую платформу — и всё, понеслась...
Ты издеваешься? Перенос на платформу, которая поддерживает file mapping потребует изменения только кода аллокатора (это будут доли процента от общего объема кода). А если работа с file mapping изначально была реализована не в ручную, а с помощью кросс-платформенной библиотеки, тогда вообще нет проблем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ты издеваешься? Перенос на платформу, которая поддерживает file mapping потребует изменения только кода аллокатора (это будут доли процента от общего объема кода). А если работа с file mapping изначально была реализована не в ручную, а с помощью кросс-платформенной библиотеки, тогда вообще нет проблем.
праавда? А то, что бинарные внутренности контейнера на другой платформе могут быть совсем другими — это ничего? И всё, прощай совместимость сериализованных файлов.
Мне как-то раз уже приходилось исправлять последствия таких художеств
Правда
Д> А то, что бинарные внутренности контейнера на другой платформе могут быть совсем другими — это ничего? И всё, прощай совместимость сериализованных файлов.
Это уже второй вопрос
Ведь речь могла идти и о совместно работающих процессах на одной машине -- им ведь так же данными обмениваться нужно. Тогда вопрос о совместимости не столь актуален.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
