![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Мозголомающие средства разработки.
После недельного писания на F# появилась идея, отчего использование дельфи так часто вырывает мозг программистам.
Суть в том, что дельфи это законченный продукт с замкнутым комьюнити. Собственно говоря, для работы на нем ничего кроме самого дельфи и нескольких сторонних компонентов (которые никуда больше и не пригодны) не нужно. Соответственно, у программистов тупо не было стимула выглядывать за пределы своей песочницы. В дельфи было все, необходимое и достаточное, чтобы писать всякого рода опердень в то время. Причем в силу простоты - это еще и стимулировало индивидуальное вкалывание, нахрен нужна какая-то командная разработка, какие-то процессы и прочие атрибуты, если один человек мог спокойно сделать достаточно немалую софтину.
Сишные и С++ либы, опять же, не подключались без извращений типа "завернуть в dll с plain C интерфейсом".
Сколько я не смотрю на другие средства разработки - там обязательно есть какая-то шиза на тему того, что невозможно пользоваться, не вкурив штук пять смежных областей. Тот же дотнет - это просто страшная сборная солянка из XML, веба, рефлекшена с кодогенерацией, хитрожопого ООП, причем некоторые вещами оттуда до сих пор проще переписать чем использовать готовые.
Послушаешь![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
zabivator и прочих про ocaml - это просто гамон, какие-то сишные компиляторы, какие-то либы, портирование между виндами и линуксами и прочий мрак.
Жаба энтепрайзная тоже страх какой-то, судя по количеству фреймворков, методик взаимодействия с внешним миром и прочего.
Т.е. все другие платформы ориентированы или на работу в команде с разделением труда или на знание множества смежных шизов, что в любом случае не дает окопаться в песочнице и 20 лет самостоятельно пилить одну и ту же опердень.
Суть в том, что дельфи это законченный продукт с замкнутым комьюнити. Собственно говоря, для работы на нем ничего кроме самого дельфи и нескольких сторонних компонентов (которые никуда больше и не пригодны) не нужно. Соответственно, у программистов тупо не было стимула выглядывать за пределы своей песочницы. В дельфи было все, необходимое и достаточное, чтобы писать всякого рода опердень в то время. Причем в силу простоты - это еще и стимулировало индивидуальное вкалывание, нахрен нужна какая-то командная разработка, какие-то процессы и прочие атрибуты, если один человек мог спокойно сделать достаточно немалую софтину.
Сишные и С++ либы, опять же, не подключались без извращений типа "завернуть в dll с plain C интерфейсом".
Сколько я не смотрю на другие средства разработки - там обязательно есть какая-то шиза на тему того, что невозможно пользоваться, не вкурив штук пять смежных областей. Тот же дотнет - это просто страшная сборная солянка из XML, веба, рефлекшена с кодогенерацией, хитрожопого ООП, причем некоторые вещами оттуда до сих пор проще переписать чем использовать готовые.
Послушаешь
zabivator и прочих про ocaml - это просто гамон, какие-то сишные компиляторы, какие-то либы, портирование между виндами и линуксами и прочий мрак.Жаба энтепрайзная тоже страх какой-то, судя по количеству фреймворков, методик взаимодействия с внешним миром и прочего.
Т.е. все другие платформы ориентированы или на работу в команде с разделением труда или на знание множества смежных шизов, что в любом случае не дает окопаться в песочнице и 20 лет самостоятельно пилить одну и ту же опердень.
no subject
Примеры можно? Желательно, сравнимые с MFC - где vptr смещен на 4 байта относительно начала класса.
no subject
Просвещайтесь:
http://en.wikipedia.org/wiki/Category:C_compilers
http://en.wikipedia.org/wiki/Category:C%2B%2B_compilers
(и это далеко не полный список)
Как раз на Юниксах десяток разных компиляторов -- начиная от Sun Studio и IBM Visual Age.
> Желательно, сравнимые с MFC - где vptr смещен на 4 байта относительно начала класса.
Обычно проблемы с компиляторами начинаются задолго до исполнения.
> sh, bash, dash (light bash), zsh... 5 (пять) штук. Где сотни?
Начинаются отмазки в стиле "не всё так плохо, всего 19"
http://en.wikipedia.org/wiki/Category:Unix_shells
"Стандарт", ага.
> Без cygwin'а было бы совсем грустно. Он делает из windows подобие нормальной системы.
Что для гомосексуалиста норма, то для нормального человека гомосексуализм. Вообще-то винда НТ POSIX-сертифицирована с 1994 года. Официально, комитетом POSIX, за деньги.
Вы стандарт позикса сначала изучите, матчасть почитайте, а потом рассуждайте про "норму".
> и под unix системами могут существовать РАСШИРЕНИЯ (а не замещения!) errno
Херню какую-то городите. Скажем, известная проблема с блокирующим IO в определённой ситуации -- одна система тупо возвращает одну ошибку, вторая другую. Усё, приплыли.
А как там в POSIX со "стандартом" на ioctl()?
И не соизволите тыкнуть на стандарт по заголовочным файлам? Меня интересует сетевая подсистема. Клятые виндузятники клевещут, что разные API в разных Юниксах...
no subject
Тролль? Понемаю.
Я про несовместимости вообще-то, про которые были упомянуты.
А Си - он один, ANSI C.
Стандарт де-факто - sh и bash.
Остальное - для end-user'ов, которые хотят тонкого тюнинга консоли, либо light-версии "заместителей" - dash.
То-то там имена вызовов с двумя подчёркиваниями идут.
Помнится мне, пробовал я там собрать утилиту... Там и не получилось.
Под cygwin собралось сразу.
no subject
> Я про несовместимости вообще-то, про которые были упомянуты.
> А Си - он один, ANSI C.
пипец, такой большой, а в Гугле забанен
ну вот сходу специфика, которая может поломать совместимость
http://groups.google.com/group/fido7.su.c-cpp/browse_thread/thread/4579db8a7d183d87
https://www.suntrainingcatalogue.com/eduserv/client/loadCourse.do;jsessionid=D773548BC98D2C77F9721EA76E5B1F42.tomcat2?coId=ru_RU_WDO-2800&coCourseCode=WDO-2800&l=ru_RU
а как там с линковкой между компиляторами?
а как там с заголовочными файлами?
а зачем, если "Си - он один", кошмарное число #ifdef МОЙКОМПИЛЯТОР1?
А вот "Си он один" для любимого GCC: http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
> Стандарт де-факто - sh и bash.
Честно говоря, мне хотелось бы уйти от тупого тролления.
Нет, ну вот с точки зрения профи, чем отличается "bash стандарт de-facto" и "gcc стандарт de-facto" от "cmd.exe стандарт de-facto" и "msvc стандарт de-facto"?
Разве что меньшей обоснованностью: cmd.exe есть на минимум 90% компьютеров мира, а bash пусть на 4%.
> То-то там имена вызовов с двумя подчёркиваниями идут.
Помнится мне, пробовал я там собрать утилиту... Там и не получилось.
Никаких двойных подчёркиваний в стандарте и в его реализации нету. Если какая-то утилита что-то нехорошее делала, то это как бы её проблема.
> http://en.wikipedia.org/wiki/Berkeley_sockets
Спасибо. Я вот тоже попытался одну утилиту (rdesktop) скомпилировать, с cygwin сразу не заработало, а вот с MSVC после 2 часов секса заработало. Причина в том, что этот "стандарт" сильно разный на linux, BSD & windows. И вообще они СВОЙ netdb/in.h включили на случай "ну если не поможет, то вот наш".
no subject
В какой именно ситуации, какие именно системы?
Нету =(
http://en.wikipedia.org/wiki/Berkeley_sockets
The "de jure" standard definition of the Sockets interface is contained in the POSIX standard, known as:
IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX).
Open Group Technical Standard: Base Specifications, Issue 6, December 2001.
ISO/IEC 9945:2002
no subject
Феерический бред. Библиотека классов перепутана с языком, классы перепутаны с объектами...
no subject
no subject
Другой вопрос что лэйоут объектов вроде как различался в отладочном и релиз режимах. Ну так MFC тут абсолютно не причем.
no subject
no subject
no subject
Точнее, мне это показывали мои тогдашние коллеги - запускаем проект, выбираем опцию сборки - в часности, указываем "use mfc" or "not use mfc".
Пруфлинк я попытался найти, но нигде никто не пишет, как именно выглядит layouting в памяти, за исключением рассылок по конкретным компиляторам.
Витус прав, слушайте Витуса. Он дурного не посоветует.
no subject
Хинт: опции сборки "use mfc", "not use mfc" на самом деле шорткат для кучки опций компилятора и линкера.
no subject
Значит, только сокращение?
Ничему не противоречит.
Флажок для сборки с ATL тоже просто сокращение?
no subject
Но думаю что да. Ибо
cl /? | grep mfc
cl /? | grep atl
ничего не дали.
Итак, предположим что у компилятора есть ключ меняющий расположение vptr в объекте. Ничего криминального в этом нет. НО! Будете ли вы спорить с тем фактом (имхо аксиомой), что все исходные тексты программы и используемых статических библиотек должны быть:
- или скомпилированы с одинаковой установкой этого ключа компилятора
- или каждое объявление класса должно предваряться некой специфической #pragma, указывающей компилятору, где именно хранится vptr в объектах этого класса
?
no subject
Да
Аксиома верная, но спорить буду (не с ней).
Если ты включил MFC || ATL, то ты получил:
1) Ровно 1 (одну) реализацию компилятора
2) Жутчайший гемморой со сборкой и использованием сторонних библиотек.