Лицензионная продукция

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

allap, А мне очень хорошо известно - его цена >3500$ за одно рабочее место (каталог Софтлайн рулит) при том, что лицензионность дельфы легко проверяется. Таким образом, написанная тобой программа на левой дельфе не имеет никаких шансов быть продонной за адекватную цену легальному клиенту. А теперь прикинь какой дурак будет инвестировать такие бабки в такое мягкосказать монстрообразное недоразумение при наличии бесплатных систем разработки в т.ч. и от микрософта. А на счет удобства работы - работодателю это глубоко всеравно.

Re: re:Лицензионная продукция

Если правду говоришь, то это, действительно, перебор. Кстати, сейчас у
Borland обновилась линейка продуктов. Вышел Turbo Delphi, цена на который
должна быть более адекватной. Может, и вернется популярность тогда.

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

А шаблоны+макросы как мощнейшее средство абстракции в C++ уже не в счёт? Пользовался ли ты когда-либо STL, boost?

Одно дело создавать на скорую руку миниатюрные проекты, и другое – разрабатывать проекты крупного масштаба, требующие максимального уровня контроля на стадии компиляции (дабы значительно сократить неизбежный отлов багов в run-time) и поддержки высокого уровня абстракции (дабы написание и сопровождение программы как можно реже вынуждало прибегать к масштабному переделыванию уже существующего кода). В этом плане, AFAIK, C++ вне конкуренции.

Не понимаю, кому сейчас нужен этот C, ведь фактически это не что иное, как довольно ущербное подмножество C++.

Интересно, а за свой C++ Builder Борланд тоже столько дерёт?

Re: re:Лицензионная продукция

Не поленился и нашел цены:

BorlandR C++BuilderR 2006:

Enterprise New User ($2,490.00)
Enterprise Upgrade ($1,490.00)
Professional New User ($1,090.00)
Professional Upgrade ($460.00)

Реально много, особенно для постсоветского пространства.

А вот и новая линейка Turbo:

Turbo Delphi (for Win32) Pro ($399.00)
Turbo for Win32 Pro Upg Explorer ($249.00)
Turbo Delphi for .NET Pro ($399.00)
Turbo .NET Pro Upg Explorer ($249.00)
Turbo C++ Pro ($399.00)
Turbo C++ Pro Upg Explorer ($249.00)
Turbo C# Pro ($399.00)
Turbo C# Pro Upg Explorer ($249.00)

Вполне рыночные цены.

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

Ну, конечно, если других языков нет. А как в C++, скажем, с рефакторингом? Есть ли для C++ что-нибудь подобное Eclipse или IDEA?

Re: re:Лицензионная продукция

Так Эклипс для многих языков подходит - нужны только плагины. Например, мне
удавалось для Python его настроить.

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

allap, я ж про конкретно C++ спрашиваю, мне интересно.

Re: re:мЙГЕОЪЙПООБС РТПДХЛГЙС

Это ты просто не в курсе. Серия HLLM или HLLP по классификации ДырВеба -- это вирусы и прочая живность, написанная на языках высокого уровня. Размеры -- порядка 30-40 килобайт. И ничего, работают Да и вообще, во временя ДОСа ещё были вирусы, написанные на паскале, и тоже работали

А ассемблерные, значит, найти трудно?

Re: re:Лицензионная продукция

Что-то он исчезает, исчезает, да никак не исчезнет

Очень даже известно. Я об этом в начале темы говорил -- простота освоения дельфы приводит к тому, что всякие чайники пишут на ней кривой софт. Поэтому и складывается впечатление, что на дельфи нормальные вещи писать нельзя.

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

А чего спрашивать-то? <a href='http://www.google.ru/search?as_q=eclipse+C%2B%2B&hl=ru&newwindow=1&num=100&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&as_rights=&safe=images' target='_blank'>Набираем в Google «eclipse C++»</a>, читаем первую же ссылку:
<a href='http://www.eclipse.org/cdt/' target='_blank'>Eclipse C/C++ Development Tooling - CDT</a>

<a href='http://www.google.ru/search?as_q=eclipse+C%2B%2B+refactoring&hl=ru&newwindow=1&num=100&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&as_rights=&safe=images' target='_blank'>Добавив в поиске слово «refactoring»</a>, снова можно увидеть много интересного

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

Masterkent, спасибо

Re: re:Лицензионная продукция

А что в нем, рефакторинге, такое есть, что для других языков не подходит? В
книжках по рефакторингу Java используют, но это не мешает применять его для
других ЯП.

