Великий и ужасный С++

Ответить

Код подтверждения
Введите код в точности так, как вы его видите. Регистр символов не имеет значения.
BBCode ВКЛЮЧЁН
[img] ВКЛЮЧЁН
[url] ВКЛЮЧЁН
Смайлики ОТКЛЮЧЕНЫ
Обзор темы
   

Развернуть Обзор темы: Великий и ужасный С++

Kolinus » 28 авг 2004, 19:32

"Вот уж фигушки. Если работать с вычислительными задачами - то
ИМЕННО на платформенно-зависимые штуки внимание и стоит обратить"
И я о том же - прикладник - в первую очередь думает о пользователе а не о качесвте вычисдительных алгоритмов.

alexx » 27 авг 2004, 22:15

Нередко надо точно знать положение данных в памяти и контролировать её потребление, иначе эффективно задачу не решишь. С и С++ для этого идеально подходят.

Но нужна ли эта сила для рутинных операций, например обработка реакций юзверя, строчные манипуляции до 1-2 MB?
С неподходит, но С++ имеет достаточно средств для этого. Ими и пытается научить пользоватся Страуструп. Дать определённый стиль создания кода.

Сам пока ещё это до конца не постиг, но надеюсь получится, уж больно убедительно дядька пишет ;-)

DeeJayC » 27 авг 2004, 18:12

Kolinus писал(а):На Java тоже все не так просто и там тоже порой ой как волнует и количество символов на строку и кодировка.
В жабе, кстати, string тоже класс.
А по поводу плтформ депендент штук - по -моему системного ПРОГРАММИСТА они в первую очередь и должны волновать. А прикладника - скажем так - он о них должен помнить (ИМХО).
Вот уж фигушки. Если работать с вычислительными задачами - то
ИМЕННО на платформенно-зависимые штуки внимание и стоит обратить.

Absurd » 27 авг 2004, 16:19

А также программиста, видимо, не должны волновать
platform-dependent штуки
В С++ объекты отличаются от С-style POD данных. К полноценным объектам, имеющим конструктор, неприменимы операции прямой работы с памятью типа realloc/memmove/memcpy либо их запись на диск с помощью fwrite.
Если бы в C++ был атомарный тип string, то его невозможность помещения в рамки POD структуры не была бы сильным недостатком.
Разумеется, возможность его конверсии в char[] должна была быть предусмотрена.
Ну дык, уважаемый, срочно садимся за мак и пишем на жабе.
Нет уж нет уж. Задача платформеннозависимая. Юзаю _bstr_t и _variant_t в конъюнкции с STL и разгребаю монструозные сообщения об ошибках.
В Дельфи надо брать SDK от каких-то левых лиц, что тоже паршиво.

Kolinus » 27 авг 2004, 15:22

На Java тоже все не так просто и там тоже порой ой как волнует и количество символов на строку и кодировка.
А по поводу плтформ депендент штук - по -моему системного ПРОГРАММИСТА они в первую очередь и должны волновать. А прикладника - скажем так - он о них должен помнить (ИМХО).

DeeJayC » 27 авг 2004, 13:52

Absurd писал(а): Программиста такие вещи как количество символов и количество байт на символ не должны волновать.
Ню-ню... Ещё как должны.

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

Absurd » 27 авг 2004, 13:33

я имел ввиду не указатель а сам обэект, созданный статически
Выражение sizeof(std::string) внолне может быть равно и четырем.

Kolinus » 27 авг 2004, 12:51

Это понятно (про указатель (но скоро будет 8 байт :) ))я имел ввиду не указатель а сам обэект, созданный статически.

Absurd » 27 авг 2004, 12:10

а объект строки стл - точно не помню вроде 16 байт + количество символов.
Сам экземпляр объекта не требует больше, чем 4 байт, т.к. там достаточно всего одного члена - указателя на буффер.
В буффере может храниться помимо сиимволов еще какая-нибудь лабуда для подсчета ссылок и/или синхронизации
многопотокового доступа.

Вернуться к началу