Re[2]: c++ - так уж ли он крут? - Философия программирования

Здравствуйте Gambler, Вы писали:

G>Здравствуйте Курилка, Вы писали:

К>>Не хочется разводить очередную войну вокруг c++, но
К>>вот этот топик напомнил мне о статье
К>>A Critique of C++.
К>>Те же инлайны являются примером того, что Айан Джойнер называет bookkeeping — т.е. деталей реализации, которые в принципе может решить компилятор, но которые в C++ ложатся на плечи программера.
К>>И это не единственный пример.
К>>Есть какие-либо мнения по этому поводу?
К>>Тем более, что статья несколько старая — 1996.
К>>Я не очень знаком с C#, но может он решает большую часть проблем?

G>Все проблемы решает хорошая доза мышьяка или стрихнина внутривенно
G>

Спасибо — такой реакции и ожидал..

G>А если честно, то что тебе нужно? Не нравится C++ переходи на Жабу!

Ага — Жаба тоже не дело, если разобраться, хотя как язык она чуть получше будет, но с JVM мучаться — увольте!

Здравствуйте Курилка, Вы писали:

G>>Все проблемы решает хорошая доза мышьяка или стрихнина внутривенно
G>>

К>Спасибо — такой реакции и ожидал..

G>>А если честно, то что тебе нужно? Не нравится C++ переходи на Жабу!

К>Ага — Жаба тоже не дело, если разобраться, хотя как язык она чуть получше будет, но с JVM мучаться — увольте!

Ну тогда тебе подойдёт первый вариант!

Здравствуйте Gambler, Вы писали:

G>Здравствуйте Курилка, Вы писали:

G>>>Все проблемы решает хорошая доза мышьяка или стрихнина внутривенно
G>>>

К>>Спасибо — такой реакции и ожидал..

G>>>А если честно, то что тебе нужно? Не нравится C++ переходи на Жабу!

К>>Ага — Жаба тоже не дело, если разобраться, хотя как язык она чуть получше будет, но с JVM мучаться — увольте!

G>Ну тогда тебе подойдёт первый вариант!

Огроооомное спасибо за столь конструктивную дискуссию!

Здравствуйте Курилка, Вы писали:

К>Не хочется разводить очередную войну вокруг c++, но
К>вот этот топик напомнил мне о статье
К>A Critique of C++.

Не хочется показаться невежливым, но по-моему место этому топику в Прочем.

P.S. А за ссылку на статью -- спасибо

Здравствуйте Курилка, Вы писали:

К>Не хочется разводить очередную войну вокруг c++, но
К>вот этот топик напомнил мне о статье
К>A Critique of C++.

Надо сказать, что эта монография не столько критикует С++, сколько рекламирует Eiffel. Во всяком случае у меня создалось именно такое впечатление.

Здравствуйте Курилка, Вы писали:

К>Не хочется разводить очередную войну вокруг c++, но вот этот топик напомнил мне о статье A Critique of C++.

Не принимай близко к сердцу тот топик и эту статью. Там спорят теоретики о больших материях, они даже 'стандарт' с большой буквы назвают

Лично мне по барабану какой у inline linkage и ручной оптимизацией я буду заниматься только в крайних случаях, и использовать для этого буду сначала приличный профайлер типа Numega TrueTime, а уже потом советы непримеримых трактовщиков стандарта

К>Те же инлайны являются примером того, что Айан Джойнер называет bookkeeping — т.е. деталей реализации, которые в принципе может решить компилятор, но которые в C++ ложатся на плечи программера.

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

К>И это не единственный пример.
К>Есть какие-либо мнения по этому поводу?
К>Тем более, что статья несколько старая — 1996.
К>Я не очень знаком с C#, но может он решает большую часть проблем?

Шарп хороший язык. Многие вещи на нём делать проще и приятнее. В этом смысле он удобнее C++, но C#, чтобы о нём не говорили, всего лишь урезанный клон C++ с некоторыми добавленными возможностями. А о том лучше он или нет C++ мы поговорим после того как в нём появятся шаблоны.

ЗЫ. А насчёт сабжа... Хотелось бы услышать определение слова 'крут', прежде чем отвечать на это вопрос. Если пока такое определение не формулируется, то даже и не сомневайся. C++ rulez forever

А все эти джавы и шарпы просто детский сад.

Здравствуйте IT, Вы писали:

IT>ЗЫ. А насчёт сабжа... Хотелось бы услышать определение слова 'крут', прежде чем отвечать на это вопрос. Если пока такое определение не формулируется, то даже и не сомневайся. C++ rulez forever

А все эти джавы и шарпы просто детский сад.

Да в этом проблема... Да же не знаю, как требования сформулировать чётко — всё-таки я не умудрённый годами теоретик компьютерных наук и ООП. Но доводы Джойнера мне показались очень убедительными, да и примеры из собственной практики, да и даже из рсдн склоняют к мысли, что всё-же при всей мощи c++ — это далеко не лучшее решение, многие вещи реализуемы гораздо проще. И, в принципе, при желании тот же c++ (вот тут на меня посыпится наверно град замечаний о совместимости и т.д) можно довести до гораздо более нормального состояния.
И ещё раз извините, если я своей ересью запятнал великий и могучий c++.

Здравствуйте Курилка, Вы писали:

К>Да в этом проблема... Да же не знаю, как требования сформулировать чётко — всё-таки я не умудрённый годами теоретик компьютерных наук и ООП. Но доводы Джойнера мне показались очень убедительными, да и примеры из собственной практики, да и даже из рсдн склоняют к мысли, что всё-же при всей мощи c++ — это далеко не лучшее решение, многие вещи реализуемы гораздо проще. И, в принципе, при желании тот же c++ (вот тут на меня посыпится наверно град замечаний о совместимости и т.д) можно довести до гораздо более нормального состояния.

Про совместимость, переносимость, производительность и распространенность C++ тебе и так скажут. Я же хотел бы кое в чем согласиться.
Да, действительно, нынешняя ситуация напоминает переворот в средневековой военной тактике, когда были изобретены арбалеты. Рыцарь, который готовился и обучался военному делу в течение 20 лет, легко убивался человеком, который 2 месяца тренировался с арбалетом.

Язык C++, действительно, довольно сложен — это один из главных его недостатков. И за полгода подготовить с нуля здравомыслящего программиста на нем невозможно (а на VB и шарпе — похоже, это нынешняя реальность). Только так ли это сейчас важно?

Во-первых, религиозные споры о "крутости" какого-либо языка или средства разработки уже не в моде. Первую дорожку проложила архитектура COM. Высокопрофессиональный (и, кстати, высокооплачиваемый) программист на C++ создает компоненты, реализующие сложный GUI или действия на уровне API, а море его коллег использует их из VB. Теперь же, учитывая .NET, все еще более запущено :) По сути, C# отличается от VB.NET и от Perl.NET только синтаксисом! Создав класс в программе на VB, можно унаследоваться от него в C#, и наоборот.

Во-вторых, заказчики рассматривают только результаты работы — им неважно, что ты использовал Супер(tm) Optimized FrameWork+(R), главное, чтобы было сделано в срок и не глючило.

В-третьих, мне понравилась мысль, которую высказал VladD2: по-настоящему хорошие программисты на VB, Delphi и других RAD-остях получаются из программистов на C++. Это действительно так.

К>И ещё раз извините, если я своей ересью запятнал великий и могучий c++.
Вот это, кстати, уже подстрекательство к религиозному спору. :)

Здравствуйте Topi_Nambur, Вы писали:

TN>Здравствуйте Курилка, Вы писали:

К>>Да в этом проблема... Да же не знаю, как требования сформулировать чётко — всё-таки я не умудрённый годами теоретик компьютерных наук и ООП. Но доводы Джойнера мне показались очень убедительными, да и примеры из собственной практики, да и даже из рсдн склоняют к мысли, что всё-же при всей мощи c++ — это далеко не лучшее решение, многие вещи реализуемы гораздо проще. И, в принципе, при желании тот же c++ (вот тут на меня посыпится наверно град замечаний о совместимости и т.д) можно довести до гораздо более нормального состояния.
К>>И ещё раз извините, если я своей ересью запятнал великий и могучий c++.

TN>Если тебе кажется что "...многие вещи реализуемы гораздо проще...",
TN>так сделай или скажи конкретно как это можно сделать.
TN>Иначе разговор получается пустой...

Замечательную фразу читал когдата в одной конференции по поводу религиозного спора. Цитирую (не дословно):
"Нечего скубаться, шо контора купит, на том и пишем". Начальстово оно такое, DBASE значить DBASE и все тут, а вы шаблоны, красявости, оптимизация
Эх

Здравствуйте IT, Вы писали:

IT>Шарп хороший язык. Многие вещи на нём делать проще и приятнее. В этом смысле он удобнее C++, но C#, чтобы о нём не говорили, всего лишь урезанный клон C++ с некоторыми добавленными возможностями. А о том лучше он или нет C++ мы поговорим после того как в нём появятся шаблоны.

Да. да. (смущенно). И я бы попросил еще нормальный деструктор для value-типов.

IT>ЗЫ. А насчёт сабжа... Хотелось бы услышать определение слова 'крут', прежде чем отвечать на это вопрос. Если пока такое определение не формулируется, то даже и не сомневайся. C++ rulez forever

А все эти джавы и шарпы просто детский сад.

При разбитии рутого прэдмэта недолжно вытекать жидкости. Если вытикает желтая жидкость, то это прэдмэт в смятку, ну и т.д.

Здравствуйте Курилка, Вы писали:

К>Те же инлайны являются примером того, что Айан Джойнер называет bookkeeping — т.е. деталей реализации, которые в принципе может решить компилятор, но которые в C++ ложатся на плечи программера.

Та, ты задумайся... любой мало-мальски достойный комплятор умеет сам определять делать функцию инлайном или нет. Директива inline — это всего лишь право программиста сказать свое слово по этому поводу. Перефразируя вышесказанное inline (в частности) и C++ (в общем) дает то главное, чего нехватает в других языках СВОБОДЫ ВЫБОРА причем не для компилятора или фирмы ее произведшей, а ДЛЯ ПРОГРАММИСТА, т.е. для меня, тебя и вооон того (пользуясь случаем передам привет IT

). Причем это проявляется не только в inline, но и во всем духе языка. Хочешь пройтись по памяти? Пожалуста... Не хочешь? Вот тебе методы как этого не делать. У C++ есть только два недостатка: 1) сысокая сложнось (што иногда приводит к ползанью на брюхе в совершенно простых ситуациях), 2) большое количество слабо подготовленных, или просто марально неустойчивых личностей (хе-хе) которые лезут использовать этот язык и тем самым дескридитируют.

(перед пинками и плевками прошу обратить внимание, на смайлик

).

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

Здравствуйте Курилка, Вы писали:

К>Ага — Жаба тоже не дело, если разобраться, хотя как язык она чуть получше будет, но с JVM мучаться — увольте!

Самое, что интересное (и поверь для меня очень даже печальное), что с таким мировазрением через пару тройку лет и уволят. Причем с записю в трудовой "Как морально устаревший груз".

Здравствуйте Курилка, Вы писали:

К>Здравствуйте Gambler, Вы писали:

G>>Здравствуйте Курилка, Вы писали:

G>>>>Все проблемы решает хорошая доза мышьяка или стрихнина внутривенно
G>>>>

К>>>Спасибо — такой реакции и ожидал..

G>>>>А если честно, то что тебе нужно? Не нравится C++ переходи на Жабу!

К>>>Ага — Жаба тоже не дело, если разобраться, хотя как язык она чуть получше будет, но с JVM мучаться — увольте!

G>>Ну тогда тебе подойдёт первый вариант!

К>Огроооомное спасибо за столь конструктивную дискуссию!

Ну, а ты сам можешь чтонибудь предложить конструктивного?

А, то Жаба с Шарпом тебе не нравятся хотя они порой переганяют C++-сные компиляторы и по развитию библиотек переплюнули все что было создано для С++.

С++ тоже...

Свой язык (я так понимаю) ты даже в проекте предложить не можешь.

Вот Gambler и прикалывается от нечего делать.

Ты предлагай, а мы полсушаем.

Я вон сколько уже рацух прдложил и для С++ и для Шарпа, а толку чуть. Не слышно нас.

Здравствуйте Курилка, Вы писали:

К>...и даже из рсдн склоняют к мысли, что всё-же при всей мощи c++ — это далеко не лучшее решение, многие вещи реализуемы гораздо проще.

Да пойми ты... идеала достичь нелья! К нему можно и нужно стремиться, но если кто-нибудь его достигнет, то просто подымится планка того самого идеала.

ООП — это такой же промежеточный шаг (и не факт, что правильный) совершенству как структурное программирование на заре его становления. Компонентная модель, похоже, тоже шаг в некотором направление. Дельфи и .Net пытаются соединить эти две парадигмы, но далее будут новые, новые, и новые. И обо всех них будут говорить, что ни лучше, проще, круче, но нужны они или нет решать будут не теоретики, сэрая масса тык сызыть, т.е. мы с вами. С++ прошел проверку временем, т.е. огнем, водой и медными трубами. Шарп и Ява вообще не языки если смотреть в корень, а их успех пока основан на баксовой накачке. Через десять лет с этими экспонатами все решиться само собой. Они лили вымрут или будут жить. Серьезно можно говорить только о тенденциях. Мое мнение, что все идет к тому, что фирмы рипа MS и Sun стремятся вытеснить С++ в нишу низкоуровневого программирования, для крутых гуру. Естественно, что в подсознании у них живет мысль, что такие программисты если уже не работают на них, то будут работать только у них... Шарпы, Васики, Дельфи, Явя — это для прикладного уровня. Эфил и другие Перлы — для любителей экзотики. Ну, и т.п. Скорее все будет если не совсем так, то очень похоже. Но перспективы MS здесь несколько более радужные (напомню, по-моему). Об этом очень хорошо сказал Дон Бокс: "Sun делает Яву для продажи, а MS .Net для себя (в том числе), т.е. Sun сам пишет на C/C++, а остальным толкает Яву. MS же делает платформу для себя.". И это действительно так. Но это не человеколюбие.

Я бы перефразировал его так... "MS понимает, что рано или поздно Windows будет кем-то вытеснен. И MS делает новую платформу, чтобы вытеснить свою Windows, т.е. сделать тот же фарс как в девяностых, когда они добились, что все начали говорить о конкуренции NT и 9x. Ява и Линукс, будучи не самыми идеальными реализациями (мягко скажем), тем не менее сильно давят MS на хвост. И .Net (но не та сказка для дебилов которая выдается в пресс-релизах), а тот .Net который позлят скомпилировать любую Windows-программу в переносимый независимый от машины код, и тот который, за счет верификации, позволит в будущем избавить MS от обвинений в большем количестве багов. По сути .Net это больше чем программная платформа. Это и полнофункциональная переносимая ОС (причем перенасимая под драйверные носители типа Ликукса или OS/390), и свой ассемблер (плевать мы хотели на разные Интелы), и стандарт на библиотеки (большой привет Страуструпам), скрипты работающие со скоростью C++-программ (пламенный привет PHP, Пилону и Перлу для всех платформ несовместимых с .Net), и скрптлеты (пользуясь случаем, привет Sun-у). Короче, не даром MS вбухивает в эту технологию такие бабки. А Эфил... Что Эфил? Это всего лишь один язык который уже работает под тем же .Net. Ну, а C++ в .Net — это клей позволяющий легко связать старое с новым миром и средство оптимизации дающее возможность того самого ВЫБОРА которого небыль, нет и не будет в VB. В .Net можно создать класс на C++, изменить его функциональность (через наследование) в Шарме или Эфиле, и потом снова использовать его из С++.

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

Здравствуйте VladD2, Вы писали:

К>>...и даже из рсдн склоняют к мысли, что всё-же при всей мощи c++ — это далеко не лучшее решение, многие вещи реализуемы гораздо проще.

VD>Да пойми ты...

[skip]
Фундаментально

VD>IT уже как-то говорил, что все предубеждения со временем пройдут...

Могу добавить: и появятся новые!
И самое прикольное, что в следующий раз, после того как появится что-то ещё на смену .NET её будут защищать те, кто на ней выростет. А те, кто сейчас защищает C++ и Windows уже не будут так активны и просто спокойно перейдут на новую технологию, в первый раз что ли

Здравствуйте IT, Вы писали:

IT>Могу добавить: и появятся новые!

Дык!

IT>И самое прикольное, что в следующий раз, после того как появится что-то ещё на смену .NET её будут защищать те, кто на ней выростет. А те, кто сейчас защищает C++ и Windows уже не будут так активны и просто спокойно перейдут на новую технологию, в первый раз что ли

я плякаль.

PS

Блин. Хоть бы одним галзком глянуть на будущего задогмаченного ортодокса .Net.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте Курилка, Вы писали:

К>>...и даже из рсдн склоняют к мысли, что всё-же при всей мощи c++ — это далеко не лучшее решение, многие вещи реализуемы гораздо проще.

VD>Да пойми ты... идеала достичь нелья! К нему можно и нужно стремиться, но если кто-нибудь его достигнет, то просто подымится планка того самого идеала.

Я и не говорю, что его достичь можно — просто моё мнение, что надо хотя бы к нему стремиться, а Си++ в этом отношении ИМХО не очень двигается. Выражаясь фигурально от него иногда попахивает "архаикой". А всё благодаря ригидности и многочисленности пишущей на ней братии.
[skip]
А с остальным я практически полностью согласен.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте Курилка, Вы писали:

К>>Те же инлайны являются примером того, что Айан Джойнер называет bookkeeping — т.е. деталей реализации, которые в принципе может решить компилятор, но которые в C++ ложатся на плечи программера.

VD>Та, ты задумайся... любой мало-мальски достойный комплятор умеет сам определять делать функцию инлайном или нет. Директива inline — это всего лишь право программиста сказать свое слово по этому поводу. Перефразируя вышесказанное inline (в частности) и C++ (в общем) дает то главное, чего нехватает в других языках СВОБОДЫ ВЫБОРА причем не для компилятора или фирмы ее произведшей, а ДЛЯ ПРОГРАММИСТА, т.е. для меня, тебя и вооон того (пользуясь случаем передам привет IT

(перед пинками и плевками прошу обратить внимание, на смайлик

).

VD>Все эти Явы, Шарпы и Диии, как раз и пытаются устранить эту самую сложность, но иногда перегибают палку, хотя стройность Шарпа действительно подкупает...

Правильно таких их. Нас мало ,но мы все в С-плю-плюсах.

Здравствуйте VladD2, Вы писали:
VD>Все эти Явы, Шарпы и Диии, как раз и пытаются устранить эту самую сложность, но иногда перегибают палку, хотя стройность Шарпа действительно подкупает...

Стесняюсь спросить, но что подразумевалось под Диии?

Здравствуйте Doldim, Вы писали:

D>Здравствуйте VladD2, Вы писали:

VD>C++ (в общем) дает то главное, чего нехватает в других языках СВОБОДЫ ВЫБОРА причем не для компилятора или фирмы ее произведшей, а ДЛЯ ПРОГРАММИСТА, т.е. для меня, тебя и вооон того (пользуясь случаем передам привет IT

Им это не удастся! Ибо, как говорили древние...

Аbusus non tollit usum.

(лат.- злоупотребление не отменяет употребления)

Здравствуйте VladD2, Вы писали:

VD>Да пойми ты... идеала достичь нелья! К нему можно и нужно стремиться, но если кто-нибудь его достигнет, то просто подымится планка того самого идеала.

А может и не надо этого идеала? Ведь не может быть идеала одного на всех.
Идеал у каждого свой!

То о чем ты сегодня пишешь это универсальные языки программипрования
и универсальные среды исполнения.
По большому счету что мы имеем из "специализированных" языков?
По пальцам двух рук можно пересчитать!

Да конечно, (универсальные ) языки и среды будут самыми распространёнными.
Но так что из того?

В эту ли сторону движется прогресс?

У нас был преп.
Он нам внушал: "Если вам надо решить задачу — вам предстоит разработать свой язык."
И чем сложнее задача, тем специализированнее нужен язык — я так его понимал.
Тем в болшей мере решение задачи сводится к конструированию языка.

Но все простые задачи уже решены. :)
Остались одни сложные. И всё сложнее и сложнее... :(
А мы всё дальше миллиона специализированных библиотек не шагаем!
Универсальные языки программипрования по большому счету должны уйти.
Их ниша должна быть гораздо меньше, чем сейчас.

Просто мы ещё очень бедны. Бедны накопленным багажом технологий.
Потому пользуемся универсальными вещами.
Выведь не носите одни и теже ботинки и летом и зимой?
Представьте себе весь город в одних и тех же ботинках!

А то что у нас всего десяток языков программирования на всю
многомиллионную братию программистов, это мы воспринимаем как должное? :no:
Привыкли... но это временно.

Как только появится возможность... так у каждого из нас появится свой индивидуальный язык.
Мы его будем разнашивать как ботинки (отлажывать и приспосабливать).
Мы его будем чистить от всякого накопившегося хлама и мусора, будем обновлять и перестраивать.
Будем заказывать по индивидуальной мерке или долго ходить по шопам выбирая. :)
Мы будем его беречь от неаккуратного обращения. Мы будем им гордиться!

Посмотрите какой у человека язык и вы поймёте, какой он такой, что он может.

... и будут нас встречать "не по одёжке", а по языку, ну а провожать как всегда. :)))

"Жаль только жить в эту пору прекрасную..."

Здравствуйте Рек, Вы писали:

Рек>Здравствуйте VladD2, Вы писали:

VD>>Да пойми ты... идеала достичь нелья! К нему можно и нужно стремиться, но если кто-нибудь его достигнет, то просто подымится планка того самого идеала.

Рек>А может и не надо этого идеала? Ведь не может быть идеала одного на всех.
Рек>Идеал у каждого свой!

Рек>То о чем ты сегодня пишешь это универсальные языки программипрования
Рек>и универсальные среды исполнения.
Рек>По большому счету что мы имеем из "специализированных" языков?
Рек>По пальцам двух рук можно пересчитать!

Рек>Да конечно, (универсальные ) языки и среды будут самыми распространёнными.
Рек>Но так что из того?

Рек>В эту ли сторону движется прогресс?

Рек>У нас был преп.
Рек>Он нам внушал: "Если вам надо решить задачу — вам предстоит разработать свой язык."
Рек>И чем сложнее задача, тем специализированнее нужен язык — я так его понимал.
Рек>Тем в болшей мере решение задачи сводится к конструированию языка.

Рек>Но все простые задачи уже решены.

Рек>Остались одни сложные. И всё сложнее и сложнее...

Рек>А мы всё дальше миллиона специализированных библиотек не шагаем!
Рек>Универсальные языки программипрования по большому счету должны уйти.
Рек>Их ниша должна быть гораздо меньше, чем сейчас.

Рек>Просто мы ещё очень бедны. Бедны накопленным багажом технологий.
Рек>Потому пользуемся универсальными вещами.
Рек>Выведь не носите одни и теже ботинки и летом и зимой?
Рек>Представьте себе весь город в одних и тех же ботинках!

Рек>А то что у нас всего десяток языков программирования на всю
Рек>многомиллионную братию программистов, это мы воспринимаем как должное?

Рек>Привыкли... но это временно.

Рек>Как только появится возможность... так у каждого из нас появится свой индивидуальный язык.
Рек>Мы его будем разнашивать как ботинки (отлажывать и приспосабливать).
Рек>Мы его будем чистить от всякого накопившегося хлама и мусора, будем обновлять и перестраивать.
Рек>Будем заказывать по индивидуальной мерке или долго ходить по шопам выбирая.

Рек>Мы будем его беречь от неаккуратного обращения. Мы будем им гордиться!

Рек>Посмотрите какой у человека язык и вы поймёте, какой он такой, что он может.

А тебе не приходило в голову, что определяя функции или классы в C/C++, ты по сути дела определяешь новый язык? И решаешь задачу уже в рамках этого нового языка, образованного возможностями С++ и используемых тобой твоих/чужих библиотек?

Здравствуйте Sergey, Вы писали:

S> А тебе не приходило в голову, что определяя функции или классы в C/C++, ты по сути дела определяешь новый язык? И решаешь задачу уже в рамках этого нового языка, образованного возможностями С++ и используемых тобой твоих/чужих библиотек?

Ну конечно! Только этим и занимаюсь.

И это отлично, что есть С++ — наиболее гибкий и выразительный из универсальных языков.

Но рамки ... они есть. сжимают. диктуют. Как думать. Из каких решений выбирать.

Язык должен диктоваться задачей — тогда успех.
Если решения продиктованы возможностями, тем что есть под рукой,
тем что умею, то получается как всегда.

Ещё это страшное слово "патерны"! Шаблонные решения. Типовое мышление.
И говорят что это хорошо!

Вспомните как родился C++.
Из потребностей и неудовлетворённости Стаутсрупа существовавшими тогда языками.
Он же делал язык под себя, для своих задач. Это было толчком.
Все можно было решить в рамках вуществовавших тогда языков, но чуть хуже.
А он нарушил све патерны и сделал по-своему.
И вот увидите, таких Страуструпов будет с каждым годом всё больше и больше.

И все мы в конечном счете станем Страуструпами.

Ура!!! Все в Старуструпы!

Так... кажется пора слезать с трибуны.
А то сейчас начнут чем-нибудь кидаться...

Здравствуйте VladD2, Вы писали:

IT>>И самое прикольное, что в следующий раз, после того как появится что-то ещё на смену .NET её будут защищать те, кто на ней выростет. А те, кто сейчас защищает C++ и Windows уже не будут так активны и просто спокойно перейдут на новую технологию, в первый раз что ли

VD>

я плякаль.

VD>Блин. Хоть бы одним галзком глянуть на будущего задогмаченного ортодокса .Net.

А чё? Я не прав? Тогда давай глянем немного назад.

89-90 — что это у тебя за игрушка, Спектрум? Нет? ПиСи? IBM говоришь? Ну, ну... А ОС? MS-DOS? Не знаю такой. Ладно, мне надо серьёзными делами заниматься, у меня сейчас как раз машинное время на ЕС'ке.
91-92 — тотальный переход на MS-DOS.
93 — последнюю груду железа, которая раньше гордо именовалась ЕС ЭВМ продают на золото, вентиляторы и другие полезные запчасти разбирают по домам.
93-94 — повсеместное засилье IBM PC, все автоматизируются, программеры пишут каждый свой склад, бухгалтерию, зарплату (нужное подчеркнуть) и т.д.
95 — всё нормально, но такое ощущение, что чего-то не хватает. Графики, что ли? А может многозадачности?
96 — что это у тебя за игрушка, Windows? 95 говоришь? А, знаю, стоят эти тормоза у меня. Не то? А что в ней может быть нового? 32-х разрядная? Ладно, пошёл я, пора серьёзными делами заниматься.
97-98 — тотальный переход на W95.
99-00 — повсеместное засилье W95. Последнюю копию MS-DOS выкидывают вместе с поздно-уже-апгрейтовать 486 железякой.
01 — всё нормально, но такое ощущение, что чего-то не хватает. Компонентной модели что-ли? А может полноценных распределённых интернет-технологий.
02 — что это у тебя за игрушка? Дот-что? А... Дот-НЕТ. Ну, ну... Слышал. Веб-сервисы говоришь можно запускать... А как же COM+? Детский сад какой-то... Ладно, пошёл я, пора серьёзными делами заниматься.
...

Дальнейший сценарий, думаю, мало чем будет отличаться. 6 лет, ну 7. И всё, эта песня хороша — начинай сначала.

Здравствуйте Курилка, Вы писали:

К>Я и не говорю, что его достичь можно — просто моё мнение, что надо хотя бы к нему стремиться, а Си++ в этом отношении ИМХО не очень двигается. Выражаясь фигурально от него иногда попахивает "архаикой". А всё благодаря ригидности и многочисленности пишущей на ней братии.

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

Здравствуйте Gambler, Вы писали:
G>Наверно это когда много денег и здоровья и на работу ходить не надо. Угадал?

И что вы всё уважаемый Gambler во флейм превратить так жаждите?
По этой причине от дальнейших комментариев воздержусь...

Здравствуйте IT, Вы писали:

IT>Здравствуйте VladD2, Вы писали:

IT>>>И самое прикольное, что в следующий раз, после того как появится что-то ещё на смену .NET её будут защищать те, кто на ней выростет. А те, кто сейчас защищает C++ и Windows уже не будут так активны и просто спокойно перейдут на новую технологию, в первый раз что ли

VD>>

я плякаль.

VD>>Блин. Хоть бы одним галзком глянуть на будущего задогмаченного ортодокса .Net.

IT>А чё? Я не прав? Тогда давай глянем немного назад.

IT>

IT>

89-90 — что это у тебя за игрушка, Спектрум? Нет? ПиСи? IBM говоришь? Ну, ну... А ОС? MS-DOS? Не знаю такой. Ладно, мне надо серьёзными делами заниматься, у меня сейчас как раз машинное время на ЕС'ке.
IT>

91-92 — тотальный переход на MS-DOS.
IT>

93 — последнюю груду железа, которая раньше гордо именовалась ЕС ЭВМ продают на золото, вентиляторы и другие полезные запчасти разбирают по домам.
IT>

93-94 — повсеместное засилье IBM PC, все автоматизируются, программеры пишут каждый свой склад, бухгалтерию, зарплату (нужное подчеркнуть) и т.д.
IT>

95 — всё нормально, но такое ощущение, что чего-то не хватает. Графики, что ли? А может многозадачности?
IT>

96 — что это у тебя за игрушка, Windows? 95 говоришь? А, знаю, стоят эти тормоза у меня. Не то? А что в ней может быть нового? 32-х разрядная? Ладно, пошёл я, пора серьёзными делами заниматься.
IT>

97-98 — тотальный переход на W95.
IT>

99-00 — повсеместное засилье W95. Последнюю копию MS-DOS выкидывают вместе с поздно-уже-апгрейтовать 486 железякой.
IT>

01 — всё нормально, но такое ощущение, что чего-то не хватает. Компонентной модели что-ли? А может полноценных распределённых интернет-технологий.
IT>

02 — что это у тебя за игрушка? Дот-что? А... Дот-НЕТ. Ну, ну... Слышал. Веб-сервисы говоришь можно запускать... А как же COM+? Детский сад какой-то... Ладно, пошёл я, пора серьёзными делами заниматься.
IT>

...
IT>

IT>

IT>Дальнейший сценарий, думаю, мало чем будет отличаться. 6 лет, ну 7. И всё, эта песня хороша — начинай сначала.

А вот экскурс в, по-моему(слишком молод, я чтоб знать точно, что тогда было), несколько более ранние времена:

Real Programmers Don't Use PASCAL

Здравствуйте Рек, Вы писали:

Рек>Здравствуйте Sergey, Вы писали:

S>> А тебе не приходило в голову, что определяя функции или классы в C/C++, ты по сути дела определяешь новый язык? И решаешь задачу уже в рамках этого нового языка, образованного возможностями С++ и используемых тобой твоих/чужих библиотек?

Рек>Ну конечно! Только этим и занимаюсь. :)
Рек>И это отлично, что есть С++ — наиболее гибкий и выразительный из универсальных языков.

Рек>Но рамки ... они есть. сжимают. диктуют. Как думать. Из каких решений выбирать.

Угу. Есть такой момент. Но сжимают достаточно редко или слабо, чтобы побудить писать новый язык. Или просто идей свежих не хватает. Структурное программирование, ООП — и все :( . Функциональное программирование или там switch-технология на новые концепции, увы, не тянут (IMHO).

Рек>Язык должен диктоваться задачей — тогда успех.
Если ресурсов хватит :-\

Рек>Если решения продиктованы возможностями, тем что есть под рукой,
Рек>тем что умею, то получается как всегда. :)
Заработаешь себе на очередной бутерброд с маслом :) .
.
Рек>Ещё это страшное слово "патерны"! Шаблонные решения. Типовое мышление.
Рек>И говорят что это хорошо! :no:

Не надо путать типовое решение типовых задач с шаблонным мышлением. Решать типовые задачи сто раз опробованными методами — хорошо. Только при этом сначала надо подумать — а является ли решаемая задача типовой (и, соответственно, уместны ли здесь типовые решения).

Рек>Вспомните как родился C++.
Рек>Из потребностей и неудовлетворённости Стаутсрупа существовавшими тогда языками.
И не имевших приличной реализации идей ООП. Без которых Страутсруп вряд ли чего-нибудь стоящее сделал бы.

Рек>Он же делал язык под себя, для своих задач. Это было толчком.
Рек>Все можно было решить в рамках вуществовавших тогда языков, но чуть хуже.
Рек>А он нарушил све патерны и сделал по-своему.
Рек>И вот увидите, таких Страуструпов будет с каждым годом всё больше и больше.

Рек>И все мы в конечном счете станем Страуструпами. :))) Ура!!! Все в Старуструпы!

Ага, щаз... 99,9% людей будут хавать то, что им дадут (C++ библиотеки классов для работы с окошками по Win32 — яркий тому пример). 90% из них, правда, будут при этом ругаться, что кормят невкусно, зато только 1% скажут, чего именно в блюде не хватает. В лучшем случае один из нескольких тысяч замахнется на написание нового языка, да и то, в основном, по молодости. И только один из фиг знает скольки замахнувшихся доведет дело до мало-мальски работоспособного решения. А уж какой процент этих новых языков ожидает успех (или хотя бы признание), я и подумать боюсь...