Вот статья про Turbo Delphi <a href='http://www.rsdn.ru/article/devtools/turbo.xml' target='_blank'>http://www.rsdn.ru/article/devtools/turbo.xml</a>
Там есть скриншот, на которм четко видно, что в главном меню есть пункт
"Refactor". Так что это уже стандартная фишка для любой IDE и никуда от нее
не денешься

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

,
Мда, о таком не в курсе. Надо погуглить вопрос. У меня немало онлайн знакомых хакеров, все пишут на асме.

,
Если хорошо прятать, то на глаз не определишь.

Re: re:Лицензионная продукция

Анекдот на злобу дня.

- Да где вы видели нормальную девушку-программиста? Да вы посмотрите на
них... че они знают... ну вот, к примеру, хоть одна из них знает что такое
цикл?
- Эмм... полагаю ВСЕ девушки знают, что такое цикл...

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

Masterkent,

Утверждение очень спорное и я его не разделяю на 100%. То что в стандарт С++ пропихнули STL и пытаются Boost не играет на руку конечным пользователям (читай программерам) т.к. достаточно сильно лимитирует их возможности возможностями этих API. С другой стороны программирование ООП на С++ требует очень высокой степени проработки алгоритма программы (читай структуры классов) и в реальной жизни зачастую невозможно учесть всех потенциальных изменений , которые может претерпеть программа. И это сводит на нет всю ООП парадигму, т.е. гладко бывает только на бумаге. Единственная область, где ООП пытается доказать свое право на существование - GUI, но и здесь не все просто. Вопервых потребовалось около 10 лет, что бы четко очертить концепцию: только последние несколько лет стали появляться библиотеки изпользующие обекты как преимущество а не как дань моде. Если взять микрософтовсий MFC то это достаточно корявая попытка с помощю препроцессора и макросов добиться эффекта псевдоообъектности.
Ну и как завершающий тезис, хочу отметить, что при желании и на "ущербном" С можно писать качественный объектный код, просто определение объектов немного меняется.

Re: re:Лицензионная продукция

Не согласен, а шаблоны проектирования зачем разрабатывают тогда, а потом еще
и применяют на практике? ООП уже больше 20 лет и сейчас этот подход очень
оправдан.

Насчет Си могу сказать, что его использование оправдано при программировании
микроконтроллеров, где программы не столь большие, а памяти не так много,
как хотелось бы. Да и производителям гораздо легче реализовывать компилятор
Си для каждой серии микроконтороллеров, чем Си++ с его шаблонами, классами и
т.п.

Но вообще-то все идет к тому, что и на Си вскоре забьют окончательно.

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

allap,

"Писатели пописывают, читатели почитывают" и все вроде при деле. Реально, несмотря на количество восторженных отзывов в книжках по С++ STL используется не так уж часто, и она ИМХО стала частью пиара и промоушена. Я использую несколько API разработчики которых сознательно ушли от использования STL ввиду неоправданной сложности и ненужной универсальности.
Поправка: ООП с нами уже более 40 лет и все это время как магнит притягивает академические умы. Но опять же проблемы ученых редко коррелируют с практическими задачами, которые рядовые программисты решают каждый день.

я бы воздержался от столь категоричных заявлений. Всетаки львиная доля софта написана именно на Си и это та основа, забив на которую рискуешь столкнуться с необходимостью повторно изобретать велосипед.

Re: re:мЙГЕОЪЙПООБС РТПДХЛГЙС

А неассемблерные, значит, на глаз определишь?

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

Ага, по названию процедур и функций:
FirstHackLoop(), KillWinFolder(), FormatSystemC(), SendPrivateData(), GenerateSpam() и прочие...

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

at_hacker, скорее да, чем нет. По загрузке памяти и проца. Кста, если у кого-нить есть пример трояна с сорцами не на асме, прошу поделиться. Интересно, как это чудо воббще работать может.

Ну да, изобретение велосипеда всякий раз, как только понадобится, например, некая структура данных вроде списка или вектора, а также применение к ней какого-либо базового алгоритма вроде двоичного поиска или сортировки, – это, конечно, любимое занятие всех программистов C.

Это каким же образом?

Учитывать все потенциальные изменения в общем-то и не требуется. Просто желательно сразу добиваться как можно большего уровня абстракции и стараться не создавать препятствий к добавлению нового функционала. Когда программа становится недостаточно гибкой для внесения изменений, это часто свидетельствует именно о недостаточном уровне абстракции, и тогда, возможно, имеет смысл производить рефакторинг.

Странные выводы. Да, со временем программа, написанная в ОО стиле, может проявить недостаточную гибкость в отношении внесения в неё изменений, однако программы, написанные в процедурном стиле, вообще не обладают таковой изначально в силу априорной слабости своих абстракций.

Да что вы говорите?

