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

J>Просто возьми его книжку и стандарт и сравни.

А куда смотреть в стандарте?

6.5.3 The for statement

. . .

int i = 42;
int a[10];
for (int i = 0; i < 10; i++)
    a[i] = i;
int j = i;

int, не unsigned.

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

LM>boost::lexical_cast
А что, это быстро?

E>2) Во многих случаях было бы, IMHO, последовательно, для всяких действий использовать внешине функции.
E>Скажем для округления float мы же используем внешние функции, а не методы?
E>Для выяснения длины const char* тоже. И т. д.

ИМХО наиболее ровный метод — дать возможность на уровне языка расширять класс после его обьявления невиртуальными функциями, не имеющими доступа к private/protected секции класса. С одной стороны — для компилятора это всего лишь синтаксический сахар, с другой — удобство использования класса будет соседствовать с удобством его расширения. А то попытка добавить пару методов в std::string или std::vector выливается в пару экранов кода, так что проще действительно это сделать внешней по отношению к классу функцией.

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

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

S>>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?
LVV>Дело не в STL, а в синтаксисе шаблонов.

Вынужден согласиться
Но вот, к примеру, MFC-контейнеры (сейчас меня закидают помидорами ), хоть конечно и используют заглавные буквы (что я считаю читабельности только на пользу), предлагают достойную замену итераторам — POSITION. Было бы замечательно если бы MFC ещё и переносимостью обладала.

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

L>ИМХО наиболее ровный метод — дать возможность на уровне языка расширять класс после его обьявления невиртуальными функциями, не имеющими доступа к private/protected секции класса. С одной стороны — для компилятора это всего лишь синтаксический сахар, с другой — удобство использования класса будет соседствовать с удобством его расширения. А то попытка добавить пару методов в std::string или std::vector выливается в пару экранов кода, так что проще действительно это сделать внешней по отношению к классу функцией.

Можно, конечно, и так. Типа первый параметр this называешь и поехали...

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

S>Вынужден согласиться
S>Но вот, к примеру, MFC-контейнеры (сейчас меня закидают помидорами ), хоть конечно и используют заглавные буквы (что я считаю читабельности только на пользу), предлагают достойную замену итераторам — POSITION.
Очень достойно, но, ИМХО, отстойно.
(Пардон, не удержался от рифмы).

S>Было бы замечательно если бы MFC ещё и переносимостью обладала.
И позволяла бы хранить объекты

Автор: Smal
Дата: 21.02.07

.

Прочитайте сначала эту ветку

Автор: Erop
Дата: 18.02.07

.
А то в десятый раз одно и то же писать уже надоело

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

LM>>boost::lexical_cast
E>А что, это быстро?
Сейчас уже да.


P.S. Какая сволочь подняла старую тему?!

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

C>>Если ты не можешь сделать reserve — тебе в любом случае придётся делать какой-то вариант экспоненциального увеличения буффера.
J>ну либо воспользоваться std::deque.
Дека — это уже другой контейнер, со своими особенностями.

C>>Единственный минус STL — она не поддерживает перемещаемые объекты, ей приходится их всегда копировать.
J>Это в "поделке прошедших веков" так
J>А уже в текущем драфте стандарта красным по белому перечеркнуто требование "T is CopyConstructible".
J>И, естественно, все методы вставки принимают ссылки на rvalue.
То есть, наконец-то можно будет передвигаемые объекты класть?

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

LM>>boost::lexical_cast
E>А что, это быстро?
Для большинства случаев (int->float, string->int...) — уже быстро.

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

C>>Единственный минус STL — она не поддерживает перемещаемые объекты, ей приходится их всегда копировать.
E>О чём и речь...
E>Но это довольно существенный минус, IMHO.
Это уже исправили

E>Кроме того он не единственный.
А можно список? Я ещё знаю не очень продуманую схему работы с аллокаторами, разве что.

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

J>>твоя любимая библиотека общедоступна?
E>AFAIK, нет, во всяком случае пока. Она самописная (не совсем "само", но группой товарищей) и так и называется MFL :)

Я как-то уже задавал этот вопрос, но, может быть, что-то изменилось.

Как в YFL выглядит поэлементный обход аналога std::deque?

И как в YFL выглядит поиск значения в массиве, про который известно, что он упорядочен по такому-то критерию?

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

RO>Я как-то уже задавал этот вопрос, но, может быть, что-то изменилось.
RO>Как в YFL выглядит поэлементный обход аналога std::deque?
RO>И как в YFL выглядит поиск значения в массиве, про который известно, что он упорядочен по такому-то критерию?

1) аналога std::deque нет. Пока был не нужен. Есть всякие другие структуры данных, которых нет в std
2) есть шаблонный метод Find

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

LM>P.S. Какая сволочь подняла старую тему?!

Про моральные качества коллег ничего сказать не могу, но самое первое сообщение за этот год было вроде бы таким

Автор: Symon
Дата: 28.04.08

, второе что-то типа такого

Автор: Wo-o-olf
Дата: 28.04.08

...
Бессмысленно и беспощадно, короче

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

S>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?
раз есть понятие stl-like кто-то считают что способствует но при этом им сам STL чемто не нравится. Например абсолютно все гуи имеют свое core в котором свой Xarray (или Xvector) и свой XString, даже недавнишний u++.

А какой популярный продукт есть на чистом СТЛ?

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

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

C>>>Если ты не можешь сделать reserve — тебе в любом случае придётся делать какой-то вариант экспоненциального увеличения буффера.
J>>ну либо воспользоваться std::deque.
C>Дека — это уже другой контейнер, со своими особенностями.
Ну я вот не знаю, как иначе бороться с переаллокацией всего массива целиком.

C>>>Единственный минус STL — она не поддерживает перемещаемые объекты, ей приходится их всегда копировать.
J>>Это в "поделке прошедших веков" так
J>>А уже в текущем драфте стандарта красным по белому перечеркнуто требование "T is CopyConstructible".
J>>И, естественно, все методы вставки принимают ссылки на rvalue.
C>То есть, наконец-то можно будет передвигаемые объекты класть?

угу

You will always get what you always got
  If you always do  what you always did

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

E>>Кроме того он не единственный.
C>А можно список? Я ещё знаю не очень продуманую схему работы с аллокаторами, разве что.
Ты, кстати, видел в драфте, что сделали с аллокаторами?
раздел 20.6, полюбопытствуй

You will always get what you always got
  If you always do  what you always did

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

C>>А можно список? Я ещё знаю не очень продуманую схему работы с аллокаторами, разве что.
J>Ты, кстати, видел в драфте, что сделали с аллокаторами?
J>раздел 20.6, полюбопытствуй
Что-то не внушает. Возможности возвращать умные указатели так и не добавили. Что делать со stateful-аллокаторами тоже непонятно (так как для контейнеров в swap() указано константное время).

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

E>>Ну дык верная рекомендация-то...
I>Так ведь это упрощение.
Ну дык это ж гроссмейстер новичкам советует...
Как в книжках по шахматам: конь на краю доски — плохо.
А гроссмейстеры ж сплошь и рядом играют...

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

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

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

M>>>Нет в СТЛ какой-то структурировнности, что-ли. Какого-то простого правила — "Вот это точно должно быть в СТЛ, а вот это — не стоит и искать там".

KBH>>Это не в STL нет структурированности, а в твоих знаниях оной.

M>Согласен. Только почему-то не я один такой. Наверное потому,что для того что бы сказать что функция next_permutation есть в STL это нужно просто ЗНАТЬ. Ты не можешь об этом догадаться, как например ты можешь не знать, чтоо в boost::filesystem есть функция извлечени пути из полного имени файла, но при этом логично предположить, что она там есть. И в 1-ю очередь я загляну в хелп, ибо вероятность найти там желаеме высока. А в случае с STL ДОГАДАТЬСЯ о наличии там какой-то фичи — проблематично. Если я не уверен что там есть нужный мне алгоритм,то не буду тратить время на штудирование хелпа — я напишу свой, ибо мои поиски могут не увенчаться успехом и я в пустую потрачу драгоценное время. Если конечно передо мной не стоит задача "по максимуму использовать STL".

MSDN, <algorithm> Members
Все функции на одной странице.