Re[8]: Отличие Visual C++ от Builder C++ - Средства разработки

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

K>Здравствуйте Lexus, вы писали:

L>>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>>В книжках по Builder'у пишется, что некоторые вещи практически
L>>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?

K>А я уже лет пять мучаюсь с Visual C++. По сравнению с Дельфи все гораздо сложнее и заковыристей. Это как сравнивать иномарку ( купил — сел и поехал ) и наши тачки ( купил — разобрал — подтянул — починил и может быть поехал ) :-(

Ой, боюсь втянемся опять в "религиозные войны"....

Чисто из своего опыта — вначале мы писали на BCB. Все были довольны — быстро,удобно, просто, куча компонент... А потом, когда понадобилось сделать чтото, чуть более сложнее сем пара диалогов с кнопочками, полезли ошибки. Ошибки билдера. Мы писали в Inprise, они обкещали исправить к след. версии, а мы тем временем писали уйму кода чтоб их обойти.... Один экспорт класса из ДЛЛ чего стоит! (это еще во времена BCB3!). ПроDelphi я ничего не говорю — хорошая вешь. Беда билдера, то что это сишный интерфейс к паскалевскому интерфейсу сишных апи вызовов. Чуете крутизну? :)

Вот. Компилируя программу с packages допускало корректную работу dll, но криво создавалось окно, в dll содеожащееся. и наоборот. Короче, намучались мы основательно, последней каплей было тормозность OpenGL!!!! Ну как это они умудрились???? В общем переписали мы практически все проги гдето за 4 месяца на MFC, и пока все просто чудесно!

Еще прикол, что в 4 билдере не компилировался проект созданый в 3-м. Просто не работал!

Потому мы бросили исследование очередных версий BCB, что в 5-м честно говоря не знаю.

Так вот. Если у меня ктото и спрашивает на чем писать — то в зависимости от уклона — Delpi или MFC. Но никак не BCB.

Саша.

K>>А я уже лет пять мучаюсь с Visual C++. По сравнению с Дельфи все гораздо сложнее и заковыристей. Это как сравнивать иномарку ( купил — сел и поехал ) и наши тачки ( купил — разобрал — подтянул — починил и может быть поехал ) :-(

Насчет иномарок — точно. Зато когда чтото портится (глючит) — где ошибка — у тебя или у них не поймешь... Особенно когда пару раз окажется что действительно у них. Так теряешь веру, и любую ошибку начинаешь валит на них, и естественно, найти ее не получается.....

А тут — все под конролем!

Саша.

L>Кто знает, чем отличается среда Visual C++ от Builder C++.

Вопрос очень... нет, ОЧЕНЬ плохой. На iXBT он тотчас же привел бы к тремстам постингам флэйма. Если Вы действительно хотите понять разницу между некоторыми продуктами, то:
а) Вам это должно быть Оооочень нужно!
б) Вам (лично) нужно освоить оба продукта и не на тестах, а на реальных по возможности больших проектах.

Если Вы понимаете о чем (и главное почему) я это говорю, то можете читать дальше. Далее я дам СВОЕ сугубо субъективное мнение. И оно будет не о среде, а о продуктах в целом. Да собственно и не о продуктах, а о профессионалах, мастерах, ламерах, и прикладниках.

Вы, удивитесь, но если отбросить совсем новичков и совсем крутых гуру, то эти среды отличаются уровнем знаний использующих их программистов. Заранее говорю! СПОРИТЬ Я НИ С КЕМ НЕ БУДУ! Delphi и Builder объединяют вокруг себя большое прикладных программистов и ламеров. Связано это с тем (похоже, реального ответа, думаю, не знает ни кто), что в этих продуктах реализованы две вещи.
1. Мощный визуальный редактор форм.
2. Много готового кода с приемлемым качеством разнесенного по разным классам и компонентам.
Остальные, безусловно полезные, интересные и красивые решения, технологии и подходы являются лишь строительным материалом для вышеперечисленных фич.
Прикладнику которому нужно, например, работать с промышленными СУБД, такое решение может оказаться очень подходящим. Основная логика задачи реализуется легко, а небольшие тонкости, время от времени возникающие на пути, можно решать за счет того, что оба языка являются (как минимум основаны) языками третьего поколения и позволяют осуществлять доступ к всевозможным API. Правда, такая деятельность для них является хакерством (или высшим пилотажем). Про ламеров и говорить ни чего не надо. Они (и начинающие программисты) выбирают эту среду из-за возможностей быстрого старта. Старта и в смысле обучению языку и в смысле легкости создания каркаса программ. Еще одним критерием который приводит выбору этих продуктов является возможность вообще избежать программирования как такового за счет использования готовых компонентов (как входящих в поставку так и посторонних). Скажу сразу ни чего плохого во всем этом нет, кроме того, что очень часто начинающий программист вместо того, чтобы прейти в разряд мастера переходит в разряд ламера, который считает задачу не решаемой если не нашлось готового компонента для ее решения и в ближайшей конфе не помогли.

VC, gcc, g++, Intel C Compiler, и многие другие (заметьте, это не всегда среды) соберают вокруг себя тех кто может думать головой. Боже упаси думать могут и пользователи Borland, но из-за выше перечисленных причин общий процент не велик. Продукты приведенные в списке отличаются тем, что на них почти нельзя работать не углубившись в дебри познания.
Простой пример. В поставку VC входит ПОЛУТОРА ГИГОБАЙТНЫЙ MSDN. Большинство работающих на продуктах Borland даже не знают о его существовании (ну, или ограничиваются этим знанием). А ведь MSDN – это библия Win32 программирования. Далее в VC средства дизайна GUI мягко говоря уступают средствам предоставляемым Delphi или Builder-ом (gcc и g++ — это вообще только компиляторы). Это приводит к тому, что основная часть программы является кодом. Причем Вашим кодом. Т.е. на программиста ложится несравнимо большая нагрузка и от него требуется знать намного больше чем в Builder. Построение таких программ приводит к появлению бОльшего количества кода и рано или поздно встает проблема структурирования кода. Delphi эта проблема стоит не так резко, так как во-первых, она сама помогает структурировать программу, а во-вторых, много кода вообще не надо писать. Собственно это большое преимущество если речь идет о сроке и выполнения проекта. Для прикладника это и является главным факторам. НО!!! Но, с точки зрения обучения – это большая беда! Просто нет такого количества практики, и проблем. Думаю анализ не нужен. Могу сказать только, что, по моей практике, самые луч VB- и Delphi-программисты – это высоко "скильные" C/C++-ники пересаженные на эти продукты.
VC люди выбирают не только из мазохистских побуждений. Бывают области (и как не странно их большинство) где GUI основанное на диалогах не главное. Например, подсчитайте количество диалогов в Word-е. А теперь прикиньте столько там остального кода. Или Q1-Q3 или те же компоненты. Причем в этих программах очень часто становятся критичным скорость выполнения. Для таких программ обычны большие объемы рукописного кода (порядка – 30к-300к строк C++-ного кода, а иногда и больше). И тут на первый, план выходят не RAD-ости, а средства работы с большими объемами кода и средства оптимизации. Вот здесь то VC и g++ выходят на первые роли.
Оговорюсь, что на Delphi можно сделать все тоже самое, что можно сделать на VC, но общая совокупность перевешивает. Например, компилятор Delphi порождает очень не дурственный код когда речь идет о работе со строками и целыми числами. Это – 90% потребностей прикладного программиста, но когда речь заходит о ручной оптимизации, о работе с float, о доступе к неординарным API, то Delphi пасует и сильно. Builder вообще обижен Borland-ом он проигрывает даже своей сестре – Delphi. С VC ему даже бесполезно тягаться. К тому же в VC можно довольно встроить Intel C Compiler который увеличивает разрыв в скорости (на новых процессорах) до заоблачных величин. Конечно можно попытаться это сделать и на Builder-е, но... Вот тут и рождается менталитет.

А что нужно мастеру если его основная задача моделировать задачи и долбить код? Правильно средства моделирования и хороший редактор кода. С средствами моделирования на сегодняшний день дела обстоят очень плохо. Самым серьезным инструментом моделирования для C++ является Роза от Рэйшонал. Откровенно говоря гов-но она полное. Кривая рисовалка, но хоть что-то! И именно, это, что-то, входит с 98 г. в VC. Но, из-за малой пользы на практике... Перейдем к редактору кода. Вот тут VC и Emacs (применяемый обычно совместно с g++) сильно выигрывают. Про Emacs лучше спросить у его поклонников, а про VC расскажу. 1. в VC можно полностью настроить клавиатуру под себя, на схему с раскладкой заменить, а настроить любую кнопку с на любое действие (даже макрос или метод плагина). 2. Сам редактор имеет больше возможностей и более интуитивен. Присутствуют такие функции как автоматическое форматирование отступов, запись и воспроизведение макросов. Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает), но он более чем пригоден, для отладки сложных приложений. И это так уже на протяжении минимум десяти лет. В Delphi приличный отладчик появился в пятой версии, да и то при серьезной работе возникает слишком много проблем и неудобств. Кстати, некоторые навороченные возможностей отладки были реализованы MS, а Borland использует их плоды.
И Delphi и Builder и VC поддерживают расширения. Это приводит к тому, что недостающие части среды можно дополнять модулями скаченными из Internet-а. Для VC можно найти много мощеных расширений и почти все они доступны в исходных кодах. Расширения есть и для сред Borland, но преимущественно для Delphi, и 90% носят фетишистский характер. Например, для VC есть мощнейший опгрэйд для комплит ворда — "Visual Assist". С ним не сравнятся встроенные реализации ни VC 6 ни Builder-а ни даже VC 7.

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

PS

Да, совсем, забыл о профессионалах! :) Профессионал – это человек зарабатывающий себе на пропитание некоторой профессией. Обычно подразумевается, что делает он это не случайно. То есть профессионал может быть и дельфист и сионист и кто угодно кроме ламера. Чего себе и Вам желаю. :)

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

VD>Здравствуйте Lexus:

VD>Вопрос очень... нет, ОЧЕНЬ плохой.

Когда у нас будет избранное? Я хочу поместить этот крик души туда. ;o)

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

VD>>Вопрос очень... нет, ОЧЕНЬ плохой.

IT>Когда у нас будет избранное? Я хочу поместить этот крик души туда. ;o)
это Ты спрашиваешь ?-)

Igor

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

VD>Вопрос очень... нет, ОЧЕНЬ плохой. На iXBT он тотчас же привел бы к

Красота !!! Повесить линк на титульной страничке !! :))

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

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

VD>>Здравствуйте Lexus:

VD>>Вопрос очень... нет, ОЧЕНЬ плохой.

IT>Когда у нас будет избранное? Я хочу поместить этот крик души туда. ;o)

Ну хотя бы в раздел новости... А уж я в пару эх запостю, с разрешения автора :)
У меня приятель один, кстати, бывает провокатором под настроение: в Su.Windows.Prog или еще куда-нибудь пошлет письмо "здравствуйте-я-начинающий-подскажите-что-лучше-Си-или-Паскаль"...
Через полгода, бывало, зайдешь — а страсти все бушуют...

А если серьезно, то COM проложил небольшой мостик в этой бурной реке непримиримых стандартов. Мне лично пофиг, на чем кто-то напишет нужный компонент — пусть работает, как надо!
Успехов,
Виталий.

Потрясающе точно.
Господа администраторы, включите сие творение куда-нибудь, дабы не затерялось со временем.

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

R> А уж я в пару эх запостю, с разрешения автора :)
Да, сколько влезет.

R>А если серьезно, то COM проложил небольшой мостик в этой бурной реке непримиримых стандартов. Мне лично пофиг, на чем кто-то напишет нужный компонент — пусть работает, как надо!

Ну, про COM ято отдельный разговор (см. наши статьи http://www.optim.ru/cs/Topics/TopicCom.asp), а так и мен пофигу, а больше про метаморфозы. Когда лучшее, иногда, бывает врагом хорошего.

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

L>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>В книжках по Builder'у пишется, что некоторые вещи практически
L>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?

Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование. И это есть правильно. Объясняю почему. Когда пишется большой проект на visual c++, возможность множественного наследования провоцирует программистов на его использование. В результате получается много путаницы и трудновоспринимаемый код. Множественным наследованием надо пользоваться очень осторожно, когда это действительно необходимо, хотя я считаю, что его надо избегать. А в остальном visual c++ очень классная вещь, и писать надо на нём и на MFC. И как бы мы его не ругали MFC за его неповоротливость, без него нам было бы ой как трудно.

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

K>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

Вообще-то это запрещено в VCL, а не в самом Buildere. Причем только для классов, порожденных от
TObject.
А язык там всё равно C++, поэтому если кто-то чего-то хочет напуть с множественным наследованием,
то пожалуйста ;)))

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

K>Здравствуйте Lexus, вы писали:

K>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

Ну это напрасно. Например, концепция ATL базируется на шаблонах и множественном наследовании.

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

K>>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

IT>Ну это напрасно. Например, концепция ATL базируется на шаблонах и множественном наследовании.

Гы-гы. И Билдер ATL содержит в своей поставке.

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

R>А если серьезно, то COM проложил небольшой мостик в этой бурной реке непримиримых стандартов. Мне лично пофиг, на чем кто-то напишет нужный компонент — пусть работает, как надо!

Вот только и на этом поприще Borland с MS умудрились найти разногласия. :) Насколько я знаю, COM от VC++ (обычный "чистый") бывает не так легко использовать у Borlanda...

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

K>...Когда пишется большой проект на visual c++, возможность множественного наследования провоцирует программистов на его использование. В результате получается много путаницы и трудновоспринимаемый код. Множественным наследованием надо пользоваться очень осторожно, когда это действительно необходимо, хотя я считаю, что его надо избегать.

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

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

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

TL>Вот странно, да. Я вот вроде как написал пару-другую не слишком маленьких проектов и пока не то чтобы не слишком, а, насколько я помню, вообще не использовал множественного наследования. И не особо жалею по этому поводу. Но использовать его стоит. Вот только проектировать надо тщательно. Впрочем, это относится не только к множественному наследованию...

Я как-то за субботу-воскресенье набросал основные классы небольшого проекта (pure WIN api, console app) — так вышло
что без теплейтов, множественного наследования, и наследования типа C : BT<С> никак ... проекти никак не проектировался — ибо маленький и в общем-то stand alone app ...

Igor

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

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

TL>Вот только и на этом поприще Borland с MS умудрились найти разногласия. :) Насколько я знаю, COM от VC++ (обычный "чистый") бывает не так легко использовать у Borlanda...

Да все там легко... если знаеш все. У билдера и VC есть только одно серьзеное отличие #import в билдере реализован на столько криво, что реально его испльзовать не возможно. Все остольное обходится и залатывается, был бы опыт...

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

IS>Я как-то за субботу-воскресенье набросал основные классы небольшого проекта (pure WIN api, console app) — так вышло
IS>что без теплейтов, множественного наследования, и наследования типа C : BT<С> никак ... проекти никак не проектировался — ибо маленький и в общем-то stand alone app ...

Ну, это уже образ мышления... А насчет множественного и одиночного наследавания, так это же просто разные концепции 1-е подразумевает построение классов путем сбора под одну крышу функциональных частей, 2-е расширение возможностей базового типа данных. Вон вирт вообще без глассов обходится. Да, и теорию АТД еще ни кто не отменял...

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

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

K>>Здравствуйте Lexus, вы писали:

K>>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

IT>Ну это напрасно. Например, концепция ATL базируется на шаблонах и множественном наследовании.

Может быть меня обвинят в консерватизме, но я считаю, что программисты стали заложниками тех. прогресса, и нам по долгу службы приходится изучать всякие глупости типа COM и ATL. Конечно, не спорю, всё эти технологии были созданы с целью облегчения жизни программеру, но за это облегчение надо платить. Я видел много проектов написанных по компонентной технологии, и всё они отличались чрезмерной глючностью и тормознутостью. Ну ладно, чего-то я разошёлся. Боясь породить гневную критику в свой адрес — заканчиваю :)

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

А я уже лет пять мучаюсь с Visual C++. По сравнению с Дельфи все гораздо сложнее и заковыристей. Это как сравнивать иномарку ( купил — сел и поехал ) и наши тачки ( купил — разобрал — подтянул — починил и может быть поехал ) :-(

:)))

Delphi( купил — сел и поехал )... в тщетный попытках найти оный сломаный винтик, программер долго трет кулаками глаза и остается ночевать в машине

C++( купил — разобрал — подтянул — починил и может быть поехал ) :-( — а если не поехал, вставил запчасти задом-наперед и поехал

Вся разница в гибкости.

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

K>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

Там оно запрещено только для Delphi совместимых классов.
Т.е. которые наследуются от TObject. А так все нормально.

В BCB6 и это убрали. Там можно наследовться от TObject
множественно(с ограничениями)

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

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

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

TL>>Вот странно, да. Я вот вроде как написал пару-другую не слишком маленьких проектов и пока не то чтобы не слишком, а, насколько я помню, вообще не использовал множественного наследования. И не особо жалею по этому поводу. Но использовать его стоит. Вот только проектировать надо тщательно. Впрочем, это относится не только к множественному наследованию...

IS>Я как-то за субботу-воскресенье набросал основные классы небольшого проекта (pure WIN api, console app) — так вышло
IS>что без теплейтов, множественного наследования, и наследования типа C : BT<С> никак ... проекти никак не проектировался — ибо маленький и в общем-то stand alone app ...

IS>Igor

А я class'ы использую только для совместимости с чужими библиотеками...
Раньше тоже использова class'ы наследование и т.д. потом отказался и произошло чудо пропали ошибки и скорость работы возросла в 3 раза.

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

WH>А я class'ы использую только для совместимости с чужими библиотеками...
WH>Раньше тоже использова class'ы наследование и т.д. потом отказался и произошло чудо пропали ошибки и скорость работы возросла в 3 раза.
WH>

А как же Вы пишете?

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

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

WH>>А я class'ы использую только для совместимости с чужими библиотеками...
WH>>Раньше тоже использова class'ы наследование и т.д. потом отказался и произошло чудо пропали ошибки и скорость работы возросла в 3 раза.
WH>>

TL>

А как же Вы пишете?
Я ипользую смесь 80% конечных автоматов, 15% процедурного и 5% структурного программирования.
К сожалению я плохо обьясняю поэтому лучше почитайте здесь.

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

K>Здравствуйте Lexus, вы писали:

L>>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>>В книжках по Builder'у пишется, что некоторые вещи практически
L>>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?

K>А я уже лет пять мучаюсь с Visual C++. По сравнению с Дельфи все гораздо сложнее и заковыристей. Это как сравнивать иномарку ( купил — сел и поехал ) и наши тачки ( купил — разобрал — подтянул — починил и может быть поехал )

Уже год мы трахаемся

на BCB 5 (это 9 программистов), и пришли к выводу, что Билдер был создан не для людей. Наш проект на PIV-2400 компилируется более 10 минут. Ужас... Ну это пустяк... Сколько там глюков... Самый досадный, которой не удается ни как победить: LINK_PROC_INTOVER

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

Без поДписи

А>Уже год мы трахаемся

1. А насколько сложен проект? Сколько модулей? У меня BCB прекрасно справляентся с EXE, сосотящим из кучи библиотек и модулей. Насчет скорости компиляции почитайте здесь

2.Ребят, я с успехом использую и на тот, и на этот, правда, все же, BCB чаще.
Так вот. Ежели мне нужно "вайнуть" какой-нибудь сервис, то VC, несомненно, предпочтительней. Но если в программе нужен дружелюбный пользовательский интерфейс — от одной мысли,что придется использовать MFC,

мне становится тоскливо.

Здравствуйте, Аноним, Вы писали:

А>Но если в программе нужен дружелюбный пользовательский интерфейс — от одной мысли,что придется использовать MFC,

мне становится тоскливо.

А сможете ли вы в BCB так просто "вайнуть" дружелюбный пользовательский интерфейс, что-то в стиле а-ля XP, да так что бы на 95 винде работало ?

А>Уже год мы трахаемся

на BCB 5 (это 9 программистов), и пришли к выводу, что Билдер был создан не для людей.

Наш проект мы тоже начинали на 5-ом билдере и пришли к похожему выводу

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

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

AJD>Здравствуйте, Аноним, Вы писали:

AJD>
А>>Но если в программе нужен дружелюбный пользовательский интерфейс — от одной мысли,что придется использовать MFC,

мне становится тоскливо.

AJD>А сможете ли вы в BCB так просто "вайнуть" дружелюбный пользовательский интерфейс, что-то в стиле а-ля XP, да так что бы на 95 винде работало ?

Запросто, вернее точно с таким же успехом, как и в VC — если не с vcl, то WinApi еще никто в BCB не отменял. На крайний случай, для любителей экзотики — там еще поддержка MFC есть... а кому совсем невтерпеж, то можно попробовать WTL воткнуть...

З.Ы. Последнее время я юзаю только VC, поэтому флейм "что круче" раздувать не хочется — у всех свои недостатки и достоинства.

... << RSDN@Home 1.0 beta 6a >>

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

R>Запросто, вернее точно с таким же успехом, как и в VC — если не с vcl, то WinApi еще никто в BCB не отменял. На крайний случай, для любителей экзотики — там еще поддержка MFC есть... а кому совсем невтерпеж, то можно попробовать WTL воткнуть...

Не флейма ради

. Я к тому, что при боле или менее сложной задаче все навороты BCB для быстрого рисования GUI становятся бесполезными (мало полезными) и все придется делать руками

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

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

AJD>
R>>Запросто, вернее точно с таким же успехом, как и в VC — если не с vcl, то WinApi еще никто в BCB не отменял. На крайний случай, для любителей экзотики — там еще поддержка MFC есть... а кому совсем невтерпеж, то можно попробовать WTL воткнуть...

AJD>Не флейма ради

.

А чем же еще? Только ими в перемешку с головой

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

... << RSDN@Home 1.0 beta 6a >>

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

R>А чем же еще? Только ими в перемешку с головой

, это уже не зависит от среды. IMHO — основным достоинством BCB является не легкость создания гуи,
GUI и только!
R>а легкость и скорость применения различных технологий в одной программе —

Вот у меня есть маленькая библиотечка которая выполняет очень много грязной работы...Написана она под VC7 я ее несколько часов под BCB6 переносил...перенес но какой ценой. Этот урод практически не дружит с шаблонами(они там даже до VC7 недотягивают) страшно глючат const...Вобщем функциональность покоцана защиты вобще нет... Ну и кому такая библиотека нужна?

!!!БОРМАН МАЗДАЙ!!!

R>но вот тут все проблемы и начинаются... хотя бы тем что углубляться в применяемую технологию не обязательно, а через некоторе время всплывают глюки о которых ты понятия не имеешь... etc.
Во во только как это начальнику обяснить? Еще не позно пока проектируем.

... << RSDN@Home 1.0 beta 5 >>

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

R>>а легкость и скорость применения различных технологий в одной программе —
WH>

Вот у меня есть маленькая библиотечка которая выполняет очень много грязной работы...Написана она под VC7 я ее несколько часов под BCB6 переносил...перенес но какой ценой.

А ты не пробовал обратоное (из BCB в VC)? Не думаю, что ты потратил бы только несколько часов...

WH>Этот урод практически не дружит с шаблонами(они там даже до VC7 недотягивают) страшно глючат const...Вобщем функциональность покоцана защиты вобще нет... Ну и кому такая библиотека нужна?
На счет шаблонов, что-то странное, у меня особых проблем как раз в BCB с ними небыло. Может хоть покажешь в чем эти проблемы заключались?

WH>

!!!БОРМАН МАЗДАЙ!!!

Разбавлять с IMHO не забывай

... << RSDN@Home 1.0 beta 6a >>

Здравствуйте, Аноним, Вы писали:

А>Уже год мы трахаемся

на BCB 5 (это 9 программистов), и пришли к выводу, что Билдер был создан не для людей.

Ох, золотые слова! У нас к сожалению большинство клиенских приложений пишутся на BCB5, но некоторые счастливчики кое-что иногда пишут на VC (есть проекты, где клиенты поставили условие — только VC). Так всегда можно отследить переход с VC на BCB. Человек вдруг ни с того ни с сего начинает просто материться...

В приципе BCB создавался может быть и для людей, но похоже совсем не тестировался. Какой-то он недоделанный, причем от версии к версии. Сразу видно, что для Борланда это побочный продукт. Про среду разработки я уж вообще молчу. А уж про BDE-линки без мата просто невозможно...
Хотя сама идея очень даже неплохая.

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

R>А ты не пробовал обратоное (из BCB в VC)? Не думаю, что ты потратил бы только несколько часов...
Мне пришлось бы полностью переписовать... Ибо BCB ничерта не умеет, а с икалечеными им библиотеками я в вижуле работать не буду.

R>На счет шаблонов, что-то странное, у меня особых проблем как раз в BCB с ними небыло. Может хоть покажешь в чем эти проблемы заключались?
http://www.rsdn.ru/File/620/Ref.h
Попробуй портируй этот фаил.

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

WH>http://www.rsdn.ru/File/620/Ref.h
WH>Попробуй портируй этот фаил.
Нет там ничего

, кидай на мыло в профайле...

... << RSDN@Home 1.0 beta 6a >>

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

WH>>http://www.rsdn.ru/File/620/Ref.h
WH>>Попробуй портируй этот фаил.
R>Нет там ничего

, кидай на мыло в профайле...
странно, а у меня есть, полный h-ник всяких шаблонов

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

O$>Здравствуйте, rebus, Вы писали:

WH>>>http://www.rsdn.ru/File/620/Ref.h
WH>>>Попробуй портируй этот фаил.
R>>Нет там ничего

, кидай на мыло в профайле...
O$> странно, а у меня есть, полный h-ник всяких шаблонов
Ага, уже появилось...

... << RSDN@Home 1.0 beta 6a >>

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

R>>На счет шаблонов, что-то странное, у меня особых проблем как раз в BCB с ними небыло. Может хоть покажешь в чем эти проблемы заключались?
WH>http://www.rsdn.ru/File/620/Ref.h
WH>Попробуй портируй этот фаил.

У меня сейчас нет BCB под рукой, но я увидел в твоем коде некоторые странности (да простят меня местные гуру, если я глупости начну говорить):

class C_RefWeakBase
{
    friend class T_RefCOMBase;
//...
};

В то время, как T_RefCOMBase — шаблон — что ни есть правильно... при определение как friend должно быть указание что это шаблон, например написать:

class C_RefWeakBase
{
    template<class C> friend class T_RefCOMBase;
//...
};

либо:

class C_RefWeakBase
{
    friend class T_RefCOMBase<void**>;
//...
};

etc...
И так по всему тексту..
Посмотри стандарт, помоему — 14.5.x — x не помню, но название — Friends.

... << RSDN@Home 1.0 beta 6a >>

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

    template<class P_Type>friend class T_RefWeak<P_Type>;

Но это мелочи...там еще куча проблем которые не получается решить...разве что сносом защиты что есть очень плохо.

А как тебе такой перл

    T_RefStrong<I_FactorysContainer>    container;
...
    bool isReady()const {return container!=0;}

говорит не могу выбрать между

    operator const P_Type*()    const{return m_ptr;}
    operator P_Type*()            {return m_ptr;}

А вызов неконстантных функций внутри константных считает варнингом и на том спасибо хорошо что совсем не игнорирует.

... << RSDN@Home 1.0 beta 5 >>

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

WH>Здравствуйте, rebus, Вы писали:
WH>BCB просит так
WH>

WH>    template<class P_Type>friend class T_RefWeak<P_Type>;
WH>

WH>Но это мелочи...

Стандарт — это мелочи???

WH>А как тебе такой перл
WH>

WH>    T_RefStrong<I_FactorysContainer>    container;
WH>...
WH>    bool isReady()const {return container!=0;}
WH>

WH>говорит не могу выбрать между
WH>

WH>    operator const P_Type*()    const{return m_ptr;}
WH>    operator P_Type*()            {return m_ptr;}
WH>

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

WH>А вызов неконстантных функций внутри константных считает варнингом и на том спасибо хорошо что совсем не игнорирует.
Да, это точно, он такое делает

Ворнинги отрубаешь на время и думаешь что все правильно, а потом на тебе

Вот код (кстати тоже константность), на который он тоже ворнингом отругался:

#include <iostream>
class Sample
{
mutable int x;
mutable int y;
public:
    Sample():x(0),y(0){};
    void Add_x();
    void Add_y() const;
};

void Sample::Add_x()
{
    x++;
}
void Sample::Add_y() const
{
    y++;
}

int main(int argc, char* argv[])
{

    const Sample D2;
    Sample D1;
    D1.Add_y();
    D2.Add_x();// <---- Ошибка в VC++ 6,7 и ворнинг в Builder 6
    return 0;
}

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

... << RSDN@Home 1.0 beta 6a >>

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

WH>>

WH>>    template<class P_Type>friend class T_RefWeak<P_Type>;
WH>>

WH>>Но это мелочи...
R>Стандарт — это мелочи???
Нет но в данном случае это скорее расширение со стороны вижула.

WH>>

WH>>    operator const P_Type*()    const{return m_ptr;}
WH>>    operator P_Type*()            {return m_ptr;}
WH>>

R>Правильно говорит — тут ведь неоднозначность на лицо, т.к. возвращаемые типы не участвуют в разрешении неоднозначности, при перегрузке функций и операторов...
Разве? Обрати внимание на const.

R>В реальном коде я догло пытался понять почему не работает в VC, после переноса из Билдера...
Во во а когда переносишь из VC в BCB там тАкое начинается

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

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

WH>>>

WH>>>    template<class P_Type>friend class T_RefWeak<P_Type>;
WH>>>

WH>>>Но это мелочи...
R>>Стандарт — это мелочи???
WH>Нет но в данном случае это скорее расширение со стороны вижула.

— одна из причин сложности переноса приложений... Так что не только билдер во всем виноват

Будим считать ворнинги, вместо ошибок у билдера — тоже его расширением

WH>>>

WH>>>    operator const P_Type*()    const{return m_ptr;}
WH>>>    operator P_Type*()            {return m_ptr;}
WH>>>

WH>Разве? Обрати внимание на const.

Ну вобщем надо смотреть на всесь твой код, чтоб иметь все представление об объектах их их возможностях, а то выводов можно сделать кучу, но только все это неправильно будет

Всеже попробую поразмышлять, как я все понял...

Я тут у Страуструпа посмотрел, так у него написано:

"Константную функцию-член можно вызвать как для константного, так и неконстантного объекта, в то время, как неконстантную функцию-член, можно вызвать только для объекта, не являющегося константой" 10.2.6

Отсюда, можно сделать вывод (беря в расчет твой код), что VC, считает все объекты внутри константной функции (в твое случае —

bool isReady()const;

)- константами (именно по этому в VC сработает константное преобразование), а билдер считает, что внутри фукции объеты имеют тот тип, который имеют, просто функция не может их менять... если так думать, то билдер прав...

З.Ы. Все это может иметь смысл, если для операторов преобразования не существует неких "особых" правил, при разрешении неодназначностей, imho их нет (по крайне мере ничего "особого" я не нашел), и их можно принять как за обычные функции...

"Как правило, лучше не переусердствовать при создании операторов преобразования, При чрезмерном использовании они приводят к неодназначности..."

(с) Б.Страуструп

Здравствуйте, Lexus,
Я борландовские продукты не использую с С++ 3
Судя по уровню понимания работы винды лучше уточнить в такой формулировке:

Кто знает, чем отличается среда Visual Basic от Builder C++.

Общие места — компонентное программирование
Разница Язык

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

L>Кто знает, чем отличается среда Visual C++ от Builder C++.

А что в них общего
L>В книжках по Builder'у пишется, что некоторые вещи практически
L>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?
В билдере 5.0 можно установить библиотеку MFC. Вот с ее помощью и создают GUI приложения в VisualC++. И это действительно долго и муторно, зато производительность при определленных обстаятельствах гораздо выше, и возможностей для разного рода извращений больше. Короче имеем дело с более низкоуровнивым програмированием. А слово Visual в название это рекламный трюк, и ничего общего с другими Visual подобными средствами нету.

А вот Visual C#.Net это совсем другое дело, это дествительно похоже на Дельфи. При создании пользовательского интерфейса отличии не велики (правдо поддержка различнных нововведений Windowsа типа GDI+ появляются у microsoft быстрее, странно почему

). И с доступом к БД или созданием Web приложений VisualC#.Net явно на высоте. Да и среда удобней.

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

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

R>
R>>>а легкость и скорость применения различных технологий в одной программе —
WH>>

Вот у меня есть маленькая библиотечка которая выполняет очень много грязной работы...Написана она под VC7 я ее несколько часов под BCB6 переносил...перенес но какой ценой.

R>А ты не пробовал обратоное (из BCB в VC)? Не думаю, что ты потратил бы только несколько часов...

WH>>Этот урод практически не дружит с шаблонами(они там даже до VC7 недотягивают) страшно глючат const...Вобщем функциональность покоцана защиты вобще нет... Ну и кому такая библиотека нужна?
R>На счет шаблонов, что-то странное, у меня особых проблем как раз в BCB с ними небыло.
Может хоть покажешь в чем эти проблемы заключались?

WH>>

!!!БОРМАН МАЗДАЙ!!!

R>Разбавлять с IMHO не забывай

Обсуждение не имеет смысла... Поскольку, вы когда-нибудь портировали программы на С++ из\в VC++,BC++,gcc,workshop,intel c++? Так вот с ответсвенностью говорю, у них все С++ — РАЗНЫЕ и НЕСОВМЕСТИМЫЕ и ОСНОВАННЫ на РАЗНЫХ ПОДМНОЖЕСТВАХ\НАДМНОЖЕСТВАХ С++. Совершенно коректный и простой код на одном не компилица на другом! Каждый из ни оптимизирован под свои задачи и плохо подходит для других.

Здравствуйте, <Аноним>, Вы писали:

А>Обсуждение не имеет смысла...

Имеет, хотя бы со стороны СТАНДАРТА. А так же, чтобы узнать о граблях компиляторов, чтоб потом на них не наступать...

А>Поскольку, вы когда-нибудь портировали программы на С++ из\в VC++,BC++,gcc,workshop,intel c++?
Будем считать, что это не наезд. Сабж только о первом и втором, могу сказать, что портировал...

А>Так вот с ответсвенностью говорю, у них все С++ — РАЗНЫЕ и НЕСОВМЕСТИМЫЕ и ОСНОВАННЫ на РАЗНЫХ ПОДМНОЖЕСТВАХ\НАДМНОЖЕСТВАХ С++.

С++ не может быть разным, он один! Это говорит только об их недостатках, с точки зрения СТАНДАРТА.
А те "расширения" и "улучшения", которые применяются в компиляторах создают лишь иллюзию преимущества кода написанного с помощью них, над стандартным С++, т.к. трудно переносимы. А раз у Вас есть, как Вы говорите, большой опыт переноса программ на разные компиляторы, то Вы и должны в первую очередь это понимать.

... << RSDN@Home 1.0 beta 6a >>

Здравствуйте, rebus, Вы писали:
]
R>- одна из причин сложности переноса приложений... Так что не только билдер во всем виноват

R>Будим считать ворнинги, вместо ошибок у билдера — тоже его расширением

НЕТ это грубейшая ошибка не позволяющея писать безопасный код.

R>Отсюда, можно сделать вывод (беря в расчет твой код), что VC, считает все объекты внутри константной функции (в твое случае —

bool isReady()const;

)- константами (именно по этому в VC сработает константное преобразование),
Он считает this const'антным со всеми вытекающами.
R>а билдер считает, что внутри фукции объеты имеют тот тип, который имеют, просто функция не может их менять...
И вижул так считает просто this const'антный.
R>если так думать, то билдер прав...

Абсолютно не прав.

R>

R>"Как правило, лучше не переусердствовать при создании операторов преобразования, При чрезмерном использовании они приводят к неодназначности..."

(с) Б.Страуструп
Правильно говорит однако здась это не имеет места.

ЗЫ Я тут доработал свои шаблоны и ввел продержку констант.

    T_RefStrong<I_Object> obj;
    T_RefStrong<const I_Object> cobj;
    cobj=obj//так можно
    obj=cobj//а так нельзя

Под билдером так не сделаешь.

... << RSDN@Home 1.0 beta 5 >>

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

Весь этот флейм чистой воды фидошничество! Говно глючное можно написать как на VC, так и на BCB, да и на VB, Perl, Pascal, Delphi и даже на ассемблере. Да на чем угодно. Вы думаете в MFC глюков нет? Есть! И в VCL они тоже есть. Глюки есть практически в любом софте. А качество софта измеряется не языком программирования, а программистом, который его ваяет. Так что не занимайтель словоблудием. Каждый выбирает то, что ему нравится!

Lexx

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

VD>Здравствуйте Lexus:

VD>Вопрос очень... нет, ОЧЕНЬ плохой. На iXBT он тотчас же привел бы к тремстам постингам флэйма. Если Вы действительно хотите понять разницу между некоторыми продуктами, то:
VD>а) Вам это должно быть Оооочень нужно!
VD>б) Вам (лично) нужно освоить оба продукта и не на тестах, а на реальных по возможности больших проектах.

Настроение такое... Хочется вспомнить историю более чем 10ти-летней давности.
Тогда мы в конторе писали под DOS и, есссесссно, на Turbo C. Потом и ++.
Смог я уговорить контору перелезть на Windows, что далось мне тяжеловато. Само собой, востребовался только Borland. В то время графический GUI для разработки был только у него. MS поставлял консольный.
И тут появляется первый C++ от MS и с ним MFC первой версии.
За пол-дня портирую библиотеку по Borland (не без проблем) и мы реализуем проект на этой смеси.
Но! Раз в недельку я компилил весь проект на MS C. И получал кучу варнингов и ошибок. Настроен-то Borland всегда на легкий уровень... Про производительность кода Borland в то время вообще молчу. Но процесс компиляции у борланда был махом. Это уж точно. Код сыроватый, к культуре программирования продукт нас не ведет. Отношение на всю жизнь сформировалось — УЧЕБНЫЙ ПРОДУКТ.
Говорю только про C++ и сопутствующее. Про дельфина пока молчу. У нас на серваке приложений работает процентов 10 кода на Delphi. Качество отличное, видим только интерфейсы и довольны ими.
А вообще, как заметил один из участвующих в эточ флейме, все зависит от самого программера. На Forhte никто не пишет?

С уважением и пожеланиями успехов.

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

А>>Уже год мы трахаемся

на BCB 5 (это 9 программистов), и пришли к выводу, что Билдер был создан не для людей.

S>Наш проект мы тоже начинали на 5-ом билдере и пришли к похожему выводу

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

Интересный результат, посмотрел сравнительный тест (http://rsdn.ru/article/?devtools/perftest.xml)производительности для математических операций, говорит что скорость исполнения почти одинаковая

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

R>Здравствуйте, <Аноним>, Вы писали:

А>>Обсуждение не имеет смысла...

R>Имеет, хотя бы со стороны СТАНДАРТА. А так же, чтобы узнать о граблях компиляторов, чтоб потом на них не наступать...

А>>Поскольку, вы когда-нибудь портировали программы на С++ из\в VC++,BC++,gcc,workshop,intel c++?
R>Будем считать, что это не наезд. Сабж только о первом и втором, могу сказать, что портировал...

А>>Так вот с ответсвенностью говорю, у них все С++ — РАЗНЫЕ и НЕСОВМЕСТИМЫЕ и ОСНОВАННЫ на РАЗНЫХ ПОДМНОЖЕСТВАХ\НАДМНОЖЕСТВАХ С++.

R>С++ не может быть разным, он один! Это говорит только об их недостатках, с точки зрения СТАНДАРТА.
R>А те "расширения" и "улучшения", которые применяются в компиляторах создают лишь иллюзию преимущества кода написанного с помощью них, над стандартным С++, т.к. трудно переносимы. А раз у Вас есть, как Вы говорите, большой опыт переноса программ на разные компиляторы, то Вы и должны в первую очередь это понимать.

C++ как раз и не один, существует множество стандартов.

Здравствуйте, <Аноним>, Вы писали:

R>>С++ не может быть разным, он один! Это говорит только об их недостатках, с точки зрения СТАНДАРТА.
R>>А те "расширения" и "улучшения", которые применяются в компиляторах создают лишь иллюзию преимущества кода написанного с помощью них, над стандартным С++, т.к. трудно переносимы. А раз у Вас есть, как Вы говорите, большой опыт переноса программ на разные компиляторы, то Вы и должны в первую очередь это понимать.

А>C++ как раз и не один, существует множество стандартов.

Поподробнее, плз. Что-то я не слыхал до сих пор о множестве стандартов C++

... << RSDN@Home 1.1 beta 2 >>

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

grs>Здравствуйте, Аноним, Вы писали:

А>>Уже год мы трахаемся

на BCB 5 (это 9 программистов), и пришли к выводу, что Билдер был создан не для людей.

grs>Ох, золотые слова! У нас к сожалению большинство клиенских приложений пишутся на BCB5, но некоторые счастливчики кое-что иногда пишут на VC (есть проекты, где клиенты поставили условие — только VC). Так всегда можно отследить переход с VC на BCB. Человек вдруг ни с того ни с сего начинает просто материться...

grs>В приципе BCB создавался может быть и для людей, но похоже совсем не тестировался. Какой-то он недоделанный, причем от версии к версии. Сразу видно, что для Борланда это побочный продукт. Про среду разработки я уж вообще молчу. А уж про BDE-линки без мата просто невозможно...
grs>Хотя сама идея очень даже неплохая.

Вот та фраза котрую я ждал...

На самом деле... У билдера неплохая идея!!! но эту идею, разработчики, по-видимому, не смогли реализовать до конца (в плане, без ошибок)... Возможно, это вызвано громоздкостью идеи...

Кто, что думает по этому поводу?

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

O>Вот та фраза котрую я ждал...

O>На самом деле... У билдера неплохая идея!!! но эту идею, разработчики, по-видимому, не смогли реализовать до конца (в плане, без ошибок)... Возможно, это вызвано громоздкостью идеи...

O>Кто, что думает по этому поводу?

Гм, как человек ни разу не видевший билдера, решусь спросить, что же собственно это за идея?

... << RSDN@Home 1.1 beta 1 >>

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

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

O>>Вот та фраза котрую я ждал...

O>>На самом деле... У билдера неплохая идея!!! но эту идею, разработчики, по-видимому, не смогли реализовать до конца (в плане, без ошибок)... Возможно, это вызвано громоздкостью идеи...

O>>Кто, что думает по этому поводу?

ВВ>Гм, как человек ни разу не видевший билдера, решусь спросить, что же собственно это за идея?

в 2х словах: напичкать примочками... и максимально абстрагироваться от их реализации...

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

O>

в 2х словах: напичкать примочками... и максимально абстрагироваться от их реализации...

Мать моя, дык это ж дотнет!

... << RSDN@Home 1.1 beta 1 >>

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

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

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

K>>>Здравствуйте Lexus, вы писали:

K>>>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

IT>>Ну это напрасно. Например, концепция ATL базируется на шаблонах и множественном наследовании.

K>Может быть меня обвинят в консерватизме, но я считаю, что программисты стали заложниками тех. прогресса, и нам по долгу службы приходится изучать всякие глупости типа COM и ATL. Конечно, не спорю, всё эти технологии были созданы с целью облегчения жизни программеру, но за это облегчение надо платить. Я видел много проектов написанных по компонентной технологии, и всё они отличались чрезмерной глючностью и тормознутостью. Ну ладно, чего-то я разошёлся. Боясь породить гневную критику в свой адрес — заканчиваю

А по-моему, заложниками стали те, кто отказался понять сложное и воспользовался готовым

O>>

в 2х словах: напичкать примочками... и максимально абстрагироваться от их реализации...

ВВ>Мать моя, дык это ж дотнет!

Вот в последнем BuilderX-е борланд прямым текстом и говорит:
Хотите писать под win-ду — валите на dotnet. ;-c

... << RSDN@Home 1.1 beta 2 >>

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

L>>А вот Visual C#.Net это совсем другое дело, это дествительно похоже на Дельфи. При L>>создании пользовательского интерфейса отличии не велики (правдо поддержка различнных L>>нововведений Windowsа типа GDI+ появляются у microsoft быстрее, странно L>>почему

). И с доступом к БД или созданием Web приложений VisualC#.Net явно на L>>высоте. Да и среда удобней.

Но тоже не лечена глучности, причем ошибки сохраняются от версии к версии, чего только проблемы с TabPages стоят.

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

VD>Здравствуйте Lexus:

VD>Вопрос очень... нет, ОЧЕНЬ плохой.

Эх, золотые слова, это бы в статью оформить и на сайте вывесить

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

O>Вот та фраза котрую я ждал...

O>На самом деле... У билдера неплохая идея!!! но эту идею, разработчики, по-видимому, не смогли реализовать до конца (в плане, без ошибок)... Возможно, это вызвано громоздкостью идеи...

O>Кто, что думает по этому поводу?

Не могу не согласиться.
Более того: похоже, у Борланда это хроническое — с завидным упорством практически дословно переносить идеи из Паскаля/Delphi в С++ с весьма сомнительным результатом

Вспомните TurboVision или ObjectWindows — C++ кальки с паскалевского кода всегда умудрялись проигрывать в размере и производительности кода, не говоря уже о диковатости pascal-style кода на C++ как такового. OWL в конце концов переписали на чистом C++ (причем, IMHO, по функциональности и "си-плюс-плюсности" OWL5 делала MFC на раз; впрочем, по надежности — увы! — нет), но тут-то как раз вылупился Билдер, и бедняжка пемерла.
Упорство дословного переноса паскалевских библиотек (хотя, ясное дело, в случае с Delphi/BCB все сложнее; скажем так, использование паскалевской идеологии при работе на С++) можно сравнить, наверное, только со стремлением Борланда реализовать многоплатформенные библиотеки/инструментарий: та же OWL для виндов и полуоси, VCL для виндов и линухов...
К сожалению, у меня также сложилось мнение о Борланде, как о поставщике весьма не плохих идей и весьма же ненадежных решений

Кто знает, будут ли новые версии Borland C++ Builder?

Здравствуйте, <Аноним>, Вы писали:

А>Кто знает, будут ли новые версии Borland C++ Builder?
Вроде будет. Вроде даже front end от EDG но мне кажется это им не поможет. У них back end хреновый ни оптимизировать толком не умеет ни даже банально без ошибок код сгенерить.
Вобщем репутация у этой конторы очень "подмоченая".
Если хотите компилятор с front end от EDG и качественным back end то вам прямая дорого за Интеловским компилятором. Хотя и VC++7.1 тоже очень хорошь.

... << RSDN@Home 1.1.3 beta 1 >>

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

WH>Если хотите компилятор с front end от EDG и качественным back end то вам прямая дорого за Интеловским компилятором. Хотя и VC++7.1 тоже очень хорошь.

Слышал слули что "буржуи" нашим землякам этот компилер не продают.
Правда иль вымысел?
Читал на www.wasm.ru,
там из-за этого, даже на примере интеловского компилера проги ломать учат.

... << RSDN@Home 1.1.3 stable >>

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

L>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>В книжках по Builder'у пишется, что некоторые вещи практически
L>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?
Мое мнение:
Ув. тов. Vlad2 и Ocelot во многом правы. Но с некоторыми моментами я не согласен. RAD позиционировались изначально как средства быстрого создания приложений. Быстрого создания программ, а не создания быстрых программ. И в области создания мелких (по целям, по размерам они отнюдь не мелкие) программ RAD'ы на высоте. Рекомендую создать окно на чистом АПИ и в Билдере любому начинающему для проверки.
Про оптимизацию хорошо сказал Зубков и есть неплохие статьи К.Касперски. Если человек знает, как работает оптимизирующий С-компилятор, он будет писать код, который отлично оптимизируется конкретным компилятором — раз, и 90% оптимизации достигается на уровне оптимизации алгоритма. Кому надо оставшиеся 10% — милости просим, асм нам всем поможет.
Доводы про компиляторы и скорость немного мимо, хотя это верные доводы. Вот почему: любая приличная среда разработки создает свои обертки вокруг относительно низкоуровневых АПИ. ЧТобы каждый раз не изобретать велосипед. Пример (несколько неудачный): VS обладает MFC и WTL, Борланд — VCL. Тк что разговор идет о наборе готовых решений (библиотек классов, etc.), поставляемых с конкретной средой. Получается, что мы сравниваем немного разные компиляторы: кроме стандарта ANSI борладновский компилятор еще кучу всего делает, чего компилятору от VC делать в жизни не придется.
Если говорить о редакторе кода и компиляторе, то возможно пользоваться другими редакторами и компиляторами и для Борланда. Правда, исчезнет сам смысл использования — пользоваться VCL будет достаточно затруднительно и пропадет средство визуального редактирования форм. Тут очень правильно сказали про "менталитет" — emacs+makefile затачивается под любой компилятор, но только кто из адептов данного пути возьмет компилятор от Билдера? Уж лучше тогда free command-line tools.
И в заключение — инструменты дома есть? Я надеюсь, в наборе не единственная отвертка и не единственный гаечный ключ.

d Nishat Khan, Irshad Khan & Sha — Rag Bhimpalasi d

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

G> Про оптимизацию хорошо сказал Зубков и есть неплохие статьи К.Касперски. Если человек знает, как работает оптимизирующий С-компилятор, он будет писать код, который отлично оптимизируется конкретным компилятором — раз, и 90% оптимизации достигается на уровне оптимизации алгоритма. Кому надо оставшиеся 10% — милости просим, асм нам всем поможет.
Вот тут я не совсем согласен. Алгоритмические оптимизации это конешно основное. НО качество оптимизации С++ компилятора очень сильно влияет на производительность. Порой в разы.
А на счет асма то я не знаю людей которые могут писать на асме лучше чем генерирует код ителовский компилятор.

... << RSDN@Home 1.1.3 beta 1 >>

d Ravi Shankar — Mahaa Mrityunjaya d

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

L>>Кто знает, чем отличается среда Visual C++ от Builder C++.

VD>VC, gcc, g++, Intel C Compiler, и многие другие (заметьте, это не всегда среды) соберают вокруг себя тех кто может думать головой. Боже упаси думать могут и пользователи Borland, но из-за выше перечисленных причин общий процент не велик. Продукты приведенные в списке отличаются тем, что на них почти нельзя работать не углубившись в дебри познания.

для тех кто используют far + bcc32 ( cl,.. etc ) вопрос что использовать borland или visual не стоит ))O-)

VD>Простой пример. В поставку VC входит ПОЛУТОРА ГИГОБАЙТНЫЙ MSDN. Большинство работающих на продуктах Borland даже не знают о его существовании (ну, или ограничиваются этим знанием). А ведь MSDN – это библия Win32 программирования.

лично я msdn пользуюсь крайне редко и ест-сно не ставлю всю эту прорву на диск — мало того что место занимает
так VS по ней искать пытается — на П4 с 1Гб случайное нажатие F1 подвешивает работу секунд на 30.. а я всего лишь
какой нить puts искал ( например ). гораздо лучше ( имхо!!!)) борландовский hlp — и меньше ( я беру только 2 файла
про C-Runtime library и STL ) и быстрее.) а F1 пришлось в студии вообще дизейблить). а когда очень надо то
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_vclang_home.asp — благо у всех постоянный и быстрый онлайн стал нормой. всем очень рекомендую ) а полтора гига лучше хорошей музыкой занять )

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

VD>Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает
Какая-то несуразица.
1. Либо я не научился в делфи стек вызовов смотреть либо все же там нельзя это сделать. Хотя я вобщем-то на 6 пробовал. То что там есть — это скудный вариант.
2. А какже Edit@Сontinue???
3. А кастомизация отображений

На мой взгляд не стоило сравнивать дебагеры. У каждого есть и преимущества и недостатки. Я програмиирую на делфи и на vc и нахожу дебагер vc более мощным. Но это мое имхо и не для развития флейма эта фраза.

А в остальном — достойно публикации.

Здравствуйте, Аноним, Вы писали:

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

А>Весь этот флейм чистой воды фидошничество! Говно глючное можно написать как на VC, так и на BCB, да и на VB, Perl, Pascal, Delphi и даже на ассемблере. Да на чем угодно. Вы думаете в MFC глюков нет? Есть! И в VCL они тоже есть. Глюки есть практически в любом софте. А качество софта измеряется не языком программирования, а программистом, который его ваяет. Так что не занимайтель словоблудием. Каждый выбирает то, что ему нравится!

А>Lexx

"А качество софта измеряется не языком программирования". Не всегда. Что касается delphi, vc++ и т.д. — тут понятно.
НО!!! Вы работали на CA Visual Objects 2.5. Вещь не рабочая по своему определению. Там многие синтаксические ошибки компилируются даже без ворнингов. Потом ручная компиляция и отладка такого проекта — одна сказка. Более того, там неудачный GC. Передал указатель в функцию- начинаешь его использовать — а там ничего нет — пямать дефрагментировалась. А вся библиотека оконных классов реализована с использованием фиксатора указателей (чтобы не дефграгментировался этот участок памти) а при вызове более 300 этого фиксатора программа уходит.

Ну вобщем я хочу сказать что не все языки программирования относятся к утверждению "А качество софта измеряется не языком программирования".

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

WH>Вот тут я не совсем согласен. Алгоритмические оптимизации это конешно основное. НО качество оптимизации С++ компилятора очень сильно влияет на производительность. Порой в разы.
WH>А на счет асма то я не знаю людей которые могут писать на асме лучше чем генерирует код ителовский компилятор.
Смотря на каком процессоре и памяти. Конечно если ходить по двойной ссылке это скажется (но на огромных вычислениях) при условии что все данные попадают в кэш. Если смотреть на Delphi то там компилятор далек от совершенства, но например разница большая на Целерон 500 и Athlon ХР 2400+ . Если на первом Delphi может проигрывать нетовскому JIT то на втором выигрывает. А все дело в том что скорость к кэш памяти на уровне доступа к регистрам.

... << RSDN@Home 1.1.0 stable >>

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

И охота Вам было поднимать эту пыльную, покрытую паутиной, ветку?

В "Священные войны" ее и куда-нибудь поглубже

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

TL>>

А как же Вы пишете?
WH>Я ипользую смесь 80% конечных автоматов, 15% процедурного и 5% структурного программирования.
WH>К сожалению я плохо обьясняю поэтому лучше почитайте здесь.

80% многовато, я думаю реально чуть меньше

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

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

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

Ветка о выборе лучшего кандидата из перегруженных операций преобразования перенесена в "C++".
--
ПК

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

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

VD>>Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает
AE>Какая-то несуразица.
AE>1. Либо я не научился в делфи стек вызовов смотреть либо все же там нельзя это сделать. Хотя я вобщем-то на 6 пробовал. То что там есть — это скудный вариант.

Не научился. Интерфейс в Дельфи специфический, но пользоваться очень даже можно.

AE>2. А какже Edit@Сontinue???

Кстати, на атл-ых проектах если его не отключить, то легче повеситься.

AE>3. А кастомизация отображений

Отображений чего?

AE>На мой взгляд не стоило сравнивать дебагеры.

Хорошо, что есть разные мнения.

... << RSDN@Home 1.1.4 beta 2 >>

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

V>80% многовато, я думаю реально чуть меньше

Я рекомендую посмотреть на дату этого поста... 02.07.2002.
Я тогда был еще маленьким

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

... << RSDN@Home 1.1.3 beta 1 >>

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

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

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

VD>>>Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает
AE>>Какая-то несуразица.
AE>>1. Либо я не научился в делфи стек вызовов смотреть либо все же там нельзя это сделать. Хотя я вобщем-то на 6 пробовал. То что там есть — это скудный вариант.

VD>Не научился. Интерфейс в Дельфи специфический, но пользоваться очень даже можно.

Ну тогда пользуясь случаем — хочу.
1. Научиться отображать полный стек вызовов а не то что показывает Делфи
2. Научится отображать хоть что-то в этом стэке после получения исключения

AE>>2. А какже Edit@Сontinue???

VD>

Кстати, на атл-ых проектах если его не отключить, то легче повеситься.

Не знаю, не вешался.

AE>>3. А кастомизация отображений

VD>Отображений чего?

Ну есть такое окошко Watch. И есть в нем понятие отображения переменных, структур и т.д. Ну так вот. В с++ можно настраивать как отображение самой переменной Типа hRes, hr при этом будет показано не число а название ошибки, так и самих структур на уровне какого-то файла. правда дальше чем чтения описания я в этом плане не доходил. Но фича есть!!!

AE>>На мой взгляд не стоило сравнивать дебагеры.

VD>Хорошо, что есть разные мнения.

Не стоило, потому что может пойти дикий флейм (правда я сам его начал).

Но я не хотел

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

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

VD>>Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает
AE>Какая-то несуразица.

Согласен.
Очень "удобно" пользоваться отладчиком в Делфи для просмотра структур с подструктурами и списов (типа TList). Вариант, типа ((0,34,5),25,6,34,((), 245,213,5),53) очень информативен.
Еще замечательно "переключаться" между потоками.

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

VD>>Простой пример. В поставку VC входит ПОЛУТОРА ГИГОБАЙТНЫЙ MSDN. Большинство работающих на продуктах Borland даже не знают о его существовании (ну, или ограничиваются этим знанием). А ведь MSDN – это библия Win32 программирования.

TC>какой нить puts искал ( например ). гораздо лучше ( имхо!!!)) борландовский hlp — и меньше ( я беру только 2 файла
TC>про C-Runtime library и STL )

в огороде бузина, а в Киеве дядька

см. выделенное

Это у меня одного сообщения за прошлые годы падают? Причём стабильно. Может прибить эту ветку

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

AE>1. Научиться отображать полный стек вызовов а не то что показывает Делфи
AE>2. Научится отображать хоть что-то в этом стэке после получения исключения

Ну, это не на этот форум. Вроде как народ получает.

VD>>

Кстати, на атл-ых проектах если его не отключить, то легче повеситься.

AE>Не знаю, не вешался.

Значит больших проектов не делал. У нас воркспэйс компилировался 25 минут в обычном режиме. Дождаться джаст-ин-тайм копиляции было просто невозможно.

AE>>>3. А кастомизация отображений

VD>>Отображений чего?

AE>Ну есть такое окошко Watch. И есть в нем понятие отображения переменных, структур и т.д. Ну так вот. В с++ можно настраивать как отображение самой переменной Типа hRes, hr при этом будет показано не число а название ошибки, так и самих структур на уровне какого-то файла. правда дальше чем чтения описания я в этом плане не доходил. Но фича есть!!!

В новой студии все в 100 раз круче, правда для менеджед-кода. В дельфе с этим вроде было плохо. Но по умолчанию они показывали все поля и у них были специальные окна. В общем, своеобразно но жить можно.

AE>Не стоило, потому что может пойти дикий флейм (правда я сам его начал).

Но я не хотел

Ну, на это есть модераторы.

... << RSDN@Home 1.1.4 beta 2 >>

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

RSV>Интересный результат, посмотрел сравнительный тест (http://rsdn.ru/article/?devtools/perftest.xml)производительности для математических операций, говорит что скорость исполнения почти одинаковая

.

Все дело в синтетических тестах! В качестве альтернативы могу привести работу ГУИшными функциями — в MFC это заврапенные (в большинстве случаев) вызовы АПИ функций, а в делфе (билдере) это глубоко запрятанные за виртуальными функциями и несколькими классами работа с АПИ. Соответственно при прочих равных получаем более медленную работу с интерфейсом в билдере и делфи.

Более того. Если брать за основу те методы управления окнами что находятся в стандартныхз ГУИ-библиотеках этих языков то, например, на MFC изменение размеров/положения окна производится существенно быстрее поскольку выполняется вызов АПИ функции SetWindowPOS или MoveWinwow (точно не помню). на VCL имеем свойства Width, Height и т.д. при изменении каждого из которых имеем +1 вызов вышеописанной функции. Но это еще не все. Можно было бы и ручками делать SetWindowPos но Handle в VCL -это нечто весьма интересное. Желающие могут посмотеть что именно это за свойство. Я раньше думал что это

private
 FHandle: Cardinal;
public
 property Handle: Cardinal read FHandle;

на самом же деле имеем:

public
    property Handle: HWnd read GetHandle;
...
function TWinControl.GetHandle: HWnd;
begin
  HandleNeeded;
  Result := FHandle;
end;
...
procedure TWinControl.HandleNeeded;
begin
  if FHandle = 0 then
  begin
    if Parent <> nil then Parent.HandleNeeded;
    CreateHandle;
  end;
end;
...
procedure TWinControl.CreateHandle;
var
  I: Integer;
begin
  if FHandle = 0 then
  begin
    CreateWnd;
    SetProp(FHandle, MakeIntAtom(ControlAtom), THandle(Self));
    SetProp(FHandle, MakeIntAtom(WindowAtom), THandle(Self));
    if Parent <> nil then
      SetWindowPos(FHandle, Parent.PrecedingWindow(Self), 0, 0, 0, 0,
        SWP_NOMOVE + SWP_NOSIZE + SWP_NOACTIVATE);
    for I := 0 to ControlCount - 1 do
      Controls[I].UpdateAnchorRules;
  end;
end;

И так все!!! В результате простую работу с ГУИ в ущерб скорости! Тут кому как нравится. А меня в последнее время все больше WTL привлекает (когда API не пользуюсь).

А>Уже год мы трахаемся

на BCB 5 (это 9 программистов), и пришли к выводу, что Билдер был создан не для людей. Наш проект на PIV-2400 компилируется более 10 минут. Ужас...

всего-то ? у меня был 40 минут компилился.
А в чем проблема ? на VC компилится не на сильно быстрее.

--Среда отказывается линковать проект, иногда уходит до нескольких часов, для того чтобы просто собрать проект

не стесняйтесь использовать модульное программирование

VD>Простой пример. В поставку VC входит ПОЛУТОРА ГИГОБАЙТНЫЙ MSDN. Большинство работающих на продуктах Borland даже не

учитывая что 99% MSDN содержит просто мусор, оставшийся 1% и лежит у Билдера в хелпе.

--в VC средства дизайна GUI мягко говоря уступают средствам предоставляемым Delphi или Builder-ом (gcc и g++ — это вообще только компиляторы).

чеснто говоря за 10 программирования на ББ даже всеми его средствами не смог воспользоваться

VD>VC люди выбирают не только из мазохистских побуждений. Бывают области (и как не странно их большинство) где GUI основанное на диалогах не главное. Например, подсчитайте количество диалогов в Word-е. А теперь прикиньте столько там остального кода. Или Q1-Q3 или те же компоненты. Причем в этих программах очень часто становятся критичным скорость

судя по скорости работы этого продукта я сильно сомневаюсь что о ней (скорости) думали

--Для таких программ обычны большие объемы рукописного кода (порядка – 30к-300к строк C++-ного кода, а иногда и больше). И тут на первый, план выходят не RAD-ости, а средства работы с большими объемами кода и средства оптимизации. Вот здесь то VC и g++ выходят на первые роли.

300 К ? да вы смеетесь. это размер ноупада. У нас на ББ прoекты содержат по нескольку десятков мегобайт кода.

http://www.flowpath.com/software/software_main.htm

Modlow > 40 мег
UnSat Suite Plus ~8
HydroGeo Analyst > 10

VD>А что нужно мастеру если его основная задача моделировать задачи и долбить код? Правильно средства моделирования и пятой версии, да и то при серьезной работе возникает слишком много проблем и неудобств. Кстати, некоторые навороченные
возможностей отладки были реализованы MS, а Borland использует их плоды.

что -то я не помню чтобы Борлан пожинал какие-то плоды от МС. Отладчик по жизни был лучше. Наиная от Турбодебагера и выше. А то чем хвалится сейчас МС VS2005 с дотнет — функционально было реализовано 10 лет назад у Борланда

откровенно говоря скучная статья .

	От:	Lexus
	Дата:	31.07.01 12:11
	Оценка:

	От:	Koumandin
	Дата:	31.07.01 18:31
	Оценка:

	От:	Sasparella
	Дата:	31.07.01 18:54
	Оценка:

	От:	Sasparella
	Дата:	31.07.01 18:57
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	31.07.01 19:41
Оценка:	439 (60) +7 -6
#Имя:	FAQ.tools.cbvsvc

От:	retalik	www.airbandits.com/
Дата:	01.08.01 10:20
Оценка:

От:	Whirlwind	http://whirlwind.ru
Дата:	07.08.01 05:51
Оценка:

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	11.05.02 12:26
Оценка:

	От:	Аноним
	Дата:	06.03.03 14:06
	Оценка:	1 (1) +3

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	13.03.03 13:08
Оценка:

От:	CrystaX	https://crystax.me/
Дата:	19.10.03 00:19
Оценка:

	От:	Воронков Василий
	Дата:	27.10.03 21:42
	Оценка:

От:	tonal	www@promsoft.ru
Дата:	02.11.03 16:31
Оценка:

От:	TheCat	abokov.livejournal.com
Дата:	01.07.04 12:17
Оценка:	-1

От:	AlexEagle	http://www.vik.oil
Дата:	01.07.04 12:55
Оценка:

	От:	kaziboba
	Дата:	03.08.01 07:21
	Оценка:

	От:	Vodka
	Дата:	03.08.01 08:13
	Оценка:

От:	IT	linq2db.com
Дата:	03.08.01 13:45
Оценка:

	От:	kaziboba
	Дата:	06.08.01 07:23
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	01.07.04 15:06
Оценка:

	От:	Павел Кузнецов
	Дата:	01.07.04 18:36
	Оценка:

От:	Lepsik	figvam.ca
Дата:	23.07.05 22:05
Оценка: