Как вернуть вектор из функции c

Как вернуть вектор strx из функции

Мне надо чтоб два потока параллельно шли

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

По сути, для заданного искусственно созданного вектора «данных» для data [i] = i мне нужна функция, которая умножает каждый элемент вектора на 2, а затем выводит результат. Тем не менее, я не могу понять, что я сделал не так.

Решение

function возвращает std::vector который является своего рода контейнером. И мы не можем использовать std::cout распечатать элементы std::vector ,
Мы должны пойти в контейнер, чтобы получить элементы и распечатать их.
Как это:

Другие решения

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

Помните, если функция берет объект из обобщенного класса (такого как std :: vector ), вам нужно указать, что это шаблонная функция.

Теперь вернемся к вашему вопросу. Я предполагаю, что вы не хотите менять значения data сам, потому что вы объявили data2 ,

Тогда у вас есть два варианта (если я понимаю проблему, которую вы пытаетесь решить).

Первый вариант — написать функцию, которая возвращает вектор.

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

Конечно, если вы просто хотите распечатать дважды значение всех записей в векторе, вы можете просто использовать функцию:

Это может быть много нового для вас, так как вы, кажется, плохо знакомы с c ++. Я предлагаю прочитать через этот Веб-сайт.

Читайте также:  Виджет двойные часы для андроид

Вы также можете использовать станд :: копия алгоритм для этой перегрузки или использовать его прямо так:

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

Есть функция, создающая каким-то определенным образом экземпляр vector . Вопрос: как вернуть этот экземпляр вызывающему?

Правильное с точки зрения логики и стройности программы решение выглядит так:

Тут экземпляр вектора возвращается по значению, что означает потенциальное глубокое копирование локального объекта в контекст вызывающей функции. Сразу возникает сомнение: а что, если вектор огромен — его ж надо будет побайтно перекладывать из одного места в другое? Гораздо «разумнее» было бы написать:

Тут вектор передается по указателю, и стопроцентно ненужного полного копирования не будет. Но такой код выглядит откровенно плохо.

Сравним скорости работы на векторе длиной 100MB. Например, на компиляторе:

Теперь по указателю:

Время в обоих случаях одинаково. Получается, что стоит выбрать первый, «красивый» вариант.

Объяснений тут два. Первый, и возможно самый важный — это RVO, Return value optimization. Это когда компилятор догадывается, что создаваемый локальный экземпляр вектора предназначен для возврата из функции, и сразу создает его в контексте вызывающего кода, чтобы потом не копировать туда. Фактически компилятор реализует передачу по ссылке, но неявно, не портя красоту исходного кода. Данный трюк будет работать для любого класса, не обязательно класса из STL.

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

Читайте также:  Два одинаковых тонких проволочных кольца радиусом r

Ну а в контексте C++11, где есть семантика перемещения, вообще не будет лишних копирований, если класс «правильно» реализован (что верно для классов из STL).

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