Рек>Так... кажется пора слезать с трибуны.
Рек>А то сейчас начнут чем-нибудь кидаться...

Здравствуйте Курилка, Вы писали:

На мой взгляд основной недостаток C++ — солножть его применения для компонентного программирования.
C# позиционируется именно как язык компонентного программирования.

Чтобы не быть голословным поговорим о COM. Вроде все начинается как чистый C++ — интерфейсы как абстрактные классы и все такое.
Но есть еще MSIDL, и уже для того, чтобы использовать в своей программе другой компонент, даже написанный на
CPP мне приходится генерировать какойто специальный код при помощи #import. А послать или обработать событие? Ведь то, что делает ATL — это бред!
Не скажу, что в MFC лучше, но, для меня безусловно проще. А проще простого — в VB.

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

Особа прелесть — это h-файлы. Кто мне обяснит следующие вещи:

1) Почему в обявлении класса я могу написать:

class SomeClass {

static int MyProc(int a,int b=0);

};

а в реализации не

static int SomeClass::MyProc(int a,int b=0);

int SomeClass::MyProc(int a,int b);

теперь мне, чтобы понять что конкретно представляет MyProc придется лезть в h-файл,

или писать комментарии

/*static*/ int SomeClass::MyProc(int a,int b/*=0*/);

это касается и virtual.

2) Каким местом думал автор языка, когда вводил в него ключевые слова public, private и т.п, ведь теперь в больших классах (а я пишу такие классы, так получается :shuffle: ) приходится искать, где же там в верху стоит спецификатор доступа?

private:

// много-много строчек
// много-много строчек

int MyProc();

При этом, если я захочу сделать MyProc открытым, то мне обязательно нужно будет найти в верху этот дурацкий private: и опять поставить его после
MyProc(); А то вдруг там стоит protected:(? Мне это иногда очень напоминает on error goto из Basic'a. Кроме того, в файле реализации (CPP) опять не видно, с каким доступом объявлен метод.

В итоге, возможно вообще придется писать в стиле

class SomeClass {

public: int Proc1();
public: static int Proc2(int a=0);
....

}

и потом в CPP

/*public:*/ int SomeClass::Proc1() { };
/*public: static */int SomeClass::Proc2(/*int a=0*/) { };

Я правда до этого еще не дошел, но подумываю об этом (и о C#, конечно :) )

Я все это написал не потому, что мне очень не нравится C++, я на этом языке прогаммирую уже очень давно (начиная с VC1.5). Просто в последнее время
он меня стал немного утомлять вот такими непонятными вещами.

Здравствуйте Sergey, Вы писали:

S> Угу. Есть такой момент. Но сжимают достаточно редко или слабо, чтобы побудить писать новый язык. Или просто идей свежих не хватает. Структурное программирование, ООП — и все

. Функциональное программирование или там switch-технология на новые концепции, увы, не тянут (IMHO).

Есть ещё аспектно-ориентированное, это штука серьёзная, кое кто даже поговаривает, что дни ОО сочтены

Здравствуйте Mishka, Вы писали:

M>Здравствуйте Sergey, Вы писали:

S>> Угу. Есть такой момент. Но сжимают достаточно редко или слабо, чтобы побудить писать новый язык. Или просто идей свежих не хватает. Структурное программирование, ООП — и все

. Функциональное программирование или там switch-технология на новые концепции, увы, не тянут (IMHO).

M>Есть ещё аспектно-ориентированное, это штука серьёзная, кое кто даже поговаривает, что дни ОО сочтены

а можно вот здесь поподробнее?
ссылкой в меня киньте, если не жалко...

Здравствуйте al, Вы писали:

al>2) Каким местом думал автор языка, когда вводил в него ключевые слова public, private и т.п...

Заметь, он думал над этим 20! лет назад. Не удивительно, что по прошествии такого времени мы можем видеть некоторые недостатки в языке.

al>Я все это написал не потому, что мне очень не нравится C++, я на этом языке прогаммирую уже очень давно (начиная с VC1.5). Просто в последнее время он меня стал немного утомлять вот такими непонятными вещами.

Это правда. Но самое печальное, что новый стандарт C++, что-то типа C++0x, не предполагает изменений в самом языке, только некоторые улучшения в библиотеках. А это настораживает, получается, что C++ врядли будет дальше развиваться.

Здравствуйте Курилка, Вы писали:

К>а можно вот здесь поподробнее?
К>ссылкой в меня киньте, если не жалко...

www.aspectj.org

Здравствуйте Курилка, Вы писали:

К>а можно вот здесь поподробнее?
К>ссылкой в меня киньте, если не жалко...

и ещё aosd.net

Здравствуйте Рек, Вы писали:

Рек>Универсальные языки программипрования по большому счету должны уйти.

Думаю здесь ты ошибаешся. Я не против спец. языков, но именно их ниша очень узкая. Узкая но глубокая. Это судьба специализации. Или обо всем по чуть-чуть, поверхносно так..., или мало но конкретно. Это жизнь. И это только о языках. Среды же исполнения вообще специализированные ненужны. Это же системный слой. Надстройки специализированные да, но специальная ос для бухгалтерии! Бред. Хотя Оракл в своем маразме дожил до СУБД на голом железе. Хотя и это ерунда... там всеже ядно (чуть не написал ведро :) ) солярки есть. Спец языки хороши как дополнение на который можно решать конкретные задачи, а общие алгоритмы удобрее все же на универсальных (типа того же Шарпа) решать. .Net это и делает. Я (вроде) слышал про реализацию пролога (или чего-то похожего) для нет. Представь: пишиш игрушку (ну, пока я загибаю)... сложный кусок требующий оптимизации прописываешь на С++, а может на MSIL, а то и на асме для конкретной платформы... этот сложный кусок процентов пять от основного кода... интерфейс и некритичную логику пишиш на Шарпе, Васике или ОПаскале (коворят его тоже портонут)... доходишь до искуственного интелекта (AI)... о, а тут и пролог с другими спец. средствами пригодится. По-моему, красива... Как думаешь?

Рек>Их ниша должна быть гораздо меньше, чем сейчас.

Ну, я свою позицию обосновал, а твое обоснование меня как-то не убеждает. :-\

Рек>Выведь не носите одни и теже ботинки и летом и зимой?
(давай на ты?!)
Аналогии плохи не только тем, что зачатую приводят к демагогии, но и тем, что они не всегда соотвествуют жизни. :)
Рек>Представьте себе весь город в одних и тех же ботинках!

Представь себе я весь год кожу в одни и тех же батинках. :)) Ну, естественно пока они не состарятся. А жуву в 10 минутах от работы. Если куда надо, то или ловлю машину или еду на метро, которое и вовсе в 4 минутах от дома. Так что зимнии батинки мне безнадобности. А всему причиной среда и мои потребности. Но языки программирования здесь не причем. Так что давай лиже к телу. :)

Рек>А то что у нас всего десяток языков программирования на всю
Рек>многомиллионную братию программистов, это мы воспринимаем как должное? :no:
Рек>Привыкли... но это временно.

Ошибаетесь батенька. Мало языков сейчас. И не от бедности, а от того, что остальные вымерли. На заре программирования их были тысячи. Талько в недрах наших НИИ их наклепли с сотню...

Рек>Как только появится возможность... так у каждого из нас появится свой индивидуальный язык.

Да Якс и Лекс лет двадцать существуют. С их помошью сделать новый язых работа на два дня. Вот только это никому (ну, кроме тебя :) ) не нужно. Вернее, так может оно и нужно, но идти вперед — задача не из простых и дана не каждому. Прогресс идет. Туда или нет покажет время...

Рек>Мы его будем разнашивать как ботинки (отлажывать и приспосабливать).

Ты про ADA читал? Так вот сдохла она не родившись. А по "разнашиванию" она и сейчас всем фору даст.

Рек>Будем заказывать по индивидуальной мерке или долго ходить по шопам выбирая. :)

Так софт не ботинки. Проще написать функцию/класс/библиотеку и испльзовать из того языка который тебе лично больше нравится.

Рек>Посмотрите какой у человека язык и вы поймёте, какой он такой, что он может.

Новая наука?! Раньше гадали по руке... сетчатке глаза... а теперь еще по языку будут. :)

Рек>... и будут нас встречать "не по одёжке", а по языку, ну а провожать как всегда. :)))

Мордобоем, что ли? :shuffle:

Здравствуйте retalik, Вы писали:

R>Язык C++, действительно, довольно сложен — это один из главных его недостатков. И за полгода подготовить с нуля здравомыслящего программиста на нем невозможно (а на VB и шарпе — похоже, это нынешняя реальность). Только так ли это сейчас важно?

Я вот честно так и не понял, почему же C++ столь сложен. Вот все говорят: "сложен для изучения и т.п.". Неужели и правда так сложен? Или это у меня мозги столь набекрень, что я этой сложности не вижу. Некоторую "красоту" вижу, изворотливость вижу. А вот сложность... Хочешь пользуйся тем или другим, хочешь не пользуйся. И не обязательно все знать — можно некоторых тонкостей никогда и не коснуться. А придется коснуться — да, помозговать придется, пальчиком потыкать. А потом глядишь — ух ты, какая вещь получается! В общем с точки зрения ООП лучшего я пока ничего не видел. Но впрочем я и видел то немного. :) Объектного Паскаля я просто боюсь. А вот Джава... Это такая славненькая темная лошадка. В общем "учиться, учиться и еще раз учиться"! Надо же, какие слова были сказаны! :)

R>Во-вторых, заказчики рассматривают только результаты работы — им неважно, что ты использовал Супер(tm) Optimized FrameWork+(R), главное, чтобы было сделано в срок и не глючило.

Тут уже больше вопрос системной интеграции всего со всем. Что-то последнее время приходится не столько программировать, сколько "собирать конструктор". :) А это уже совсем другая история.

R>В-третьих, мне понравилась мысль, которую высказал VladD2: по-настоящему хорошие программисты на VB, Delphi и других RAD-остях получаются из программистов на C++. Это действительно так.

Тут я согласен: заставь меня писать на Delphi (денежкой) — что ж, буду писать. Ругать нехорошими словами Борланда, но писать. А суть примерно одна и та же, главное оператор присваивания не путать :) и не пытаться организовывать сложную классовую (шаблонную) структуру, а обходится простыми средствами. И усе будет путем!

Вот уже лет 20 как поговаривают что вот-вот скоро программировать не надо будет, а надо будет просто описать задачу и ее решение. Что-то типа того. Prolog в общем довольно занимательная штука...

Здравствуйте Курилка, Вы писали:

К>Здравствуйте VladD2, Вы писали:
VD>>Все эти Явы, Шарпы и Диии, как раз и пытаются устранить эту самую сложность, но иногда перегибают палку, хотя стройность Шарпа действительно подкупает...

К>Стесняюсь спросить, но что подразумевалось под Диии?

Это скоростное написание слава "Дельфи".

PS

Разговор с дувушкой пришедшей устраиваться секретарем:

— И с какой скоростью вы печатаете?

— 1200 знаков в минуту... но такая фигна пулучается.

Здравствуйте al, Вы писали:

al>2) Каким местом думал автор языка, когда вводил в него ключевые слова public, private и т.п, ведь теперь в больших классах (а я пишу такие классы, так получается

) приходится искать, где же там в верху стоит спецификатор доступа?

al>private:

al>// много-много строчек
al>// много-много строчек

al>

Не, ну я многое могу понять, но вот хоть убей не пойму почему ты не можешь писать:

private: int MyProc1();
private: int MyProc2();
public:  int MyProc3();
private: int MyProc4();

Может дело в восприятии мира?

Мне так по фигу эта мелочь.

Ну, а в остальном я солидарен.

Здравствуйте Рек, Вы писали:

Рек>Вспомните как родился C++.
Рек>Из потребностей и неудовлетворённости Стаутсрупа существовавшими тогда языками.
Рек>Он же делал язык под себя, для своих задач. Это было толчком.
Рек>Все можно было решить в рамках вуществовавших тогда языков, но чуть хуже.
Рек>А он нарушил све патерны и сделал по-своему.
Рек>И вот увидите, таких Страуструпов будет с каждым годом всё больше и больше.

Рек>И все мы в конечном счете станем Страуструпами.

Ура!!! Все в Старуструпы!

Ты читал Буча? Видел там на одной из первых страниц таблицу с расписанными по поколениям языками? После 3-го идет "потерянное поколение: много языков созданных, мало выживших." Все, кто поломятся в страуструпы, за оч. редким исключением, будут там же, где и языки этого поколения.

Я не думаю, что есть много в мире народа, которые могут изобрести то, что успешно используется сейчас для решения современных задач. Сложность этих задач как никогда высока. Появление С++, других языков — необходимость, которая позволила решать такие сложные задачи. И это хорошо, что есть выбор языков, но все они одной породы. Новый язык той же породы может войти в моду, получить популярность, но пока он будет в рамках той методологии, в которой сейчас языки развиваются (OOP) — это не будет прорывом.

Так что, это уже проходили. Не будет больше такого, как ты хочешь: "Каждому по языку!!!". Это — идеализм, а реальность другая. "Каждому по известному и зарекоммендовавшему себя инструментальному средству, и никакой самодеятельности!!!" Типа, девиз менеджера.

У Буча по поводу развития написано, что в большинстве современных систем кол-во аспектов таково, что охватить все их одному человеку больше не под силу. А если для реализации чего-то такого будут каждый на своем языке говорить, то знаешь что получится? Про вавилонскую башню слышал? (Кстати, линк)

Вот такие вот пироги. Такой подход не годится. Это проверено временем. И побороть такое положение дел очень мало кому по плечу. Это больше похоже было бы на атаку во время Финнской войны: с одной стороны — матросы с лопатами, а с другой — в три ряда бетонные доты с пулеметами, и с коммуникациями, с душами и саунами под замлей.

С уважением

Здравствуйте The Lex, Вы писали:

TL>Здравствуйте retalik, Вы писали:

R>>Язык C++, действительно, довольно сложен — это один из главных его недостатков. И за полгода подготовить с нуля здравомыслящего программиста на нем невозможно (а на VB и шарпе — похоже, это нынешняя реальность). Только так ли это сейчас важно?

TL>Я вот честно так и не понял, почему же C++ столь сложен. Вот все говорят: "сложен для изучения и т.п.". Неужели и правда так сложен? Или это у меня мозги столь набекрень, что я этой сложности не вижу. Некоторую "красоту" вижу, изворотливость вижу. А вот сложность... Хочешь пользуйся тем или другим, хочешь не пользуйся. И не обязательно все знать — можно некоторых тонкостей никогда и не коснуться. А придется коснуться — да, помозговать придется, пальчиком потыкать. А потом глядишь — ух ты, какая вещь получается! В общем с точки зрения ООП лучшего я пока ничего не видел. Но впрочем я и видел то немного.

Объектного Паскаля я просто боюсь. А вот Джава... Это такая славненькая темная лошадка. В общем "учиться, учиться и еще раз учиться"! Надо же, какие слова были сказаны!

Ты не понял. Для изучения фиг бы с ним. Помучился с пол года и все. Он сложен для восприятия. Причем как человеком, так и машиной (до сих пор нет ни одного правильного парсера, для комплит ворда). Читать извороты тяжело. Особено когда код чужой. За лесом кода не видно сути алгоритма. Хороший пример COM-объекты. Для их создания на C++ нужно написать гору кода, обычно с шаблонами и кучей наследования, а на VB пара строк. Тот же контроль памяти выливается в гору кода для хелперов или подсчета ссылок. ATL — это полтора мега текстов которые нужны только для того чтобы упростить работу. Ты открой реализацию тогоже ATL, глянь хотя бы на CWindowImpl<>. Да без спорно красиво, особенно сабкласинг. Да ни на одном другом современном языке так красиво не залудить (или вообще не получится, или большая чать будет на асме), но читать это без пол литры (а с не й тем более

) нет никакой мочи.

TL>Тут уже больше вопрос системной интеграции всего со всем. Что-то последнее время приходится не столько программировать, сколько "собирать конструктор".

А это уже совсем другая история.

Это кому как.

TL>Тут я согласен: заставь меня писать на Delphi (денежкой) — что ж, буду писать. Ругать нехорошими словами Борланда, но писать.

За-то радуешся, что ругаешь Борланд и Дельфи, а не любимый С++.

Здравствуйте VladD2, Вы писали:

VD>Ты не понял. Для изучения фиг бы с ним. Помучился с пол года и все. Он сложен для восприятия. Причем как человеком, так и машиной (до сих пор нет ни одного правильного парсера, для комплит ворда). Читать извороты тяжело. Особено когда код чужой. За лесом кода не видно сути алгоритма. Хороший пример COM-объекты. Для их создания на C++ нужно написать гору кода, обычно с шаблонами и кучей наследования, а на VB пара строк. Тот же контроль памяти выливается в гору кода для хелперов или подсчета ссылок. ATL — это полтора мега текстов которые нужны только для того чтобы упростить работу. Ты открой реализацию тогоже ATL, глянь хотя бы на CWindowImpl<>. Да без спорно красиво, особенно сабкласинг. Да ни на одном другом современном языке так красиво не залудить (или вообще не получится, или большая чать будет на асме), но читать это без пол литры (а с не й тем более :) ) нет никакой мочи. :(

Вы не поверите, но на Бейсике, Паскале и прочих, кто кричит о своей страшной простоте, структуированности и тому подобных вещах, люди пишут очаровательно, просто сногсшибательно нечитабельный код! Чего стоят толпы вложенных begin-end. Так что я не думаю что это проблема C++.

Насчет COM-объектов: я вот несколько недолюбливаю ATL. Скорее всего потому что просто еще не пробовал как следует. :) А пока пишу компоненты "ручками": беру обкатанный "базовый" проект и пишу в него методы интерфейсов и т.п. Что нехорошо — нет нормальной поддержки со стороны среды разработки: она все же под ATL заточена. Впрочем как и Колдуны в основном под MFC. А так — очень даже живенько получается. И не так уж сильно отличается от того, как я писал несколько лет назад на Borland C++ 3.1 практически не используя эти самые плюсы, т.е. классы. А шаблоны тогда еще и реализованы не были. И исключения тоже.

А WTL уж точно не пробовал и скорее всего уже и не попробую. :) А зачем? Я как писал приложения под Windows на классах-обертках, так и пишу. Особо не отличается. Все работает и все понятно. По мере необходимости можно что-либо разворотить в меру необходимости и получить то что хотелось получить. Но это все касается интерфейса пользователя. А вот "системная часть" как была голым кодом, так и осталась. Правда последнее время очень активно пользуюсь STL — надоело каждый раз "писать свой язык" :) и снова и снова изобретать списки, ассоциативные массивы и прочее. А так — раз-два и усе на мази. Конечно головой думать приходится. Но я снова повторяю, что гораздо больше приходится думать когда надо "вот эту штучку подключить к вот этой вот". :) Я был просто в восторге, когда моя клиентская программка заработала на Win95. После устновки WinSock и MDAC, которые стали как-то так тихо, мирно и спокойно и в нужное место и все сразу заработало. Вот за это я все же ценю Microsoft. Попробовать что-то из Oracle поставить! А потом еще и к этому подсоедениться. Правда никогда не пробовал ставить, но верю молве. :) Там уж точно своя операционная система. :)

А может просто Microsoft + Microsoft = Microsoft, а вот Oracle + "что-то" = "нечто". В общем в грядущей войне я пожалуй все же на стороне Microsoft. Но буду держать ухо востро: где будут больше платить... :) Чего и вам всем желаю!

Здравствуйте The Lex, Вы писали:

TL>...А так — очень даже живенько получается. ...

Ну, тогда, плиз, перепеши на C++ следующий код на VB script:

Sub FillTable (Cursor)
    Response.Write "<TABLE width='100%' border=0 cellSpacing=1 cellPadding=3 >" & vbCrLf
    For each col in Cursor.Columns 
        Response.Write "<TH class='header'>" & col.Caption & "</TH>"
    Next
    do Until Cursor.IsEOF
        Response.Write "<TR>"
        For each col in Cursor.Columns 
            Response.Write ascFmt(col)
        Next
        Response.Write "</TR>" & vbCrLf
        Cursor.FetchNext
    Loop
    Response.Write "<TABLE border=0 cellSpacing=1 cellPadding=3 >" & vbCrLf
End Sub

Желательно без спарт поинтеров и разных ATL-ов.

TL>А WTL уж точно не пробовал и скорее всего уже и не попробую.

А зачем?

Дык! Пока не попробуешь не узнаешь.

TL>Попробовать что-то из Oracle поставить! А потом еще и к этому подсоедениться. Правда никогда не пробовал ставить, но верю молве.

Там уж точно своя операционная система.

Ты знаешь пробывал. Проблем не больше че с MS. И там и там глюки, но работать можно.

TL>А может просто Microsoft + Microsoft = Microsoft, а вот Oracle + "что-то" = "нечто". В общем в грядущей войне я пожалуй все же на стороне Microsoft.

Тогда срочно учи C#/CLR (короче, .Net). А то и с MS дорожки разбегутся. MS отводит C++-у роль низкоуровневого сдедства для склейки CLR-мира с ОС. А ихний проповедник Д.Бокс вообще говорит "C++, Win32 API, COM мертвы и не будут больше развиваться. NT отведена роль HAL (хардварьной абстракции, слоя между железом и софтом), а .Net — это новая платформа MS". Во как. А ты еще COM-осваеваешь.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте The Lex, Вы писали:

TL>>...А так — очень даже живенько получается. ...

VD>Ну, тогда, плиз, перепеши на C++ следующий код на VB script:
VD>

VD>Sub FillTable (Cursor)
VD>    Response.Write "<TABLE width='100%' border=0 cellSpacing=1 cellPadding=3 >" & vbCrLf
VD>    For each col in Cursor.Columns 
VD>        Response.Write "<TH class='header'>" & col.Caption & "</TH>"
VD>    Next
VD>    do Until Cursor.IsEOF
VD>        Response.Write "<TR>"
VD>        For each col in Cursor.Columns 
VD>            Response.Write ascFmt(col)
VD>        Next
VD>        Response.Write "</TR>" & vbCrLf
VD>        Cursor.FetchNext
VD>    Loop
VD>    Response.Write "<TABLE border=0 cellSpacing=1 cellPadding=3 >" & vbCrLf
VD>End Sub
VD>

VD>Желательно без спарт поинтеров и разных ATL-ов.

Без проблем! Берем объекты Cursor и Response и пишем все один в один. Вопрос лишь в том где взять эти объекты. А откуда они в VBS взялись? Дык они там и были всегда, да?

TL>>А WTL уж точно не пробовал и скорее всего уже и не попробую.

А зачем?

VD>Дык! Пока не попробуешь не узнаешь.

Дык! Потому и пробовать не буду, что "MS отводит C++-у роль низкоуровневого сдедства для склейки CLR-мира с ОС. А ихний проповедник Д.Бокс вообще говорит "C++, Win32 API, COM мертвы и не будут больше развиваться"

TL>>Попробовать что-то из Oracle поставить! А потом еще и к этому подсоедениться. Правда никогда не пробовал ставить, но верю молве.

Там уж точно своя операционная система.

VD>Ты знаешь пробывал. Проблем не больше че с MS. И там и там глюки, но работать можно.

Верю что Вы пробовали, искренне верю. Но разве не правда что с точки зрения администрирования Microsoft все же ближе к идеалу "поставилось само и само заработало"? Да, у меня очень мало опыта с другими о чем искренне сожалею.

TL>>А может просто Microsoft + Microsoft = Microsoft, а вот Oracle + "что-то" = "нечто". В общем в грядущей войне я пожалуй все же на стороне Microsoft.

VD>Тогда срочно учи C#/CLR (короче, .Net). А то и с MS дорожки разбегутся. MS отводит C++-у роль низкоуровневого сдедства для склейки CLR-мира с ОС. А ихний проповедник Д.Бокс вообще говорит "C++, Win32 API, COM мертвы и не будут больше развиваться. NT отведена роль HAL (хардварьной абстракции, слоя между железом и софтом), а .Net — это новая платформа MS". Во как. А ты еще COM-осваеваешь.

Ну, COM я не столько осваиваю, сколько использую по мере необходимости. И пока успешно. А то что мне в нем не особо нужно, того не использую и не осваиваю. Так, почитываю научно-популярную литературу чтобы быть в курсе событий.

ИМХО: NT и иже с ним еще по крайней мере пару лет не сдадут своих позиций. UNIX тоже стар как мир...

А новое изучать конечно же надо! А еще штудировать английский и немецкий языки...

Еще раз повторяю: ИМХО.

P.S. То, что я стараюсь ко всем обращаться на "Вы" прошу не считать признаком моей зелености...

Здравствуйте VladD2, Вы писали:

VD>Не, ну я многое могу понять, но вот хоть убей не пойму почему ты не можешь писать:

VD>

VD>private: int MyProc1();
VD>private: int MyProc2();
VD>public:  int MyProc3();
VD>private: int MyProc4();
VD>

VD> :???:

VD>Может дело в восприятии мира? :)

VD>Мне так по фигу эта мелочь.

Так я и говорил, что практически готов к этому:), хотя на самом деле хочется писать
private int MyProc1();, а еще больше просто int MyProc1(), а private пусть будет по умолчанию! (т.е. евно указываем только public и protected).

А еще мне очень не понятен смысл ::, т.е. почему int MyClsss::MyProc1(), а не int MyClass.MyProc1() ?
А еще я хочу оператор with и много чего еще :)

Вообще я очень рад тому, что в этом форуме меня срезу не " :maniac: "

Второй реальной проблемой языка C++ помимо его "древности" и вытекающих из нее таких-вот особенностей
я считаю то, что стандарт языка и его конкретные реализации развивались параллельно. В итоге мы сейчас
имеем, например, такие вещи, как MFC, которая ничего не знает о пространствах имен и имеет свои
собственные классы-контейнеры. Теперь есть STL, но и MFC обзавелась своими шаблонами CMap<...> и т.п.
Кроме того есть вообще разные реализации STL.

MFC идет своим путем, а на мой скромный взгляд большинство пишущих в VC — это не C++ программисты, а MFC программисты.
В своей большой программе я изначально использовал MFC-контейнеры, потом попытался использовать STL, но потом
всетаки вернулся в MFC-шаблонам. STL конечно лучше и удобнее, но сказывается и привычка, и не желание смешивать разные
технологии в одной программе, ведь MFC у себя в нутри использует свои контейнеры, а не STL.

Кроме того, в MFC (которая появилась хрен знает когда, еще в MS С/С++ 7.0 (не Visual, а просто MS C/C++) и могла
работать даже под DOS) был реализован свой механизм исклбчений — макросы TRY, CATCH и т.п. При чем эти макросы
используются и в современных реализациях MFC, и, хотя они теперь используют try / catch в своей работе,
но для обработки исключений MFC следует использовать именно эти макросы! Это связано с тем, что MFC передает
параметр исключения (потомок CException) как адрес, т.к. это эффективнее. Т.е. когда
мы пишем, например, AfxThrowArchiveException, то где-то там в нутри создается экземпляр
CArchiveException при помощи оператора new и реально возбуждается исклбчение типа CArchiveException*.
При этом если мы для его обработки напишем catch (CArchiveException), мы вообще ничего не поймаем, т.к.
макрос CATCH сам добавляет * после своего параметра



#define CATCH(class, e) } catch (class* e)     { ASSERT(e->IsKindOf(RUNTIME_CLASS(class)));         _afxExceptionLink.m_pException = e;

кроме того макросы MFC отвечают за удаление C...Exception*.

Это было одной из причин отказа от STL, т.к. мне приходилось иногда обрабаывать в одном месте исключение и от
MFC и от STL (что-то типа catch(...) -т.е. прсто возникла ошибка, все равно какая) — тут возникали большие проблемы.
Приходилось разбираться, чье это исключение — STL или MFC.

О смешивании MFC и ATL я говорить не буду, т.к. это уже проблема не С++, а MS VC++.

Здравствуйте Mishka, Вы писали:

M>Здравствуйте Курилка, Вы писали:

К>>а можно вот здесь поподробнее?
К>>ссылкой в меня киньте, если не жалко...

M>www.aspectj.org

Чё-то почитал, но как-то туманно всё... ООП для меня гораздо понятнее (или просто технология уже зрелая?)
Интересно: кто-нибудь разобрался в этом деле?

Здравствуйте Курилка, Вы писали:

К>Здравствуйте Mishka, Вы писали:

M>>Здравствуйте Курилка, Вы писали:

К>>>а можно вот здесь поподробнее?
К>>>ссылкой в меня киньте, если не жалко...

M>>www.aspectj.org

К>Чё-то почитал, но как-то туманно всё... ООП для меня гораздо понятнее (или просто технология уже зрелая?)
К>Интересно: кто-нибудь разобрался в этом деле?

На самом деле там нет ничего такого уж страшного. Всё достаточно просто: все методы класса — это объекты с событиями Before(возникает перед вызовом метода), After(после), Throwing(если метод выкидывает исключение). Аспект — это обработчик этих событий, вот вообшем-то и вся идея. Правда из этого действительно много можно получить. Особенно преимущества заметны когда теряется необходимость в паттерне Observer[GoF], там где-то пример есть на AspectJ написанный.
Я тут начал проектировать для внутренних разработок свой язык, собираюсь поиспользовать часть идей из аспектной ориентации.

Здравствуйте Mishka, Вы писали:

M>Здравствуйте Курилка, Вы писали:

К>>Здравствуйте Mishka, Вы писали:

M>>>Здравствуйте Курилка, Вы писали:

К>>>>а можно вот здесь поподробнее?
К>>>>ссылкой в меня киньте, если не жалко...

M>>>www.aspectj.org

К>>Чё-то почитал, но как-то туманно всё... ООП для меня гораздо понятнее (или просто технология уже зрелая?)
К>>Интересно: кто-нибудь разобрался в этом деле?

M>На самом деле там нет ничего такого уж страшного. Всё достаточно просто: все методы класса — это объекты с событиями Before(возникает перед вызовом метода), After(после), Throwing(если метод выкидывает исключение). Аспект — это обработчик этих событий, вот вообшем-то и вся идея. Правда из этого действительно много можно получить. Особенно преимущества заметны когда теряется необходимость в паттерне Observer[GoF], там где-то пример есть на AspectJ написанный.
M>Я тут начал проектировать для внутренних разработок свой язык, собираюсь поиспользовать часть идей из аспектной ориентации.

Если я не ошибаюсь, что в CLOS эти After и Before точно вроде уже как не один год есть (точно не помню, но кажется у Буча было упоминание), но там вроде никто про аспекты не говорил...
Ладно, надо поподробнее посмотреть — всё таки "век живи — век учись"

Здравствуйте Курилка.

Так ведь всё ж уже давно придумано, целые университеты вторую половину 20 века только и клепали теоретические основы

, вот только сейчас мы добираемся до их практической реализации

. Вот сдунуть бы пыль с томов 50-летней давности, там поди и ни такое найти можно было бы

Здравствуйте The Lex, Вы писали:

TL>

Без проблем! Берем объекты Cursor и Response и пишем все один в один. Вопрос лишь в том где взять эти объекты.

Шустрый больно.

Каждая строчка на VBS у тебя в 3-5 сишных привратится, а с грамотной обработкой ошибок и 1:20 может получится.

А откуда они в VBS взялись? Дык они там и были всегда, да?

Нет, это объекты ASP, и нашего ascDB (в место него можно сунуть ADO, разницы не будет).

TL>>>А WTL уж точно не пробовал и скорее всего уже и не попробую.

А зачем?

VD>>Дык! Пока не попробуешь не узнаешь.

TL>Дык! Потому и пробовать не буду, что "MS отводит C++-у роль низкоуровневого сдедства для склейки CLR-мира с ОС. А ихний проповедник Д.Бокс вообще говорит "C++, Win32 API, COM мертвы и не будут больше развиваться"

Маладэсь Валэрик! (из анекдота).

VD>>Ты знаешь пробывал. Проблем не больше че с MS. И там и там глюки, но работать можно.

TL>Верю что Вы пробовали, искренне верю. Но разве не правда что с точки зрения администрирования Microsoft все же ближе к идеалу "поставилось само и само заработало"? Да, у меня очень мало опыта с другими о чем искренне сожалею.

Ну, в общем да. Особенно если ставишь не под NT, а под разные клоны Унихов.

TL>P.S. То, что я стараюсь ко всем обращаться на "Вы" прошу не считать признаком моей зелености...

Да никто и не считает. Только прияно когда в дружеской беседе тебя все же на ты на зывают.

Здравствуйте al, Вы писали:

al>Так я и говорил, что практически готов к этому

, хотя на самом деле хочется писать
al>private int MyProc1();, а еще больше просто int MyProc1(), а private пусть будет по умолчанию! (т.е. евно указываем только public и protected).

А вот мы болше COM-объекты пишем. В них все что не в IDL все приват, хотя и паблик. А приват вообще избегаем или протектед или паблик. Я вообще считаю приват ошибкой природы.

al>А еще мне очень не понятен смысл ::, т.е. почему int MyClsss::MyProc1(), а не int MyClass.MyProc1() ?

Ну, это просто... По синтаксису языка. Страус еще знаешь чё зчудил? Вместо точки "->" для доступа к бленам по указателю использует! Во гад?

А если серьезно пиши на C# бедет нехватать гадостей из C++ делай маленький хелпер на C++ и используй его из Шарпа.

al>А еще я хочу оператор with и много чего еще

Ну, тоды пише на Васике.Нет!

al>Вообще я очень рад тому, что в этом форуме меня срезу не "

"

Погоди... здесь народ добрый еще огреют.

al>Второй реальной проблемой языка C++ помимо его "древности" и вытекающих из нее таких-вот особенностей я считаю то, что стандарт языка и его конкретные реализации развивались параллельно. В итоге мы сейчас имеем, например, такие вещи, как MFC, которая ничего не знает о пространствах имен и имеет свои собственные классы-контейнеры.

Знаешь. Вот MFC мне почему-то не нравится. И с самого начала не наравилась.

al>Теперь есть STL, но и MFC обзавелась своими шаблонами CMap<...> и т.п.

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

al>Кроме того есть вообще разные реализации STL.

Заметь реализации! А стандарт един. Пожалуй это лучшая черта STL-а.

al>MFC идет своим путем, а на мой скромный взгляд большинство пишущих в VC — это не C++ программисты, а MFC программисты.

Ну, мы так пишим с использованием ATL/WTL/ascLib. Чёж бы теперь тоже не на нем пишим. И почему тогда наши программы тем же Борлондом компилируются? Так что не путай библиотеки, пусть даже стандартные, и язык.

al>В своей большой программе я изначально использовал MFC-контейнеры, потом попытался использовать STL, но потом всетаки вернулся в MFC-шаблонам. STL конечно лучше и удобнее, но сказывается и привычка, и не желание смешивать разные технологии в одной программе, ведь MFC у себя в нутри использует свои контейнеры, а не STL.

Ну, мы вообще свои написали. И не жалеем. Не так уж много времени это заняло. За-то какая гибкость...

al>Кроме того, в MFC (которая появилась хрен знает когда, еще в MS С/С++ 7.0 (не Visual, а просто MS C/C++) и могла работать даже под DOS) был реализован

Нда... Мне казалось что мфси появилась вместе с VC 1.0. Ну, могёт быть...

Здравствуйте VladD2, Вы писали:

VD>... пиши на C# бедет нехватать гадостей из C++ делай маленький хелпер на C++ и используй его из Шарпа.

Так и собираюсь делать, только подожду SP1 (а лучше 2) для VS7.

al>>А еще я хочу оператор with и много чего еще :)

VD>Ну, тоды пише на Васике.Нет! ;)

Тоже можно. Ты посмотри, в MSDN описания C# и VB.Net сведены в одну папку. Я и сейчас использую VB в работе, ничего, язык как язык, со своими
плюсами и минусами. На мой взгляд в VB.Net есть несколько вещей, делающих его более удобным чем C# (то-же with), и менее удобным (как себе представлю,
что теперь придется писать еще и End Try и Exit Try, это еще "гаже" чем бегин/енд в паскале:)

al>>В своей большой программе я изначально использовал MFC-контейнеры, потом попытался использовать STL, но потом всетаки вернулся в MFC-шаблонам. STL конечно лучше и удобнее, но сказывается и привычка, и не желание смешивать разные технологии в одной программе, ведь MFC у себя в нутри использует свои контейнеры, а не STL.

VD>Ну, мы вообще свои написали. И не жалеем. Не так уж много времени это заняло. За-то какая гибкость...

Я очень много чего хочу написать своего (в этом списке есть и двоичный формат типа реестра Windows, и скрипровый яхык липа VBA c отладчиком и
IDE, и контейнеры, и оконный интерфейс и т.п), но реалность задает свои условия — использую то что есть, т.к. времени не хватает, а кушать
хочется.

VD>Нда... Мне казалось что мфси появилась вместе с VC 1.0. Ну, могёт быть...

Есть такой монстр — MFC1.0 — у меня есть MS C/C++7.0 — типа двадцать пятидюймовых дисков, IDE — PWB2.0 (DOS из под Windows), отладчик CodeView и т.п. В Visal 1.0 — та-же MFC, но IDE уже в Windows + ClassWizard для MFC (раньше приходилость все карты тообщений писать ручками — чума!).

Здравствуйте al, Вы писали:

VD>>... пиши на C# бедет нехватать гадостей из C++ делай маленький хелпер на C++ и используй его из Шарпа.

al>Так и собираюсь делать, только подожду SP1 (а лучше 2) для VS7.

Тогда уж жди .Net-2.

VD>>Ну, тоды пише на Васике.Нет!

al>Тоже можно. Ты посмотри, в MSDN описания C# и VB.Net сведены в одну папку. Я и сейчас использую VB в работе, ничего, язык как язык, со своими плюсами и минусами. На мой взгляд в VB.Net есть несколько вещей, делающих его более удобным чем C# (то-же with), и менее удобным (как себе представлю,
al>что теперь придется писать еще и End Try и Exit Try, это еще "гаже" чем бегин/енд в паскале

Да я собственно серьезно. С подобным подходом действительно VB.Net луший выбор. Я лично отдаю предпочтение Шарпу, так как обычно приношу простоту в угоду гибкости, а так как VB и C# с точки зрения простоты очень близки, то и выбор однозначный. Но и выбор Васика тоже понимаю.

al>>>В своей большой программе я изначально использовал MFC-контейнеры, потом попытался использовать STL, но потом всетаки вернулся в MFC-шаблонам. STL конечно лучше и удобнее, но сказывается и привычка, и не желание смешивать разные технологии в одной программе, ведь MFC у себя в нутри использует свои контейнеры, а не STL.

VD>>Ну, мы вообще свои написали. И не жалеем. Не так уж много времени это заняло. За-то какая гибкость...

al>Я очень много чего хочу написать своего (в этом списке есть и двоичный формат типа реестра Windows, и скрипровый яхык липа VBA c отладчиком и IDE, и контейнеры, и оконный интерфейс и т.п), но реалность задает свои условия — использую то что есть, т.к. времени не хватает, а кушать хочется.

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

VD>>Нда... Мне казалось что мфси появилась вместе с VC 1.0. Ну, могёт быть...

al>Есть такой монстр — MFC1.0 — у меня есть MS C/C++7.0 — типа двадцать пятидюймовых дисков, IDE — PWB2.0 (DOS из под Windows), отладчик CodeView и т.п. В Visal 1.0 — та-же MFC, но IDE уже в Windows + ClassWizard для MFC (раньше приходилость все карты тообщений писать ручками — чума!).

Я это чудо перескачил.

Четверкой пользовался, пятеркой тоже, но тогда это еще был просто С (не ++).

Здравствуйте VladD2, Вы писали:

TL>>

Без проблем! Берем объекты Cursor и Response и пишем все один в один. Вопрос лишь в том где взять эти объекты.

VD>Шустрый больно.

Каждая строчка на VBS у тебя в 3-5 сишных привратится, а с грамотной обработкой ошибок и 1:20 может получится.

Это только потому, что ты директиву #import и за директиву то не считаешь. С ней будет не больше чем на VB.

VD>А откуда они в VBS взялись? Дык они там и были всегда, да?

VD>Нет, это объекты ASP, и нашего ascDB (в место него можно сунуть ADO, разницы не будет).

Признайся, это было не совсем честно предложить пример на ASP

TL>>P.S. То, что я стараюсь ко всем обращаться на "Вы" прошу не считать признаком моей зелености...

VD>Да никто и не считает. Только прияно когда в дружеской беседе тебя все же на ты на зывают.

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

Здравствуйте IT, Вы писали:

IT>Здравствуйте VladD2, Вы писали:

TL>>>P.S. То, что я стараюсь ко всем обращаться на "Вы" прошу не считать признаком моей зелености...

VD>>Да никто и не считает. Только прияно когда в дружеской беседе тебя все же на ты на зывают.

IT>К тому же, как я уже говорил, обращение на 'Вы' на нашем сайте обычно не предвещает ничего хорошего.

Ну вы, господа, совсем достали!

Ну нравится мне выказывать свое уважение к собеседнику, называя его на Вы! Ясен пень — английский такого не позволяет — довольно бедный язык...

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте al, Вы писали:

VD>>>... пиши на C# бедет нехватать гадостей из C++ делай маленький хелпер на C++ и используй его из Шарпа.

al>>Так и собираюсь делать, только подожду SP1 (а лучше 2) для VS7.

VD>Тогда уж жди .Net-2.

Жду. А серьезно, я действительно жду SP, т.к. судя по некоторым сообщениям в ветке .Net, там есть определенные проблемы (например, c WinForms).
Да я и сам знаю та пару глюков. К стати, когда мы покупали VS6, SP1 уже лежал в коробке!= на отдельном CD с наклейкой "ПОСТАВИТЬ СРАЗУ ПОСЛЕ
УСТАНОВКИ VS!".

VD>Я это чудо перескачил.

Четверкой пользовался, пятеркой тоже, но тогда это еще был просто С (не ++).

А вот ни 4, ни 5 ни 6 я не видел. Сидел на TP. 7 тоже не особенно пользовался, но по его шикарной документации учил английский (в рамках необходимого). Там был еще оодин прикол — реализация шаблонов через макросы!

(это Страуструп бегает за Гейтсом после этого)

Здравствуйте al, Вы писали:

al>Там был еще оодин прикол — реализация шаблонов через макросы!

(это Страуструп бегает за Гейтсом после этого)

Эту реализацию Страуструп сам предлагал в качестве решения проблемы параметризации типов, так что Биляра тут не при чём. В одном из первых компиляторов C++ — Zortech C++ это дело тоже было представлено в полный рост. Списки там всякие, деревься. Прикольно смотрелось, но работало.

P.S. Все, кончаем базар, а то посмотри в верх, сколко наколбасили!

Здравствуйте IT, Вы писали:

VD>>Шустрый больно.

Каждая строчка на VBS у тебя в 3-5 сишных привратится, а с грамотной обработкой ошибок и 1:20 может получится.

IT>Это только потому, что ты директиву #import и за директиву то не считаешь. С ней будет не больше чем на VB.

Ну, и с той же скоростью. К тому же она нестандартная. Если бы мы ее использовали, то на Борлонде скомпилироваться не удалось бы. Хотя кому она надо.

VD>>А откуда они в VBS взялись? Дык они там и были всегда, да?

VD>>Нет, это объекты ASP, и нашего ascDB (в место него можно сунуть ADO, разницы не будет).

IT>Признайся, это было не совсем честно предложить пример на ASP

Да какой под рукой попался тот и сунул.

Вон в ASP.Net можено их на С++ писать. Признайся, ты будеш это делать?

TL>>>P.S. То, что я стараюсь ко всем обращаться на "Вы" прошу не считать признаком моей зелености...

VD>>Да никто и не считает. Только прияно когда в дружеской беседе тебя все же на ты на зывают.

IT>К тому же, как я уже говорил, обращение на 'Вы' на нашем сайте обычно не предвещает ничего хорошего.

Даааа ужжжж.

Здравствуйте al, Вы писали:

al>Жду. А серьезно, я действительно жду SP, т.к. судя по некоторым сообщениям в ветке .Net, там есть определенные проблемы (например, c WinForms).
al>Да я и сам знаю та пару глюков. К стати, когда мы покупали VS6, SP1 уже лежал в коробке!= на отдельном CD с наклейкой "ПОСТАВИТЬ СРАЗУ ПОСЛЕ
al>УСТАНОВКИ VS!".

Я уже опробывал релиз и поюзал обе бэты. И могу с уверенностью сказать, что количество глюков не критично. Делать коммерческие проекты можно. В шестерке даже с пятым SP глюков хватает. Так можно и всю жизнь прождать. К релизу твоей программы SP уже выйдет...

VD>>Я это чудо перескачил.

Четверкой пользовался, пятеркой тоже, но тогда это еще был просто С (не ++).

al>А вот ни 4, ни 5 ни 6 я не видел. Сидел на TP. 7 тоже не особенно пользовался, но по его шикарной документации учил английский (в рамках необходимого). Там был еще оодин прикол — реализация шаблонов через макросы!

(это Страуструп бегает за Гейтсом после этого)

А ты не видел эмуляцию шаблонов на Дельфи?

Здравствуйте VladD2, Вы писали:

IT>>Это только потому, что ты директиву #import и за директиву то не считаешь. С ней будет не больше чем на VB.

VD>Ну, и с той же скоростью. К тому же она нестандартная. Если бы мы ее использовали, то на Борлонде скомпилироваться не удалось бы. Хотя кому она надо.

Ты думаешь от неё сильные тормоза? Она делает тоже самое что и ты после каждого вызова метода — проверяет HRESULT, всё. А про Борланд — это конечно да, но это уже ваши проблемы

IT>>Признайся, это было не совсем честно предложить пример на ASP

VD>Да какой под рукой попался тот и сунул.

VD>Вон в ASP.Net можено их на С++ писать. Признайся, ты будеш это делать?

Каюсь, уже делаю

Здравствуйте IT, Вы писали:

IT>Здравствуйте VladD2, Вы писали:

IT>>>Это только потому, что ты директиву #import и за директиву то не считаешь. С ней будет не больше чем на VB.

VD>>Ну, и с той же скоростью. К тому же она нестандартная. Если бы мы ее использовали, то на Борлонде скомпилироваться не удалось бы. Хотя кому она надо.

IT>Ты думаешь от неё сильные тормоза? Она делает тоже самое что и ты после каждого вызова метода — проверяет HRESULT, всё.

Ага. А про замечательные _bstr_t, ... и обертки забыл? Ну, не перевариваю я этой кривизны. Какой смысл тогда на C++ писать? На ведь VB в раз проще...

VD>>Вон в ASP.Net можено их на С++ писать. Признайся, ты будеш это делать?

IT>Каюсь, уже делаю

Маньяк!

Здравствуйте VladD2, Вы писали:

VD>>>Вон в ASP.Net можено их на С++ писать. Признайся, ты будеш это делать?

IT>>Каюсь, уже делаю

VD>Маньяк!

Ну не всё конечно

, а только обёртку для зипования файлов, может быть в будущем индексилку, но ведь делаю.

Кстати, что-то я не нашёл в .NET компоненты для упаковки/распаковки файлов в/из ZIP. Это так задумано или я плохо искал?

Здравствуйте IT, Вы писали:

IT>Это правда. Но самое печальное, что новый стандарт C++, что-то типа C++0x, не предполагает изменений в самом языке, только некоторые улучшения в библиотеках. А это настораживает, получается, что C++ врядли будет дальше развиваться.

А нужно ли дальнейшее развитие С++?
На мой взгляд — нет, ведь у него абсолютно другие задачи, это ен прикладной язык, а системный и переносимый. У меня все эти MS specific уже сидят неизвестно шде, но да и чёрт с этим.
Дело в другом — на С++ сейчас можно сделать пчти всё что угодно, но стоит ли развивать сам язык, для того что бы получить из широкопрофильного языка узкоспециализированный? МС правильно с одной стороны сделали — взяли лучшее из С++ и перекинули в C#, а что было бы если бы они изменили С++? поднлся бы вой — да что это такое, дакак так и в том духе, т.е. с одной стороны все за изменения, вне зависимости от того, нужны они или нет, а сдруго — против, т.к. при этом нарушается совместимость/переносимость (да о чем тут и говорить, мне что бы написать переносимый код приходиться всё вподряд испещрять #if #else #endif и отключать иногда поддержку совместимости с MS VC++ у интеловского комилятора)

Возьмём, к примеру, Garbage Collector. Бесспорно, грамотно реализованная — это оченб удобная фича, но стоит ли её вводить в С++? С одной стороны, это можно сделать используя возмосжности языка, а с другой — это получится C#, в некотором роде, когда для прямой работы с памятью приходиться писать unsafe fixed код.

МС правильно поступает, выпуская более высокоуровневые языки — VB, C# — ну нельзя же использовать С++ как универсальный молоток для забивания всех гвоздей. С++ должен занять место примерно как и ассемблер — все слышали, многие со справочником могут понять что происходит и лишь единицы из общей массы — писать. Не у всех же Pnp девайс "hand" Пропатчен до прямого состояни, и по-этому их код падал, падает и будет падать.

Итого — на мой взгляд, дальнейшее развитие С++ для превращения его в высокоуровневый язык для нормальной работы с win32 не нужно.

Здравствуйте IT, Вы писали:

IT>Кстати, что-то я не нашёл в .NET компоненты для упаковки/распаковки файлов в/из ZIP. Это так задумано или я плохо искал?

MS почему-то zip-ы cab-ами называет. Не пробывал искать апи для кабов (ну или инсталяторов)?

всегда есть люди которые делают VB,C#,Java и те кто ими пользуется.

Здравствуйте IT, Вы писали:

IT>Заметь, он думал над этим 20! лет назад. Не удивительно, что по прошествии такого времени мы можем видеть некоторые недостатки в языке.

Удивительно другое. Целая армия программистов не желает видеть ни одного недостатка. Фанатство в чистом виде.

... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 12.1.0.1028.36665 >>

Здравствуйте VuDZ, Вы писали:

VDZ>...но стоит ли развивать сам язык, для того что бы получить из широкопрофильного языка узкоспециализированный?

А почему собственно "узкоспециализированный"? Язык можно развивать и не заужая рамки. C# тем и плох, что не перенял у своего брата многие полезные черты. Есть даже обоснования почему это было сделано (вернее не сделано). Но выглядят они припохабно. Мол мы не можем обеспечить 100%-ой детерминированности уничтожения объекта если хоть где-то применим GC, а заначит выкинем эту фичу на фиг. Уничтожайте ресурсы вручную. В качестве кости мы вам using всунем. Шаблоны вообще в спшке не сделали. Ну да ладно. В конце концов MS в рыночной экономике. Думаю, рынок их впихнет в нужную струю.

... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 12.1.0.1028.36665 >>

Здравствуйте The Lex, Вы писали:

TL>Дык! Потому и пробовать не буду, что "MS отводит C++-у роль низкоуровневого сдедства для склейки CLR-мира с ОС.

Надо и своей головой думать. Микрософт много чему отводит место, однако даже ее агрессивная политика не всегда приводит к результатам, ею желаемыми. Несмотря на активное продвижение XPени, до сих пор у поти половины (!) российских пользователей стоит Win98. А почему? Потому что просто непонятно, на кой XPень нужна, когда и то, что есть работает вполне удовлетворительно. С .Net тоже самое. Это медленная, кривая платформа. Конечно, со временем ее улучшат, но по большому счету зачем она нужна? От силы ее существование можно обосновать стремлением Микрософт к мировому господству и желанием людей ставить себе на компьютер сомнительные программы в поисках острых ощущений.

TL>А ихний проповедник Д.Бокс вообще говорит "C++, Win32 API, COM мертвы и не будут больше развиваться"

К словам микрософтовских апологетов следует относится с изрядной долей скептицизма

.

TL>Верю что Вы пробовали, искренне верю. Но разве не правда что с точки зрения администрирования Microsoft все же ближе к идеалу "поставилось само и само заработало"? Да, у меня очень мало опыта с другими о чем искренне сожалею.

Да, она ближе. Проблемы начинаются, когда оказывается, что работает не так как нужно

.

TL>ИМХО: NT и иже с ним еще по крайней мере пару лет не сдадут своих позиций. UNIX тоже стар как мир...

А новое изучать конечно же надо! А еще штудировать английский и немецкий языки...

Испанский и португальский не забудь

Здравствуйте The Lex, Вы писали:

TL>Ну вы, господа, совсем достали!

Почему? You — это и есть вы. Ты будет "thou".

Здравствуйте VladD2, Вы писали:

VD>А почему собственно "узкоспециализированный"? Язык можно развивать и не заужая рамки. C# тем и плох, что не перенял у своего брата многие полезные черты. Есть даже обоснования почему это было сделано (вернее не сделано). Но выглядят они припохабно. Мол мы не можем обеспечить 100%-ой детерминированности уничтожения объекта если хоть где-то применим GC, а заначит выкинем эту фичу на фиг. Уничтожайте ресурсы вручную. В качестве кости мы вам using всунем. Шаблоны вообще в спшке не сделали. Ну да ладно. В конце концов MS в рыночной экономике. Думаю, рынок их впихнет в нужную струю.

Скорее Микрософт подпихнет рынок туда, куда нужно

Здравствуйте IT, Вы писали:

IT>Здравствуйте VladD2, Вы писали:

<skipped>

это все правильно, только на каждый период есть очень простой ответ: "Ладно, я пошел, меня ждет мой UNIX" :))

И UNIX еще очеь долго будет жить, и еще неизвестно, кто кого переживет

Здравствуйте Aquila, Вы писали:

VD>>А почему собственно "узкоспециализированный"? Язык можно развивать и не заужая рамки. C# тем и плох, что не перенял у своего брата многие полезные черты. Есть даже обоснования почему это было сделано (вернее не сделано). Но выглядят они припохабно. Мол мы не можем обеспечить 100%-ой детерминированности уничтожения объекта если хоть где-то применим GC, а заначит выкинем эту фичу на фиг. Уничтожайте ресурсы вручную. В качестве кости мы вам using всунем. Шаблоны вообще в спшке не сделали. Ну да ладно. В конце концов MS в рыночной экономике. Думаю, рынок их впихнет в нужную струю.

A>Скорее Микрософт подпихнет рынок туда, куда нужно

.

Практика покзывает, что успех MS — это и есть плавание по течению.

... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 12.1.0.1028.36665 >>

От:	Курилка	http://kirya.narod.ru/
Дата:	11.03.02 12:21
Оценка:

	От:	Gambler
	Дата:	11.03.02 12:51
	Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	11.03.02 13:06
Оценка:

	От:	Gambler
	Дата:	11.03.02 13:14
	Оценка:	-1

От:	Курилка	http://kirya.narod.ru/
Дата:	11.03.02 13:24
Оценка:

От:	Хитрик Денис	RSDN
Дата:	11.03.02 14:21
Оценка:

От:	Pavel Ivlev	www.vsi.ru/~pavel
Дата:	11.03.02 15:11
Оценка:

От:	IT	linq2db.com
Дата:	11.03.02 15:30
Оценка:	16 (5)

От:	retalik	www.airbandits.com/
Дата:	12.03.02 05:55
Оценка:	5 (2)

От:	VladD2	www.nemerle.org
Дата:	12.03.02 19:52
Оценка:

	От:	Рек
	Дата:	13.03.02 12:11
	Оценка:	34 (6) -1

От:	Kaa	http://blog.meta.ua/users/kaa/
Дата:	13.03.02 18:15
Оценка:	9 (2)

От:	Aquila	http://www.wasm.ru
Дата:	03.11.02 09:33
Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	04.11.02 10:01
Оценка: