Re: Compile-time strlen - C/C++

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

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

__>>Насчет копирование решается просто: Boost.Range (Поиск по форуму помогает

)

__>>

__>>typedef boost::iterator_range<char> char_range;

__>>void f(char_range p)
__>>{
__>>}

__>>std::string my_str("aa"); // Copy
__>>f(make_iterator_range(my_str));

__>>char const my_array[] = "aa";  //Copy
__>>f(make_iterator_range(my_array)); // No copy
__>>

Вы плохого мнения о компиляторах.
Компилятор умеет оптимизировать эту вещь и не делать настоящего копирования.

    const char a[] = "aaa";
004113BE A1 3C 57 41 00   mov         eax,dword ptr [string "aaa" (41573Ch)] 
004113C3 89 45 F8         mov         dword ptr [a],eax

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

А>Во блин. Прикольный язык, ИМХО его невозможно выучить до конца — пока выучишь, новый стандарт приймут

За похвалу конечно спасибо, но это всё-таки заблуждение. ИМХО можно довольно глубоко

Ну да это просто комитет нас щадит

Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском

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

L>Re[4]: Compile-time strlen Написать-то можно, но как известно, всё украдено до нас.

Может кто уже сделал такое.

Ну ct-strlen можно много как написать. Только объект иметь таки удобнее. Его же копировать там можно, begin end приделать и всё такое...

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

...

__>Вы плохого мнения о компиляторах.
__>Компилятор умеет оптимизировать эту вещь и не делать настоящего копирования.

__>

__>    const char a[] = "aaa";
__>004113BE A1 3C 57 41 00   mov         eax,dword ptr [string "aaa" (41573Ch)] 
__>004113C3 89 45 F8         mov         dword ptr [a],eax 
__>

; Function compile flags: /Ogtpy
; COMDAT _wmain

...

; 14 : const char a[]="34bfc3xnw3xheirxfb846xtb4n8xg54xngf54r";

mov ecx, 9
mov esi, OFFSET ??_C@_0CH@DJLFEJFA@34bfc3xnw3xheirxfb846xtb4n8xg54x@
lea edi, DWORD PTR _a$[esp+52]
rep movsd

Я бы сказал, что я разумного о них мнения, и предпочел бы не расчитывать лишний раз на них. Это стандартные Release настройки VS2K5SP1.

Более того, если бы Вы внимательно посмотрели на код, который сами же привели, то увидели бы, что копирование происходило, просто такой Вы подобрали пример, что скопировать надо 4 байта — 3 'a' и завершающий 0. Что как раз влезает в DWORD, который и скопировался.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>Только в первой строке произойдет копирование в буфер. Хотелось бы этого по возможности избежать. А во второй избежать вызова strlen или совсем, или хотя бы многократного.

L>>Если есть 2 класса, один из которых, скажем ограничивает интерфейс только константными методами, а второй копирует в буфер только по необходимости, то совсем замечательно было бы.

N>Может имеет смысл посмотреть в сторону const_string ?

Спасибо большое, скачал, разбираюсь. Буду профилировать с этими строками.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>Re[4]: Compile-time strlen Написать-то можно, но как известно, всё украдено до нас.

Может кто уже сделал такое.

E>Ну ct-strlen можно много как написать. Только объект иметь таки удобнее. Его же копировать там можно, begin end приделать и всё такое...

Так никто не спорит, тем более не сильно и отличаются Ваш class constStr от моего template<typename T, int len> class StringLiteral.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Так никто не спорит, тем более не сильно и отличаются Ваш class constStr от моего template<typename T, int len> class StringLiteral.

Принципиально отличается. У меня тип объекта не зависит от его значения...

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

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

L>>Так никто не спорит, тем более не сильно и отличаются Ваш class constStr от моего template<typename T, int len> class StringLiteral.

E>Принципиально отличается. У меня тип объекта не зависит от его значения...

template<typename T>
class StringLiteral
{
...
public:
    template<size_t l>
    StringLiteral(const T (&b)[l])
    {
        buf=b;
        len=l;
    }
    size_t size()
    {
        return len;
    }
    const T* c_str()
    {
        return buf;
    }
}

Это? Спасибо.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Более того, если бы Вы внимательно посмотрели на код, который сами же привели, то увидели бы, что копирование происходило, просто такой Вы подобрали пример, что скопировать надо 4 байта — 3 'a' и завершающий 0. Что как раз влезает в DWORD, который и скопировался.

Решение которое, надеюсь, вас устроит в ветке уже предложили.
Можно вариацию вроде:

#include <boost/tuple/tuple.hpp>

template<typename T, size_t N>
boost::tuple<T const*, size_t> static_length(T const (&a)[N])
{
 return boost::tuple<T const*, size_t>(a, N);
}

boost::tuple<char const*, size_t> x(static_length("abcd"));

__>>Вы плохого мнения о компиляторах.
__>>Компилятор умеет оптимизировать эту вещь и не делать настоящего копирования.

...
L>Я бы сказал, что я разумного о них мнения, и предпочел бы не расчитывать лишний раз на них. Это стандартные Release настройки VS2K5SP1.
...

Чтобы помочь компилятору в его сложной работе достаточно сделать выражение const char a[] = "aaa"; глобальным.
Никаких дополнительных расходов, один недостаток — область видимости вся единица трансляции.

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

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

L>>Более того, если бы Вы внимательно посмотрели на код, который сами же привели, то увидели бы, что копирование происходило, просто такой Вы подобрали пример, что скопировать надо 4 байта — 3 'a' и завершающий 0. Что как раз влезает в DWORD, который и скопировался.

__>Решение которое, надеюсь, вас устроит в ветке уже предложили.

Предложили даже 2 решения, сейчас занимался проверкой, что лучше по скорости. Проблема в том, что в некотором legacy коде, производительности которого не хватает на имеющемся железе буквально чуть-чуть, во внутренних циклах порядочно вызовов strlen от строковых литералов. Естественно, что появилась мысль их убрать за ненадобностью. Искался самый простой вариант.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>Чтобы помочь компилятору в его сложной работе достаточно сделать выражение const char a[] = "aaa"; глобальным.
MS>Никаких дополнительных расходов, один недостаток — область видимости вся единица трансляции.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Это? Спасибо.

Да. Всегда пожалуйста

Для "спасибо" есть кнопки

L>>Хм, как насчет того, что дублируются строки? А если они длинные?
Нефига они не дублируются, sizeof() вычисляется на этапе компиляции, это не вызов функции.

MS>#define STR_HELLO "Hello"
После обработки препроцессором это даст тотже самый sizeof("Hello")

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

L>>>Хм, как насчет того, что дублируются строки? А если они длинные?
LD>Нефига они не дублируются, sizeof() вычисляется на этапе компиляции, это не вызов функции.

Два строковых литерала запросто могут дважды оказаться в бинарнике. От компилятора, в общем, зависит. У VC опцией рулится.

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

L>>>Хм, как насчет того, что дублируются строки? А если они длинные?
LD>Нефига они не дублируются, sizeof() вычисляется на этапе компиляции, это не вызов функции.

Строки дублируются в исходном коде. Что иногда приводит к неприятным ошибкам.

...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>>>Хм, как насчет того, что дублируются строки? А если они длинные?
LD>>Нефига они не дублируются, sizeof() вычисляется на этапе компиляции, это не вызов функции.

S>Два строковых литерала запросто могут дважды оказаться в бинарнике. От компилятора, в общем, зависит. У VC опцией рулится.

Кстати, а зачем интересно могут понадобится 2 одинаковые строки в бинарнике? Ну, что проще спихать туда все, не сортируя, это понятно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Кстати, а зачем интересно могут понадобится 2 одинаковые строки в бинарнике? Ну, что проще спихать туда все, не сортируя, это понятно.

Тяжкое наследие С

L>>>Хм, как насчет того, что дублируются строки? А если они длинные?
LD>Нефига они не дублируются, sizeof() вычисляется на этапе компиляции, это не вызов функции.

MS>>#define STR_HELLO "Hello"
LD>После обработки препроцессором это даст тотже самый sizeof("Hello")

Приведенное решение упрощало работу с длинными запись

f( "VeryLongVeryLongVeryLongVeryLongVeryLongVeryLongString", sizeof("VeryLongVeryLongVeryLongVeryLongVeryLongVeryLongString")-1 );

до такой

#define STR_HELLO "VeryLongVeryLongVeryLongVeryLongVeryLongVeryLongString"
f( STR_HELLO, sizeof(STR_HELLO)-1 );

По сгенеренному коду два примера будут одинаковые
Никакого лишнего overhead'а ни при каких опциях компиляции.

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

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

L>>Кстати, а зачем интересно могут понадобится 2 одинаковые строки в бинарнике? Ну, что проще спихать туда все, не сортируя, это понятно.

E>Тяжкое наследие С

А поподробней в этом месте, пожалуйста.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

	От:	_nn_
	Дата:	29.11.07 21:19
	Оценка:

	От:	Erop
	Дата:	30.11.07 00:31
	Оценка:

	От:	Erop
	Дата:	30.11.07 00:33
	Оценка:

	От:	lifrsdn
	Дата:	30.11.07 15:05
	Оценка:	+2

	От:	lifrsdn
	Дата:	30.11.07 15:05
	Оценка:

	От:	MShura
	Дата:	01.12.07 10:50
	Оценка: