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

В общем случае да, согласен, лучше через указатель.
Но существуют и частные случаи, в том числе возврат типа div_t или ldiv_t в функциях div и ldiv соответственно. (Интересно, как эти функции реализованы в CV?)
Случай, приведенный в первом сообщении автора, можно с натяжкой отнести к частным.

Разве?
Итак, чтобы использовать структуру в качестве результата функции, нам в общем случае нужны 3 структуры:
1. Локальная в вызываемой функции. Она заполняется этой функцией и затем её имя используется в операторе return;
2. Неявная переменная на стеке, в которой и будет возвращен результат.
3. Локальная или глобальная переменная в вызывающей функции, которой будет присвоен результат вызова.

Разместить все 3 переменные по одному адресу можно только при очень удачном стечении обстоятельств. При запуске простейшего тестового примера на IAR EWARM 4.41A этого не получилось - компилятор совместил только переменные 1 и 2, достигнув всего лишь двойного, а не тройного расхода памяти. Оптимизация -s9.

Main.cpp:


func.cpp


После компиляции:
для main имею:

для func.cpp


Если же TTest - небольшая, то получится что-то вроде:


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

И помоему нет ни одной разумной причины не реализовать возврат структур в компиляторе, если это есть в стандарте языка.

У меня IAR 4.30

Я прошу участников дискуссии не забывать о прозрачности исходных текств в погоне на экономией одного-двух-трех байт. Кроме того, структура имеет размер немного больший, чем размер скалярной переменной, но и не такой уж большой, что бы уже задумываться о передаче указателей. Т.е. это "пограничный" случай для выбора того или иного решения. Неоднозначности здесь много.

Я посмотрел ИАРовский листинг. Там структура тоже возвращается неявно. Все правильно, так и должно быть. Опрератор return копирует данные локальной стуктуры по адресу, который пришел в функцию неявно. Т.е. код



в ассемблерном исполнении выглядит как



Т.е. компилятор выполнил "черную" работу, а мы имеем читабельность и легкое понимание исходников.
К тому же работа с локальной переменной и возврат ее из GetMessage также выглядят по-человечески:



Заумные тексты программ это не есть высокий уровень профессионализма.

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

Или я не прав?

А где тут прозрачность страдает? Или что вы подразумеваете под прозрачностью?


Вариант с указателем проигрывает (на AVR) только для размера структуры, меньшего размера указателя. В остальных случаях он или не хуже, или лучше.


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

Прозрачность начинает уменьшаться с появлением звездочек и амперсендов.
Например, в Васике нет этого, поэтому тексты программ на нем более прозрачны, чем на Си. Только не надо передергивать, а то уйдем в бессмысленное словоблудие. (Я, к стати, не адепт Васика.)
Понятно, что без указателей будет язык -- неязык. Но там где можно обойтись без указателей, зачем их пихать почем зря? Вообще-то речь идет о том, что моя структура могла бы легко быть возвращена по значению даже в регистрах, но компилятор не предоставил такой возможности вообще!


Причем здесь AVR? Это у любой платформы.


Ага. По-моему, мы говорим об одном и том же, а такое чувство, что стоим по разные стороны.

Не хочется звездочек и амперсандов, можно использовать ссылки. Это, правда, уже ++ная фича, но большинство доступных компиляторов это умеет без вопросов. Там, правда, тоже есть амперсанд, но только в определении функции, что, имхо, прозрачности не убавляет:



Тут уж все однозначно. Хотя синтаксис немного другой.

Ну так создайте тип - "указатель на структуру" и перестаньте использовать звездочки:



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


или динамическое выделение памяти:


Можно heap_alloc вставить прямо внутрь GetMessage поменяв функцию так:



и пользовать так

я там где-то ранее обещал опубликовать результаты перенеса кода из CV в IAR.

Ну что сказать? Код перешел легко и непринужденно. Изменения произошли только в вызовах прерываний (немного другой синтаксис) и в переменных типа bit. Последние я тупо заменил на BYTE, их немного, штук пять, поэтому практически они ни на что не лияют.

Попутно, что мне понравилось, так это когда IAR указал варнингами на мои ошибки. Самая страшная, это когда беззнаковой переменной я присваивал минус единицу. CV просто проглатывал.

Иногда, там, где действительно есть ошибки и он CV видит их, он дает не совсем корректную диагностику. Этого мало, он может отправить вас вообще не туда, где лежит ошибка =8-[

Да много чего хорошего можно сказать про IAR против CV. Только мне хотелось бы озвучить результаты.

Размер флешь-кода, полученного в CV составляет 4030 слов (или 8060 байт). У IAR код получился размером 7086 байт. Могу сказать только то, что в IAR была устновлена максимальная оптимизация.
(К стати, в текстах для IAR, и в текстах для CV (т.е. -- везде) я заменил bit на BYTE.)

Но вот есть еще один, неприятный для CV факт. У меня в коде присутствует кусок размером 1536 байт, который является растром шрифта. По идее это кусок надо бы вычесть из размера флешь-кода, поскольку это не команды. Т.е. соотношение откомпилированного кода явно в пользу IAR.

Но самое забавное, что я вошел в азарт и перенес в IAR старый проект для tiny2313. Там CV создал код в 890 слов (1980 байт), а вот IAR перестарался -- 2012 байт. До кучи, IAR не смог создать отладочную версию, т.к. вылелел за 2048 байт.

Выводы делать не буду, комментировать цифры тоже. "Исходники в студию не принесу", авторство, разумеется, -- мое, но вот исходники (собственность) принадлежат фирме.

12-ти %-ная разница в объёме сгенерировнного кода. Компиляторы равны в своих прямых функциях - генерации кода. Разница между ними только в IDE.