volatile,у вас вроде VS (или кто нибудь другой у кого она есть)..
  какой sizeof у std::string ? 
 VS желательна старой версии, на новой будет скорей всего будет 4 байта ( из за cow)..

Это сообщение отредактировал(а) mes - 19.11.2011, 12:36

mes, VS2005/Win7x64, Default Project Settings for Console App:
Debug
32 bytes
Release
28 bytes

попробовал в VS2010 - результат тот же

Это сообщение отредактировал(а) semibug - 19.11.2011, 12:53

mes, 
В студии стринг маленькие строки (кажется до 14 байт, точно не помню) хранит внутри себя, без выделения памяти. Поэтому размер не 4 байта, а как сказал 
semibug, 




Это сообщение отредактировал(а) volatile - 19.11.2011, 13:04

 , и для больших строк этот буфер остается незайдествованным.. этим они и спасаются от вышеуказанной ошибки.. но ничто не мешало (кроме их взглядов на эффективность) им сделать реализацию, которая хранила бы часть строки в локальном буфере, а хвост в куче..

Добавлено через 1 минуту и 55 секунд

это не проверял, но я все ж надеюсь что у них именно так, а не 

потому как в противном случае, пдобная проблема всплывала бы часто..

Добавлено через 6 минут и 13 секунд

я говорил :

а эт несколько иное значение 

Добавлено через 11 минут и 53 секунды

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

где-то на винграде это обсуждалось. но я не понимаю где здесь хоть намек на эффективность? вот нужно создать мильен строк размером больше того буфера, и что мы получим? - пустые расходы памяти. ведь 14*1000000 = 14мб  

Это же не объективный (специально подобранный) тест, чтобы дескредитировать такой алгоритм.
Почему-бы не взять (тоже не объективный) тест с мульеном строк, но размером чуть меньше этого буфера.  Если вспомнить что выделение памяти одна из самых тормознутых операций, то тест будет далеко не в пользу реализаций с коротким sizeof (string).
Впрочем я не защищаю их алгоритм.
У стл-порт короткий sizeof (string), можно поставить его - выбор есть всегда. Но реального быстродействия, и экономии памяти при использовании стл-порт::string, у я не заметил.


Вот здесь ударение надо поставить на бы.
mes, я не возражаю что это нарушение правил, и что так делать нельзя. Я только хочу сказать, что в реале я не встречал (возможно даже они где-то есть, но я не видел) реализаций стринга которые бы не работали, так как преположил borisbn.

если это правило случайно ( VS была специально приведена дкак пример вполне не ожидаемой реализации) не было нарушено, это не дает нам право никаких оснований на спокойное их нарушение..

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



Это сообщение отредактировал(а) mes - 19.11.2011, 15:29

mes, абсолютно согласен.