_>>как мне кажется тут проблема у MFC... т.к. выделенное это С стиль

XC>а как решить эту задачу используя C++ стиль?

я полагаю использовать GUI библиотеки написанные в С++ стиле

LuciferMoscow wrote:

> Это подразумевалось, т.к. мы говорим об STL. А как добавлять элементы в
> Ваш массив?
Написать свой аллокатор, который будет использовать alloca.
Правда нафиг нужно — непонятно.

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

.>Написать свой аллокатор, который будет использовать alloca.
.>Правда нафиг нужно — непонятно.

Зачем не знаю. Но мне так кажется, что выделенное осуществить не удастся

Erop wrote:

> .>*Написать свой аллокатор, который будет использовать alloca.*
> .>Правда нафиг нужно — непонятно.
> Зачем не знаю. Но мне так кажется, что выделенное осуществить не удастся
Почему? Аллоцировать с запасом, деаллокация — ничего не делает (или отмечает блок как свободный, на случай если кто-то
другой запросит блок такого размера), аллокация — всегда выделяет новый буфер.

Правда всё равно в реальной жизни это бесполезно, т.к. размер стека жутко ограничен.

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

E>> Коммерческая библиотека классов, которая поставляется, например, с CodeWarrior

_>а её можно посмотреть не покупая?
Не знаю. У меня когда-то получалось
Может потому, что я это делал под MacOS, там есть своя специфика с пиратством

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

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

E>>> Коммерческая библиотека классов, которая поставляется, например, с CodeWarrior

_>>а её можно посмотреть не покупая?
E>Не знаю. У меня когда-то получалось
E>Может потому, что я это делал под MacOS, там есть своя специфика с пиратством

да хотябы примеры доки... чтоб оценить

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

_>я полагаю использовать GUI библиотеки написанные в С++ стиле
Библиотека называется Windows API или X-Windows, например.
О сотовых телефонах я вообще скромно молчу пока что.
И? Как решаем?: )

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

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

_>>я полагаю использовать GUI библиотеки написанные в С++ стиле
E>Библиотека называется Windows API или X-Windows, например.
E>О сотовых телефонах я вообще скромно молчу пока что.
E>И? Как решаем?: )

легко

пишем C++ обёртки над этим C style API

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

>> Это подразумевалось, т.к. мы говорим об STL. А как добавлять элементы в
>> Ваш массив?
.>Написать свой аллокатор, который будет использовать alloca.
.>Правда нафиг нужно — непонятно.
Т.е. Вы из стека кучу собираетесь сделать?

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

.>Почему? Аллоцировать с запасом, деаллокация — ничего не делает (или отмечает блок как свободный, на случай если кто-то
.>другой запросит блок такого размера), аллокация — всегда выделяет новый буфер.
Потому, что alloca выделяет память на стековом фрейме вызывающей функции, то есть метода аллокатора
Так как inline-подсьановку метода гарантировать невозможно, то и работтоспособность этого "изделия" гарантировать не удастся

.>Правда всё равно в реальной жизни это бесполезно, т.к. размер стека жутко ограничен.
Странно. В известных мне операционках, обычно можно отматать столько стэка, сколько надо...
Пишешь нужное число в заголовок exeшника и всё...

А ещё можно стэк другой нити использовать...

Erop wrote:

> .>Почему? Аллоцировать с запасом, деаллокация — ничего не делает (или
> отмечает блок как свободный, на случай если кто-то
> .>другой запросит блок такого размера), аллокация — всегда выделяет
> новый буфер.
> Потому, что alloca выделяет память на стековом фрейме вызывающей
> функции, то есть метода аллокатора
Хм... Действительно... Не подумал. Если можно как-то параметром аллокатору передавать текущий стековый фрейм... В
общем тут я уже сомневаюсь.

> .>Правда всё равно в реальной жизни это бесполезно, т.к. размер стека
> жутко ограничен.
> Странно. В известных мне операционках, обычно можно отматать столько
> стэка, сколько надо...
По умолчанию 1 мег. А как стек можно мотать динамически? Как оно будет гарантировать то, что место будет?

> Пишешь нужное число в заголовок exeшника и всё...
Ну это аналогично вызову reserve с большим числом прозапас (или специальному аллокатору с фиксированным размером).

> А ещё можно стэк другой нити использовать...
Извращенец.

LuciferMoscow wrote:

> Т.е. Вы из стека кучу собираетесь сделать?
АГА!
Вот и интересно — а возможно ли?

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

_>да хотябы примеры доки... чтоб оценить
Если найду -- кину.
Там идея такая, что можно преобразовывать строки в числа и взад. Довольно легко и прямо.
При этом они там строки короче чего-то вообще не аллокируют никогда.

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

_>пишем C++ обёртки над этим C style API
Ну это и есть так называемое "совсем не уменьшается производительность труда" и "зачем писать свой велосипед, если есть STL"

Но это всё лирика. Вот есть LISTBOX. Наверное он довольно известен. На всяк случай скажу, что там на элемент можно задать 32 бита данных.
И что же мы пишем, чтобы запихнуть туда итератор?

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

.>Хм... Действительно... Не подумал. Если можно как-то параметром аллокатору передавать текущий стековый фрейм... В
.>общем тут я уже сомневаюсь.
И не зря

>> Странно. В известных мне операционках, обычно можно отматать столько
>> стэка, сколько надо...
.>По умолчанию 1 мег. А как стек можно мотать динамически? Как оно будет гарантировать то, что место будет?
Ну заранее в заголовке EXE пишешь максимальный размер, какой тебе надо и пользуйся, хоть ГИГ

>> А ещё можно стэк другой нити использовать...
.>Извращенец.

А то!

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

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

_>>да хотябы примеры доки... чтоб оценить
E>Если найду -- кину.
E>Там идея такая, что можно преобразовывать строки в числа и взад. Довольно легко и прямо.
boost::lexical_cast
E>При этом они там строки короче чего-то вообще не аллокируют никогда.
MS реализация std::string

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

CS>А map? Как хранилище key/value пар? Ну дык hashmap эффективнее.
CS>Или как упорядоченный по ключу набор? И часто такое нужно?

Бывает нужно, и не так уж редко. А вот написать хорошую хэш-функцию, чтобы выполнялось выделенное, иногда для объектов куда сложнее, чем написать оператор порядка.

Здравствуйте, Erop, Вы писали:
.>>Правда всё равно в реальной жизни это бесполезно, т.к. размер стека жутко ограничен.
E>Странно. В известных мне операционках, обычно можно отматать столько стэка, сколько надо...
E>Пишешь нужное число в заголовок exeшника и всё...
Зачем patch-ить exe-файл? Серьёзный компилятор позволяет указать размер stack-а главного thread-а.

• MSVC6:
  меню «Project»,
  пункт «Settings…»,
  окно «Project Settings»,
  страница «Link»,
  выпадающий список «Category:» – выбрать «Output»,
  группа «Stack allocations»,
  поля ввода «Reserve:» и «Commit:».
  
• BCB5:
  меню «Project»,
  пункт «Options…»,
  окно «Project Options»,
  страница «Linker»,
  группа «PE file options»,
  поля ввода «Min stack size:» и «Max stack size:».

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

А>2. Все STL-контейнеры неявно копируются. Опасно, если неявная операция дорога.

Это опасность "по невнимательности". Таких опасностей в С++ много и недостаками они в рамках идеологии С++ считаются не должны.

А>4. STL-контейнеры провоцируют использование size_t. Беззнаковость этого типа влечёт проблемы.

Это неверно. В STL-контейнерах никак не используется 'size_t'. Используется же там контейнерно-зависимый беззнаковый тип 'size_type'. Использование беззнакого типа вполне оправдано, ибо соответствует он заведомо неотрицательному значению. В данном случае наблюдается следование правилу "всегда использовать в программе только беззнаковые типы, кроме тех мест, где необходим знаковый тип", что более чем похвально.

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

А> Сам он всячески призывает программиста использовать int.

В этом Страуструп не столько "не прав", сколько допускает черезмерное упрощение, ориентируясь на начинающего программиста (его книга изобилует такими упрощениями). Это лишь вопрос подходов к обучению: учиться ли правильному использованию беззнаковых типов с самого начала, или все таки отложить на потом. Страуструп считает, что лучше отложить. Многие считают что лучше сразу.

А>Какое отношение size_t имеет к array-based контейнерам (vector, string), ещё понятно: в языках C/C++ длина/индекс массива выражаются типом size_t. Какое отношение size_t имеет к node-based контейнерам (list, map), непонятно совсем. В 90-ые годы (время проектирования STL), когда ещё живы были 16-битные платформы, использование size_t было оправдано. Сейчас это источник тонких ошибок.

Это утверждение построено на неверном предположении, что используется именно тип 'size_t'. На самом деле же никакого 'size_t' там и близко нет. Не надо путать 'size_t' с 'container<>::size_type'.

А>"Проблему size_t" можно решить несколькими способами:

Реальный способ тут только один — уситься пользоваться беззнаковыми типами как можно раньше. 99% целых типов в профессионально написаной среднестатистической программе должны являться беззнаковыми. Знаковые типы используются только в исключительных случаях.

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

А>5. Нельзя получить итератор по указателю на элемент контейнера за константное время.

В общес случае — нельзя. Но это ограничение имеет свои оправдания, свои плюсы и минусы. Странно видеть его в качестве "минуса".

А>6. Вместо метода empty удобнее был бы метод с позитивным смыслом, например has_elems (возвращает true <=> в контейнере есть хотя бы один элемент).

Неочевидно. Если и минус, то очень слабый.

А>7. Нельзя const_cast const_iterator в iterator. Я с этой проблемой на практике не сталкивался. Теоретически, может возникнуть при неудачном дизайне.

Слабый и странный "минус".

А>9. list
А>9.1. list спроектирован так, что либо size за константное время, либо splice (вариант с 4-мя параметрами) за константное время (при условии, что allocator-ы равны).

А что делать? Так устроен мир. Именно к STL это мало относится.

А>10. string
А>10.1. Если программа много работает с текстом, то string (или его аналог) — ходовой тип. При этом желательно, чтобы неявное копирование string-а было дешёвым. Для этого реализация string-а может использовать разделяемый (между несколькими string-ами) буфер с подсчётом ссылок. Но string спроектирован в mutable стиле, поэтому у него есть не-const методы begin, end, rbegin, rend, operator[] и at. Если реализация string-а считает ссылки, то эти методы делают copy-on-write (даже если вы не собираетесь ничего менять) и запрещают разделяемость буфера.

По-моему это вопрос качества реализации. Нет?

А>10.2. Нет завершающего '\0'.

Нет. Не вижу в этом минуса. А придумать ситуацию, когда это неудобно можно всегда.

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

_>>>да хотябы примеры доки... чтоб оценить
E>>Если найду -- кину.
E>>Там идея такая, что можно преобразовывать строки в числа и взад. Довольно легко и прямо.
LM>boost::lexical_cast
E>>При этом они там строки короче чего-то вообще не аллокируют никогда.
LM>MS реализация std::string

т.е. ты видел это ? (PowerPlant)