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

Здравствуйте 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 тоже не особенно пользовался, но по его шикарной документации учил английский (в рамках необходимого). Там был еще оодин прикол — реализация шаблонов через макросы!

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

От:	VladD2	www.nemerle.org
Дата:	13.03.02 18:00
Оценка:

От:	VladD2	www.nemerle.org
Дата:	13.03.02 18:06
Оценка:

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

От:	VladD2	www.nemerle.org
Дата:	13.03.02 18:34
Оценка:

	От:	The Lex
	Дата:	13.03.02 19:05
	Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	14.03.02 09:50
Оценка:

От:	IT	linq2db.com
Дата:	15.03.02 14:47
Оценка:	4 (1)