Вот только усилий для этого, скорее всего, понадобится куда больше, нежели на ОО языке. Да и не сможет он быть по-настоящему качественным по причине отсутствия должной инкапсуляции (обеспечить которую средствами языка C не получится, как ни старайся).

Кроме того, ООП – это ещё не всё, что отсутствует при программировании на C. В C нет исключений, нет шаблонов и перегрузки функций (иметь несколько версий функции для разных фундаментальных типов тоже может быть полезным), нет аргументов по умолчанию, нет ссылок (всегда приходится проверять указатели на равенство нулю перед разыменованием), отсутствует строгая проверка типов, а местами и количества аргументов (реверанс в сторону частоиспользуемых в C функций семейства printf)... Это первое, что удалось припомнить. Если немножко поднапрячь память, то наверняка можно вспомнить ещё массу полезных вещей, которых в C нет. Но даже исходя из перечисленного (и не принимая во внимание ООП), можно смело утверждать, что C++ – это как минимум значительно улучшенный C. По крайней мере, всё, что реализовано в C, может быть с лёгкостью переписано под C++.

Причиной тому либо безграмотность, либо банальная лень (в отношении освоения каких-то идиом). На программерских форумах я не встречал ни одного человека, который бы одновременно демонстрировал сколь-нибудь глубокие познания в языке C++ и в то же время выказывал какие-то негативные отзывы касательно STL.

Что такого сложного можно найти в STL, мне, честно говоря, непонятно. Универсальность же практически никогда не бывает лишней (если она не противоречит понятности и эффективности – благо, STL позволяет создавать вполне понятный и эффективный код).

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

Masterkent,

для тебя "велосипед" а для меня попытка закрутить квадратный болт в круглое отверстие - каждому свое.
Из основных недостатков STL это невозможность определенно сказать как данные распределены в памяти: одним большим куском или несколькими маленькими. Отсюда ограничение на использование только родного интерфейса

Ничего странного. ИМХО итеративная разработка софта в процедурном стиле более продуктивна в отношении: результат/затраченное время, чем разработка в объектном. Хотя, конечно, я здесь субъективен и тенденциозен.

"не судите и не судимы будете". Попытка возвести в культ ту или иную идеологию является индикатором неадекватности восприятия действительности. Универсальные средства, как и специфические имеют одинаковые права на существование.

Re: re:Лицензионная продукция

_blackdog, складывается впечатление, что вы программист старой закалки
Без обид, пожалуйста.

re:мЙГЕОЪЙПООБС РТПДХЛГЙС

allap, Я думаю здесь уместно внести ясность и расставить все точки над i.
Я не старик мне всего лишь 29.
Да и программист - это, наверное, слишком громко сказано.
Обстоятельства сложились так, что в последние годы я сталкивался с достаточно не тривиальными задачами. Это плюс простое любопытство способствовало поддержанию духа эксперимента в области программирования, что собственно вкупе с изучением доступной информации позволило составить собственное впечатление об сильных и слабых сторонах разных языков программирования.

Как ни называй, это работа вхолостую, т.е. просто пустая растрата времени. Абстрагирование тем и замечательно, что позволяет не возвращаться к решению одних и тех же проблем многократно, давая возможность уделить больше времени другим задачам.

Полагаю, речь идёт о контейнерах? Если требуется непрерывное расположение элементов, то следует выбирать std::vector (стандарт гарантирует, что элементы вектора располагаются последовательно в одном непрерывном блоке памяти; тем самым обеспечивается совместимость вектора с C-массивами). Если такого требования нет, то и разницы как-то особой нет и нужный контейнер выбирается исходя из других соображений (скажем, эффективности наиболее часто используемых операций с контейнером). Так что с этим никаких проблем не вижу.

Что-то не понимаю я, о каких ограничениях речь.

Кстати, allap упомянул шаблоны проектирования (вообще), а не только лишь STL (в частности). Не стоит забывать, что в STL сосредоточена фактически лишь ничтожная часть известных на данный момент паттернов ООП, в т.ч. с использованием шаблонов.

«Идеологии» – это у тех, кто любит отвергать очевидные преимущества, изложенные в общепринятых (среди прогрессивного человечества ) концепциях.

Могут иметь, но только в том случае, если универсальные средства заметно проигрывают по каким-то характеристикам (например, затратам на их создание) конкретизированным. В противном случае отказ от универсальности зачастую непрактичен (из-за потенциальной возможности столкнуться с аналогичной задачей, причём не обязательно в текущем разрабатываемом проекте).

Боюсь, что поверхностное изучение этих самых языков не сможет дать достаточно полного представления о них, чтобы делать какие-то адекватные выводы.