Передать массив из функцииГрубо говоря массив a был создан в стеке, когда произошел выход из функции стек свернулся и сооветсвенно объект вместе с ним уничтожился и на его месте уже может лежать мусор(а может и не лежать тут уже как карта ляжет), поэтому как тут правильно заметили память нужно выделить динамически, или же вопользоватся STL типами, которые сделают всю работу за нас
Здравствуйте, art_kuz, Вы писали:
_>супер си-шный вариант
Думаешь, такое будет быстрее?
typedef std::array<long, 200> myarray;
myarray myfunc(long* b)
{
myarray a;
for (int i=0;i<200;i++)
a[i]=b[i];
return a;
}
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, s.ts, Вы писали:
ST>сразу скажу, что мы говорим, конечно, про "pure c". ST>и тут скорее проще поставить вопрос иначе: какие плюсы у других реализаций ? ST>ответ: только реентерабельность.
Еще и удешевление сопровождения кода. Ужасное количество С кода написано в таком стиле, и для переиспользование приходится передалывать. Код Васи Пупкина можно и не рессматривать, взять старндатную библиотеку С — фукнции вроде gmtime сейчас стали не юзабельны. gmtime_r, или gmtime_s есть не везде. Что далеть то с такими хорошими решениями? Делают даже такие костыли как по отдельному процессу вместо каждого потока
И это еще простая ситуация, когда о проблеме с нереентерабельностью функций заранее известно, а бывает что о таких статиках выясняют после длительного дебага, когда ошибка трудновоспроизводима
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, dabeat_bf, Вы писали:
_>Здравствуйте, monax, Вы писали: M>>Нельзя так делать, это глобальная переменная получится.
_>явно не глобальная.
Давайте-ка разберемся с тем, что такое "глобальная переменная", потому как ни в C, ни в C++ языках нет такого понятия. А в место этого есть набор свойств, которыми можно характеризовать любую переменную:
Область видимости (Scope) — local, function prototype, function, file (C), namespace (C++), class (C++);
Класс памяти (Storage Duration) — static, automatic, dynamic;
Тип связывания (Linkage) — external, internal, no linkage.
В данном случае, массив, объявленный в теле функции с ключевым словом static, является объектом с локальной областью видимости (local scope), статическим классом памяти (static storage duration), без связывания (no linkage).
Теперь давайте решим, какие характеристики являются существенными для нас в данном случае, а какие не очень. По-моему, область видимости и тип связывания нашего массива в данном случае не имеют принципиального значения. А вот область памяти, в которой он расположен, является важной характеристикой. Взвесим все "за" и "против".
Преимущества:
Не нужно выделять и заботиться об освобождении памяти.
И все.
Недостатки:
Не определенность времени жизни. Точнее — его окончания в данном случае;
Проблема многопоточного использования;
Проблема реентерабельного использования.
С учетом того, что единственное достоинство такого подхода можно достичь массой других способов, ИМХО, вывод в данном случае напрашивается сам собой — это не тот случай, когда использование объектов со статическим временем жизни оправдан.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Аноним, Вы писали:
А>Привет, необходимо передать массив заданный в функции: А>int* myfunc(int *b) А>{ А>int i; А>long a[200];
А>for (i=0;i<200;i++) А>a[i]=b[i]; А>return a; А>} А>Подскажите, почему возвращаются только первые несколько элементов, как исправить? Заранее спасибо.
a — это всего лишь указатель на long, а не массив. Вы пытаетесь вернуть локальный массив, т.е. такой память для которого выделяется при входе в функцию и удаляется при выходе из неё. Поэтому нет никакой гарантии, что по указателю, возвращённому из функции находится то, что нужно. Там может находиться всё что угодно!
Для того чтобы решить проблему можно:
1) зарезервировать память под массив в вызывающей функции, а в функцию myfunc передать уназатель на него:
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, s.ts, Вы писали:
ST>>сразу скажу, что мы говорим, конечно, про "pure c". ST>>и тут скорее проще поставить вопрос иначе: какие плюсы у других реализаций ? ST>>ответ: только реентерабельность.
GN>Еще и удешевление сопровождения кода. Ужасное количество С кода написано в таком стиле, и для переиспользование приходится передалывать. Код Васи Пупкина можно и не рессматривать, взять старндатную библиотеку С — фукнции вроде gmtime сейчас стали не юзабельны. gmtime_r, или gmtime_s есть не везде. Что далеть то с такими хорошими решениями? Делают даже такие костыли как по отдельному процессу вместо каждого потока
GN>И это еще простая ситуация, когда о проблеме с нереентерабельностью функций заранее известно, а бывает что о таких статиках выясняют после длительного дебага, когда ошибка трудновоспроизводима
ты не то удалил/оставил для ответа
а то потом выясняется, что "из всех искусств для нас важнейшим является кино"(c)
если смотреть мой мессадж целиком, то:
сразу скажу, что мы говорим, конечно, про "pure c".
и тут скорее проще поставить вопрос иначе: какие плюсы у других реализаций ?
ответ: только реентерабельность.
т.е. если нет многопоточных вызовов, то static — это хорошее решение.
реентерабельное решение в чистом си сразу влечет дополнительные сложности реализации и использования.
потому многие чисто сишные функции именно так и реализованы — через static.
как-то так.
Здравствуйте, s.ts, Вы писали:
ST>ты не то удалил/оставил для ответа
Я удалил несущественное. Если сейчас "нет многопоточных вызовов", то завтра они появятся, и решение окажется негодным — поэтому поддержка кода и увеличивается в цене.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth