Я не совсем давно начал заниматься программированием (можно сказать недавно), и на протяжении своей бытности программистом столкнулся с парой вопросов на которые у меня не нашлось ответов. Сейчас же наступил момент, когда мне хотелось бы их получить.
1) Насколько я понял, если приложению необходимо обеспечить кроссплатформенность, то ограничиваются использованием только рантайма, без спицифичных для конкретной ОС API. (это так?) А если приложение будет работать ТОЛЬКО под Windows, то что является предпочтительным для использования: рантайм или API от ОС? Например: что лучше использовать для работы с файлами: fopen или CreateFile? Стоит ли их смешивать, или вообще отказаться от рантайма? (под смешиванием я понимаю совместное использование, а не ошибочное открытие с fopen и закрытия CloseHandle)
Я неоднакратно слышал что "API обеспечивают больший уровень сервиса по отношению к стандартным файловым функциям", но хотелось бы услышать ответ поподробнее.
2) Никак не могу взять в толк, зачем в библиотеках MFC, ATL, WTL написаны собственные слассы строк CString, если существует стандартный string от рантайм? Чем он плох? И что предпочтительнее для проектов под Windows, но без MFC?
Ещё раз прошу прощения за глупые вопросы, но буду признателен за ответы.
Спасибо.
Здравствуйте, Аноним, Вы писали:
А>2) Никак не могу взять в толк, зачем в библиотеках MFC, ATL, WTL написаны собственные слассы строк CString, если существует стандартный string от рантайм? Чем он плох? И что предпочтительнее для проектов под Windows, но без MFC?
1) Строки в MFC появились еще когда еще стандарта небыло. Кроме того они банально удобнее для разработки на WinAPI.
2) WTL были добавлены строки, реализация которых не завистит от с++ crt. В свое время это было важно для получения сверхмалого размера бинарника. Сейчас не используются.
3) Были добавлены в ATL в 7 студии. Т.е. сейчас MFC и WTL используют строку из ATL
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Аноним, Вы писали:
А>Привет всем!
Привет!
А>Я не совсем давно начал заниматься программированием (можно сказать недавно), и на протяжении своей бытности программистом столкнулся с парой вопросов на которые у меня не нашлось ответов. Сейчас же наступил момент, когда мне хотелось бы их получить.
Изложу имхо.
А>1) Насколько я понял, если приложению необходимо обеспечить кроссплатформенность, то ограничиваются использованием только рантайма, без спицифичных для конкретной ОС API. (это так?)
Считаю приоритетом "рантайм" и библиотеки языка. Существует не только С\С++, а в других языках дотянуться до API бывает не так то просто и не нужно. Т.е. подход такой: если можно просто взять, и писать std::cout, std::fstream или тот же fopen() — то так и надо делать. С другой стороны, как только возникают более системные задачи — требуются потоки, проекции файлов в память. И не имея желания тащить в проект большую библиотеку (а иногда это указано ), конечно приходится юзать API — писать обертки.
А>Я неоднакратно слышал что "API обеспечивают больший уровень сервиса по отношению к стандартным файловым функциям", но хотелось бы услышать ответ поподробнее.
Обеспечивает. Хотя бы , например, аттрибуты безопасности доступа. Поподробнее — читаем о std:: в книгах по С++ и про API в Рихтере, Харте, Соломоне (Win) или в Стивенсе (unix) и находим отличие. Это будет исчерпывающе-подробно
А>2) Никак не могу взять в толк, зачем в библиотеках MFC, ATL, WTL написаны собственные слассы строк CString, если существует стандартный string от рантайм? Чем он плох? И что предпочтительнее для проектов под Windows, но без MFC?
Как уже сказали, что давным-давно, в далекой галактике... не было std::string И тогда же был спроектирован, уж как смогли, MFC. И именно в контексте MFC его родной CString полностью себя оправдывает. И в контектсте ATL — его же стринг так же себя оправдывает. В настоящих реалиях, не используя этих библиотек, не вижу смысла их тащить только за ради их CString или какого-нибудь CFile.
Может сложиться впечатление, что куда то ушли все эти "MFC, ATL...". Нет, не ушли, но появились другие технологии для решения задач, для которых они были предназначены (.net) и появились другие библиотеки, Qt например. boost опять же настолько разнопланов, что трудно отнести его к какой либо категории, пожалуй что только не для GUI, а системных вещей (мультиплатформанных!) в нем много. Сетевая-сервисная системная библиотека ACE ... так же многоплатформанная. Кстати, наблюдается тенденция, что уж если пишется библиотека, то она мультиплатформенная. Причем в разных библиотеках реализованы разные подмножетсва чистой API функциональности, зачастую довольно обширные. И если есть возможность и целесообразность притянуть какую библиотеку в проект, то, имхо, стоит это сделать — обычно всякие нюансы при работе с API удобно обернуты библиотекой (см. например здесь
Исходя из своего опыта: А>1) Насколько я понял, если приложению необходимо обеспечить кроссплатформенность, то ограничиваются использованием только рантайма, без спицифичных для конкретной ОС API. (это так?) А если приложение будет работать ТОЛЬКО под Windows, то что является предпочтительным для использования: рантайм или API от ОС? Например: что лучше использовать для работы с файлами: fopen или CreateFile? Стоит ли их смешивать, или вообще отказаться от рантайма? (под смешиванием я понимаю совместное использование, а не ошибочное открытие с fopen и закрытия CloseHandle)
Почти всегда создавалась своя обёртка над файловой системой, так как:
CRT функции работают не на всех платформах, особенно это касается ембеддед (одного этого достаточно)
Как правило обёртка упрощает работу с функциями ОС и приводит форму этой работы к общему стандарту для проекта.
А>Я неоднакратно слышал что "API обеспечивают больший уровень сервиса по отношению к стандартным файловым функциям", но хотелось бы услышать ответ поподробнее.
Возможно предполагался более низкий уровень работы чему у CRT и STL и большее тонкое управление системой.
А>2) Никак не могу взять в толк, зачем в библиотеках MFC, ATL, WTL написаны собственные слассы строк CString, если существует стандартный string от рантайм? Чем он плох? И что предпочтительнее для проектов под Windows, но без MFC?
Во-первых std::string — это скорее контейнер для строк, чем нормальный класс строки. Во-вторых, для движка мы используем модификации std::string, а для виндового UI — всё в перемешку.
Аноним 910 пишет: > 1) Насколько я понял, если приложению необходимо обеспечить > кроссплатформенность, то ограничиваются использованием только рантайма, > без спицифичных для конкретной ОС API. (это так?)
Это так. Но проблема в том, что много чего на одном CRTL не напишешь.
К сожалению. Но есть boost ...
А если приложение > будет работать ТОЛЬКО под Windows, то что является предпочтительным для > использования: рантайм или API от ОС?
Это зависит исключительно от требований к этому приложению.
> для работы с файлами: fopen или CreateFile? Стоит ли их смешивать, или > вообще отказаться от рантайма? (под смешиванием я понимаю совместное > использование, а не ошибочное открытие с fopen и закрытия CloseHandle)
Смешивать можно, если это нужно. Ничего криминального в этом нет.
> Я неоднакратно слышал что "API обеспечивают больший уровень сервиса по > отношению к стандартным файловым функциям", но хотелось бы услышать > ответ поподробнее.
Да, поскольку API конкретной OS обеспечивает всю функциональность
данной OS в данном случае для работы с файлами. Но программа становиться
"только для этой ОС". CRTL же использует подход "наибольшего общего
кратного". Реализует только то, что есть везде.
> 2) Никак не могу взять в толк, зачем в библиотеках MFC, ATL, WTL > написаны собственные слассы строк CString, если существует стандартный > string от рантайм?
Гы... сейчас начнется ....
Но во-первых надо сказать, что конкретно CString конкретно в MFC
появился тогда, когда STL-я еще и в проектах не было. И потом CString
поддерживает много специфичных для Win32 функций, которых нет в STD.
Чем он плох?
Ну, как сказать ... многим. Нет быстрого копирования,
нет подсчета ссылок (точнее они могут быть, но стандарт
не оговаривает обязательность их наличия, а это — все равно
что их нет), нет удобных функций обработки.
Но тут опять-таки многое зависит
от специфики приложения. Для одних приложений хватает, для других —
нет.
И что предпочтительнее для проектов под > Windows, но без MFC?
использование стандартных функций не всегда дает гарантию кроссплатформенного кода (или близкого к нему). к примеру, для PalmOS, несмотря на то, что компилятор поддерживает стандартные функции С и С++, я бы порекомендовал использовать API функции, в силю большого количества нюансов, которые можно полностью контролировать только при использовании API. если вам нужен кроссплатформенный код, то я бы порекомендовал использовать специально для этого предназначенные библиотеки.
Я так понимаю под рантаймом тут понимается CRT + STL?
А>1) Насколько я понял, если приложению необходимо обеспечить кроссплатформенность, то ограничиваются использованием только рантайма, без спицифичных для конкретной ОС API. (это так?)
It depends. А если в рантайме нет необходимого функционала? Рантайм довольно обобщен и абстрагирован от конкретной ОС.
А>А если приложение будет работать ТОЛЬКО под Windows, то что является предпочтительным для использования: рантайм или API от ОС? Например: что лучше использовать для работы с файлами: fopen или CreateFile? Стоит ли их смешивать, или вообще отказаться от рантайма? (под смешиванием я понимаю совместное использование, а не ошибочное открытие с fopen и закрытия CloseHandle)
Я не пользуюсь рантаймом совсем (исключение поддержка float и т.п.) — очень уж он убог. Кроме того, все равно вызов рантайма сведется к вызовам API, только еще будет выполнена кучка кода, который зачастую попросту делает ненужную работу. Потоки STL вообще редкое убожество. Для текста еще пойдет, но не для работы с бинарными данными.
Все разумеется ИМХО.
А>Я неоднакратно слышал что "API обеспечивают больший уровень сервиса по отношению к стандартным файловым функциям", но хотелось бы услышать ответ поподробнее.
Достаточно почитать что можно сделать с файлом через тот же fopen и CreateFile.
А>2) Никак не могу взять в толк, зачем в библиотеках MFC, ATL, WTL написаны собственные слассы строк CString, если существует стандартный string от рантайм? А> Чем он плох? И что предпочтительнее для проектов под Windows, но без MFC?
Ну, вообще std::string сам по себе не так уж и плох. Плохо то, что его реализации в разных рантаймах бывают разными.
В одном есть буфер для маленьких строк — т.е. не происходит выделение памяти при работе с короткими строками, зато размер инстанса класса строки больше на размер этого буфера, вне зависимости используется он или нет.
В другом хранится счетчик ссылок и одинаковые строки в памяти хранятся в одном экземпляре, на который ссылаются все инстансы
В третьем вообще никаких ухищрений — все тупо в лоб.
Поэтому когда перекомпиливаешь программу под другим рантаймом могут вылезти различного рода нюансы в поведении — например начнет работать медленнее и жрать больше памяти.
Потому и сделали МС свой класс, для которого они могут гарантировать неизменное поведение вне зависимости от рантайма.
Кроме того, насколько я помню, MFC CString появился до того как стандартизировали STL.
Где то так...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
), конечно приходится юзать API — писать обертки.
