информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetПортрет посетителяSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / miscellaneous
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
согласен 15.07.04 20:57  Число просмотров: 1665
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
> Да и проги
> на Билдере без дополнительных бибилиотек не работают.
Но как же можно говорить что лучше даже не зная как включить в билдере статическую линковку библиотек?
> Вообще, если выбирать продукты от Борланд, то лучше
> использовать Дельфу, т.к. Билдер - это та же Дельфа, но с
> синтаксисом С++.
Не люблю паскаль. Не годится он для больших проектов. Громоздкий очень.
>Как написали в одном журнале: "Borland C++
> Builder - это помесь бльдога с пылесосом".
No comments. Кстати в билдере можно писать как на паскале так и на С++. Те паскалевские юниты он комплит на ура (не путать с компонентами, именно просто в одном проекте могут мирно сосущетсвовать модули на паскале и С, ничего не напоминает? А ведь билдер постарше framework'а от МС будет...)
<miscellaneous>
[C++] Borland Builder or Visual C кто, что использует? Аргументируйте почему 09.07.04 20:55   [amirul, HandleX, Ktirf, Killer{R}]
Автор: choor Статус: Elderman
Отредактировано 09.07.04 20:56  Количество правок: 1
<"чистая" ссылка>
[c++] visual c++ рулит !!! 15.07.04 17:07  
Автор: Ilich Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Мне в моей профессиональной деятельности приходилось сталкиваться как с написанием прог на Borland C++ Builder, так и на Visual C++. Последний релиз Visual C++ просто супер. Мало того, что компилятор довольно быстрый и прекрасно оптимизирует код, это еще и очень универсальное средство разработки. Под него есть много CASE средств. Да и библиотеки сторонних производителей пишутся именно под это средство, и отлько потом (может быть) портируются под Билдер. ЛИчно для меня Visual Studio 2003 + Rational XDE for .NET наиболее оптимальный вариант. А если делать интерфей (точнее не делать, а рисовать), то можно заюзать Windows Forms. ПО-моему, нет никакой разницу между этом средством и Билдером. Разве что при использовании Windows Forms приходится устанавливать Micrisift .NET. Да и проги на Билдере без дополнительных бибилиотек не работают. Вообще, если выбирать продукты от Борланд, то лучше использовать Дельфу, т.к. Билдер - это та же Дельфа, но с синтаксисом С++. Как написали в одном журнале: "Borland C++ Builder - это помесь бльдога с пылесосом".
согласен 15.07.04 20:57  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
> Да и проги
> на Билдере без дополнительных бибилиотек не работают.
Но как же можно говорить что лучше даже не зная как включить в билдере статическую линковку библиотек?
> Вообще, если выбирать продукты от Борланд, то лучше
> использовать Дельфу, т.к. Билдер - это та же Дельфа, но с
> синтаксисом С++.
Не люблю паскаль. Не годится он для больших проектов. Громоздкий очень.
>Как написали в одном журнале: "Borland C++
> Builder - это помесь бльдога с пылесосом".
No comments. Кстати в билдере можно писать как на паскале так и на С++. Те паскалевские юниты он комплит на ура (не путать с компонентами, именно просто в одном проекте могут мирно сосущетсвовать модули на паскале и С, ничего не напоминает? А ведь билдер постарше framework'а от МС будет...)
Терперть не могу статические библиотеки !!! 18.07.04 10:42  
Автор: Ilich Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я никогда не пользуюсь статическими библиотеками, т.к. они увеличивают размер файла. В моем случае имелось ввиду то, что dll-ка для MFC есть практически в любой Винде (про 95 не знаю), а Борландовые библиотечки в поставку не входят. Для создания интерфейса mfc хватает. Хотя сейчас начал использовать FLTK и QT, т.к. приходитися писать кроссплатформенные решения.
Терпеть не могу динамические библиотеки !!! 18.07.04 12:55  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Во-первых: создавать проги, требующие для своей работы несколько файлов и устарнавливаемые только с помощью инсталлятора - крайне дурной тон. (Я даже БД ухитрился создать, которая хранит данные в теле EXE-шника и переносится с места-на-место со всем содержимым его копированием)

Во-вторых: обобществлять надо только те функции и ресурсы, которые могут понадобиться другим, при этом, необходимо публиковать их описания. Такие ДЛЛ-ки должны становиться "официальными компанентами системы" и, в дальнейшем, распространяться с ней вместе.
Знаешь, я бы на тебя посмотрел, как бы ты в один экзешник... 18.07.04 21:17  
Автор: Ilich Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Знаешь, я бы на тебя посмотрел, как бы ты в один экзешник засунул мощную систему документооборота, которая поставлялась на целой болванки (моя разработка для одной конторы). Состема включает в себя специально написанный ля этого дела Application Server, на базе которого строится вся остальная система. Для небольших проектов может и удобно использовать статические библиотеки, но в моем случае это не возможно. А так уж получилось, что я загнимаюсь разработкой только крупных проектов.
Ой. А какие виды workflow в твоей системе есть и позволяет... 19.07.04 08:00  
Автор: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка>
> Знаешь, я бы на тебя посмотрел, как бы ты в один экзешник
> засунул мощную систему документооборота, которая
> поставлялась на целой болванки (моя разработка для одной
> конторы). Состема включает в себя специально написанный ля
Ой. А какие виды workflow в твоей системе есть и позволяет ли она создавать свои?
Мой маленький Application Server на динамических библиотеках ... ;-) 19.07.04 17:10  
Автор: Ilich Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Система настраивается практически под любые нужды корпоративных пользователей, т.е. на базе нее можно вести бухгалтерский учет, складской учет, учет материалных ценностей и т.п. Есть собственная система электронной почты (SMTP, POP3 и IMAP серверы), система экстренного оповещения пользователей (отправка сообщений по электронной почте, а так же на пейджер или мобильный телефон). Есть собственный web-сервер, который позволяет удаленный пользователям подключаться к серверу и получать доступ к своим программам и настройкам (т.е. вести бух. учет и т.п.). Система имеет свой скриптовый язык, который позволяет писать приложения практически под любые нужды. Сервер написан на базе CORBA, поддерживает SSL для обеспечения безопасности. Сервер кроссплатформенный, поэтрому может работать как на базе ВИнды, так и под Юниксом.

З.Ы. Я бы посмотрел, как ты все эти функции засунул бы в один экзешник. Хороший бы у экзешника был размер. ;-) Особенно если CORB'у в экзешник пихать. ;-) По-моему, это вообще маньячество.
Понятно, т.е. что такое workflow ты не знаешь. Посмотри на... 20.07.04 07:48  
Автор: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка>
> Система настраивается практически под любые нужды
> корпоративных пользователей, т.е. на базе нее можно вести
> бухгалтерский учет, складской учет, учет материалных
> ценностей и т.п. Есть собственная система электронной почты
> (SMTP, POP3 и IMAP серверы), система экстренного оповещения
Понятно, т.е. что такое workflow ты не знаешь. Посмотри на www.documentum.ru

> З.Ы. Я бы посмотрел, как ты все эти функции засунул бы в
> один экзешник. Хороший бы у экзешника был размер. ;-)
> Особенно если CORB'у в экзешник пихать. ;-) По-моему, это
> вообще маньячество.
Я никуда ничего не собирался засовывать, мне как бы вообще ортогонален спор про динамические библиотеки, ибо лично я в каждом конкретном случае принимаю решение, как лучше сделать. Иногда - с динамическими библиотеками и внешними базами данных, иногда - полный статик, лучше с dietlibc, дабы поменьше зависеть от системы, в особо запущенных случаях - вообще автономный исполняемый код, не использующий системные вызовы, только BIOS calls.
А маньячеством считаю упираться только в один подход независимо от ситуации...
CORB'у в экзешник пихать?! Да на фиг она вообще нужна?! 20.07.04 04:55  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Если мне надо будет организовать связь между процессами/хостами, я свой интерфейс придумаю, на основе Named Pipe & Mailsliot, где функции будут вызываться по номерам. Тройное преимущество: примитивная, но секретность - номера ф-ций и аргументы известны только серверу и клиенту и нигде не документированы; скорость (команды минимальной длины, не нужен интерпретатор и контроль); Безопасность - потенциально-опасных функций (стереть, заменить) в интерфейсе можно, просто, не делать.

CORBA, OLE, SQL нужны только в том случае, если надо взаимодействовать с софтом сторонних разработчиков.
Вообще это отдельный вопрос, но если кратко, то я не согласен. 20.07.04 13:03  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
На прошлой работе как раз использовались именованные каналы и RPC для передачи данных. На новой - CORBA. Проблем с транспортом неизмеримо меньше. Кстати, уже после того, как я ушел со старого места, на нем все это безобразие переписали под COM. Неожиданно выяснилось, что COM работает быстрее, даже при передаче между машинами.
Ничего, ничего, мы и CORB'у пихали статически на солярке, потому что динамическое связывание не пахало... 19.07.04 17:59  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 19.07.04 18:00  Количество правок: 1
<"чистая" ссылка>
Толстые бинарники получались, ну так хоть работали...
:)
Статическая corba - полное д... 19.07.04 23:13  
Автор: Ilich Статус: Незарегистрированный пользователь
<"чистая" ссылка>
>Ничего, ничего, мы и CORB'у пихали статически на солярке, потому что динамическое связывание не >пахало...
> Толстые бинарники получались, ну так хоть работали...
> :)

Под соляру мое решение тоже подходит. Все ОК. Ребят, если уж динамические библиотеки не компилялись - это ваши проблемы - неужели нельзя make-файлы подправить, исходнички подчистить. Если руки растут из того места, откуда положено, то проблем быть не должно. А статическая CORBA - ПОЛНЫЙ ОТСТОЙ, ОХЕРЕНЫЕ ИСХОДНИКИ И Т.П. ЛАБУДЕНЬ. Короче, не знаю как вы, а я уж лучши dll-ки, so-шки или че нить в этом духе сделаю.

З.Ы. Если уж и юзать статику, то только тогда, когда библиотечка небольшая и это не скажитсмя отрицательно наразмере програмы.

З.Ы. 2 Вы бы еще MS Windows codename "Longhorn" в один файл запихали, или Fedora Core 2 со всеми прпиложениями (всего 4 болванки). Вот бы рулез получился - охрененная операционка в одном файле ;-))))
Да не, сейчас у нас уже все в порядке :) 20.07.04 00:32  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 20.07.04 00:33  Количество правок: 1
<"чистая" ссылка>
Это на старых солярках со старыми компиляторами, ну и без кривых рук не обошлось, конечно...

> З.Ы. Если уж и юзать статику, то только тогда, когда
> библиотечка небольшая и это не скажитсмя отрицательно
> наразмере програмы.
Статику, имхо, нужно использовать в следующих случаях: во-первых, когда ты уверен в том, что твоя библиотека используется ровно в одном месте (встает вопрос о том, нужно ли ее использовать как библиотеку), во-вторых, когда «ад динамических библиотек» заедает (а это не такое уж редкое явление - ту же Оперу я все время со статической Qt беру как раз из-за проблем совместимости с имеющейся библиотекой), и в-третьих - когда издержки становятся критичными (касается всевозможных rescue-дисков и использования в пылесосах, но также касается и и маленьких библиотек, как уже замечено).
>
> З.Ы. 2 Вы бы еще MS Windows codename "Longhorn" в один файл
> запихали, или Fedora Core 2 со всеми прпиложениями (всего 4
> болванки). Вот бы рулез получился - охрененная операционка
> в одном файле ;-))))
Шутки шутками, а busybox не от хорошей жизни был придуман.
Ты бы еще Мастдай в олин файл запихать предложил... 19.07.04 03:31  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
В любом случае, если база локальная, то лучше хранить данные в одном файле, а если клиент-сервер, то для клиентов лучше использовать Жаба-апплеты: зашел браузером, залогинился и получил гарантированно "свой" обновленный и настроенный клиент.
Мальчики, не ссорьтесь. 18.07.04 21:22  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Я вам могу тучу примеров накидать, в которых тот или иной способ связывания затыкает за хвост соперника. Истина, наверное, где-то посередине, да?
[C++] -> misc (этот топик лучше было и создавать прямо там) 12.07.04 13:06  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
[moved from programming]
А вообще, я неоднократно разочаровывался в борландовских поделках. Начиная от глючности компилятора: один раз полтора часа искали ошибку, а оказалось, что код if (false) {continue;} ВСЕГДА независимо от условия (даже в таком виде, как приведено - с явным false) переходит к следующей итерации, другой раз один знакомый несколько дней отлаживал какую то СУБД в конце концов понял, что это глюки борландовских библиотек и пр..

Ресурсы хранятся не в нормальном виде, а в виде текстового паскалеподобного описания и динамически компилятся при запуске все в те же виндовозные ресурсы для вызова CreateDialogIndirect (типа отказаться от ресурсов смогли, а переписать user-подсистему, для поддержки своих типов ресурсов - нет). На хрена, спрашивается, промежуточное текстовое представление?

Да и вообще борландовские продукты вызывают у меня какое то чувство непрофессионализма и корявости.
[C++] -> misc (этот топик лучше было и создавать прямо там) 12.07.04 14:37  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
[moved from programming]
> А вообще, я неоднократно разочаровывался в борландовских
> поделках. Начиная от глючности компилятора: один раз
> полтора часа искали ошибку, а оказалось, что код if (false)
> {continue;} ВСЕГДА независимо от условия (даже в таком
> виде, как приведено - с явным false) переходит к следующей
> итерации,
Проверил на 6м билдере - нет такого бага, возможно в более ранних версиях оно и было. Но не надо говорить о безгрешности вижуала. Особенно что касается поддержки стандарта С++. Пример 6й вижуал, - цикл for(int i=0;....). переменная видна за границей цикла. Борланд - не видна. А по стандарту и не должна. Спецы, подробно изучавшие стандарт С++ отыщут и многое другое...

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

> Ресурсы хранятся не в нормальном виде, а в виде текстового
> паскалеподобного описания и динамически компилятся при
> запуске все в те же виндовозные ресурсы для вызова
> CreateDialogIndirect (типа отказаться от ресурсов смогли, а
> переписать user-подсистему, для поддержки своих типов
> ресурсов - нет). На хрена, спрашивается, промежуточное
> текстовое представление?
Стрянно. Беру exe'шник свежескомпиленный в билдере в котором форм - тьма тьмущая. Открываю в FARе по F3. Ищу CreateDialog по F7. И нету Ж\.
Как вариант предполагаю что борландовцы подстраховались от возможных нападок со стороны МС по формату ресурсов диалога. И думаю подстраховались небезосновательно.
Еще вариант - формат представления окон которы можно без труда перенести на другую платформу. Он же юзается в переносимом под линух CLX (штука похожая на VCL, но гораздо более тормозная)

> Да и вообще борландовские продукты вызывают у меня какое то
> чувство непрофессионализма и корявости.
А у меня такое же чуство вызывает mfc. Как будто просто кучка классов, написанных просто ради того чтобы МС могли гордо сказать - "В нашем Visual C имеется библиотека классов, позволяющих не юзая голые АПИ, написать прогу".
[C++] -> misc (этот топик лучше было и создавать прямо там) 12.07.04 15:11  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> > А вообще, я неоднократно разочаровывался в
> борландовских
> > поделках. Начиная от глючности компилятора: один раз
> > полтора часа искали ошибку, а оказалось, что код if
> (false)
> > {continue;} ВСЕГДА независимо от условия (даже в таком
> > виде, как приведено - с явным false) переходит к
> следующей
> > итерации,
> Проверил на 6м билдере - нет такого бага, возможно в более
> ранних версиях оно и было. Но не надо говорить о
Было именно на 6-м билдере и вылечилось так:

if (false) {
int a;
continue;
}

То есть глюк СИЛЬНО зависел от контекста.

> безгрешности вижуала. Особенно что касается поддержки
> стандарта С++. Пример 6й вижуал, - цикл for(int i=0;....).
> переменная видна за границей цикла. Борланд - не видна. А
> по стандарту и не должна. Спецы, подробно изучавшие
Когда появился стандарт и когда 6-й вижуал? :-)
В 7-м уже все нормально.

> стандарт С++ отыщут и многое другое...
Для тестирования компиляторов есть специальные программы. Я где-то даже встречал таблицу с результатами тестов.

> Я не встречал, хотя все может быть. Не зная глюка нельзя
> сказать глюк это или просто твой знакомый недостаточно
> изучил документацию...
Фиг его знает. В отличие от предыдущего глюка, этот был очень давно (лет 6-7 назад)

> Как вариант предполагаю что борландовцы подстраховались от
> возможных нападок со стороны МС по формату ресурсов
> диалога. И думаю подстраховались небезосновательно.
Не думаю. DLGTEMPLATE и DLGITEMTEMPLATE задокументированы в MSDN и идут еще с ранних версий. Для собственноручного создания диалога из такого ресурса нужно просто получить указатель на ресурс в отмапленном образе при помощи LoadResource и прямиком преобразовать его тип в PDLGTEMPLATE. Все. В объектнике валяются готовые к употреблению структуры.

> Еще вариант - формат представления окон которы можно без
> труда перенести на другую платформу. Он же юзается в
> переносимом под линух CLX (штука похожая на VCL, но гораздо
> более тормозная)
Бинарную структуру тоже можно кроссплатформенно разгребать. И это делается даже легче, чем разгребание текстового представления.

> > Да и вообще борландовские продукты вызывают у меня
> какое то
> > чувство непрофессионализма и корявости.
> А у меня такое же чуство вызывает mfc. Как будто просто
> кучка классов, написанных просто ради того чтобы МС могли
> гордо сказать - "В нашем Visual C имеется библиотека
> классов, позволяющих не юзая голые АПИ, написать прогу".
Поправка: чувство непрофессионализма у меня вызывает ВСЕ, что выпускает борланд, а MFC я и сам не люблю. Хотя он гораздо менее корявый, чем vcl. Кроме того, писать на VC без MFC можно и нужно, а писать на борландах без vcl - нет. Вернее можно, но на фига: все используют борланд именно за то, что там легко рисовать интерфейсы, а без vcl-а это не легче, чем в VC. Вот только и отладчик у VC лучше и среда приятнее (имхо)
Честно говоря, отладчик VC меня от кошмара с отладкой UI не спасал. 12.07.04 15:39  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
А вот разработка интерфейса в Builder поставлена гораздо лучше в плане оберегания от глупостей. Да, там хватает своих неприятностей, но тем не менее разработка UI в VC у меня оставила гораздо более тяжелое впечатление и на этапе создания, и на этапе отладки. Возможно, дело в том, что тогда я был, по большому счету, начинающим.
Насчет непрофессиональности всего что делает Borland - совершенно не согласен. Ничего подобного Delphi в плане компонентной разработки я, пожалуй, не видел до выхода нового DevStudio. Более того, по сравнению с тем, что было у Borland в плане UI, старая среда MS - это просто детские игрушки, Borland эту стадию интеграции прошла лет на 5 раньше.
Сейчас, конечно, звезда Borland слегка подзакатилась: по-настоящему они правили бал в середине девяностых. Но буквально пару лет назад тому же JBuilder альтернативы, пожалуй, просто не было. Просто компиляторы, в частности для C/C++, не являются их сильным местом.
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach