Здесь создается новая переменная и pDst в нее копируется. Лучше инкрементировать саму pDst, ради этого стоит сделать ее char* и каждый раз при обращении писать преобразование типа. А если компилятор (вопреки стандарту) позволяет инкремент void* то можно оставить ее и void*

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

size потерялся где-то. Вероятно нужен еще sizeof(T)

Если уж нас заботит экономия кода, то с шаблошами лучше не связываться...

Да это всё понятно:-) Я ждал какого-то мегаоткровения, а тут... :-) Так и не понял, где здесь обещанные преимущества языка высокого уровня, по сравнению, скажем, с вариантом от Редчука. Контроль типов - на программисте как был, так и остался, арифметика с указателями - как была, так и осталась. Зато столько пафоса...

Ваш, Сергей, вариант с шаблонами по крайней мере переносит часть контроля типов на компилятор.

Если нас заботит экономия кода, то любой иснтрумент надо применять аккуртано. Многие монстроидальные результаты нынешнего софтостроения связаны не с примененеим С++ вообще или шаболнов в частности, а с бездумным "оттянул-уронил".
Я бы, может, и не влез, если бы не эта последняя фраза, которую я процитировал первой.

Никто ничего нового не создаёт.
К моменту использования нового указателя старый уже никому не нужен. Как следствие, его можно "выбросить", а регистры использовать по новой. Чудесным образом, в них уже есть нужное значение и ничего никуда копировать вообще не нужно (ну, за исключением копирования указателя из регистров передачи параметра в указательный регистр, у MSP430 и ARM не было бы и этого).
"Найдите десять отличий"

Я нашёл только одно - в порядке копирования аргументов на новые места (впрочем, size можно было и не копировать, но это не имеет отношения к преобразованибю типов и "созданиб нового указателя").

Вернёмся. Для более правдоподобного сравнивания я в каждом варианте прочту каждый вид переменной по нескольку раз.
Чистый С, "без никаких латинских примесей"





Гадкие, противные, местожрущие шаблоны.



Итого вариант с шаблонами версии "если хочеться экономить код" дал выигрыш в 3 слова программной памяти (лишний rjmp в функции read C-шного варианта не считаем) . Или, на этом участке, около 5%.
Обратите внимание - "проигрыш" шаблонов в сгенерированных при специализации шаблона функциях (9 слов), а выигрыш - при каждом применении шаблонного чтения (1 слово, тут 12 применений, 3 слова выигрыша). И чем больше будет чтений, тем больше будет выигрыш.
"догнать" на С можно, заведя самостоятельно функции и производя "закат солнца вручную".
Перегнать не выйдет.

Эту проверку можно сделать перед вызовом функции, когда принимается решение - в какую переменную читать. Ведь проверка все равно нужна, а код цикла do {} while(--size) будет короче чем while(size--) {} и в байтах кода и в тактах.
Да, конечно. надо было еще добавить uint8_t size = sizeof(T);
Ну а про шаблоны ReAl все изложил с фактами наперевес. Добавлю лишь, что можно добиться на выходе точно такого же кода, как и в С-варианте, если сделать шаблонную функцию inline. А преимущество будет в том, что не ошибешься, указав имя одной переменной а sizeof другой. Пусть рутину выполняет компилятор.

unsigned long int a[] = {1, 2, 3, 4, 5};
unsigned long int b[5];

unsigned long * ptr = a;

b[0] = (*ptr)++; // или же м.б. b[0] = *ptr++; или b[0] = *(ptr++); Что Вы хотите - Вам виднее.
b[1] = *ptr++;
PS. Все современные языки борются с указателями неявного типа. Это источник глюков.




И я о том же.


Наверное, для науки надо (как делать не надо).

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

а при чем тут макрос? Ничего общего с шаблоном у него нет.

Я извиняюсь, но это сделано не для "более правдоподобного сравнивания", а для того, чтобы вариант с шаблонами оказался короче Достаточно оставить 5 чтений вместо 6 - и результат резко меняется. Но и с шестью чтениями, стоит добавить еще один тип данных - и он вновь окажется длинее за счет появления еще одной инстанцированной функции.

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

Сообщение отредактировал 777777 - May 7 2008, 11:47

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

А я разве сказал, что у него есть что-то общее с шаблоном?
С ним чисто С-шный текст быстрее пишется и меньше шансов ошибиться, подсунув не тот sizeof. Вот и всё.


Зависит от построения программы, конечно, но если Вам более правдоподобными кажутся программы, в которых из потока вынимается в одном единственном месте по одной единственной переменной каждого типа, то да, в Вашем случае шаблоны проиграют. В случае данной платформы - по два слова программной памяти на каждом типе. Это, безусловно, катастрофическая величина, позволяющая говорить "если важен размер, с шаблонами лучше не связываться".
Уже при трёх чтениях переменной каждого типа шаблонный вариант не проигрывает.
На вполне вероятных количествах чтений 4 и больше - выигрывает. Выигрывает не столько, чтобы плясать от радости, но я только хотел показать, что "слухи о безусловной вредности шаблонов для комплекции программы несколько преувеличены", при количествах чтений от 1 до 5 на тип - 50/50. И даже в случае проигрыша - он чепуховый.

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

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