Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > Функции, параметры, вопросы.

Автор: kalomboqt 27.12.2008, 21:19

Начну со следующего, мне была непонятна конструкция

Код


void openFile(const QString &fileName)

Заинтересовал параметр функции. Вроде как передается ссылка, но при этом константа, в итоге все равно изменять нельзя. Пришел к выводу, что это тоже самое было бы, если бы мы сделали параметр QString fileName, только памяти расходовалось бы больше. Правильны ли мои рассуждения, можете ли вы что-нибудь добавить?

Теперь далее, приняв за истину свои рассуждения начал писать свои функции. Например

Код


QString getVariables(const QString &str)
{
         QString result = str; // В итоге приходится всё равно создавать копию
         // ...
        // тут я что-то делаю с result
         //.....
         return result; // ну и возвращаю её
}

Вот и вопрос назрел. Мне так кажется, что я ерундой тут занимаюсь, нужно было объявлять параметром QString str, внутри функции колдовать уже над str и возвращать её же. Или всё-таки лучше использовать const?

Автор: pan2004 27.12.2008, 22:09

Цитата(kalomboqt @ 27.12.2008, 21:19

)

Правильны ли мои рассуждения, можете ли вы что-нибудь добавить?

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

Цитата(kalomboqt @ 27.12.2008, 21:19

)

QString result = str; // В итоге приходится всё равно создавать копию

А по другому нельзя сделать? И далеко не все функции требуют этого. Хотя да, возможно передача QString напрямую была бы тут лучше, но ненамного(затраты на создание и передачу указателя == ссылки ничто по сравнению с затратами на копирование строк). Хотя надо напомнить, что Qt использует здесь Copy on write алгоритм - строка будет скопирована только тогда, когда попытаешься изменить result

Автор: kalomboqt 27.12.2008, 22:35

Цитата(pan2004 @ 27.12.2008, 22:09)

Ну вот я и хотел узнать можно ли по другому сделать=) Для определенности пусть нужно будет сделать следующее: написать функцию, которая бы из строки формул получала строку переменных. Переменной является либо одна латинская буква, либо две латинские буквы, либо первая буква, вторая цифра (естественно код для это писать не нужно, это я так для полноты картины написал). Вот как бы ты поступил в такой ситуации? QString str? const QString &str? Или что-то совсем другое?)

Автор: ISergeyN 28.12.2008, 01:49

Цитата

void openFile(const QString &fileName)

здесь в функции посто запрещается изменять "fileName".
тоесть, в пример у тебя есть некий класс "Test"который содержит даные и тебе их надо передать в функцию но при етом нельзя изменить.

Код


#include <iostream>
using namespace std;

class Test
{
public:
    int x;
    int y;
};
void test(const Test &q)
{
    cout<<q.x<<endl
        <<q.y<<endl;
    //q.x = 10; // error
    //q.y = 4;  // error
}
int main()
{
    Test q;
    q.x = 1;
    q.y = 2;
    test(q);
    return 0;
}

Автор: mes 28.12.2008, 02:10

Цитата(kalomboqt @ 27.12.2008, 22:35

)

, которая бы из строки формул получала строку переменных

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

Автор: ParaPik 9.1.2009, 20:46

Случайно у кого-нибудь нет статейки по поводу составления функций такого плана:

Код


void (*set_new_handler(void(*)()))();

Что аналогично данной записи:

Код


typedef void (*new_handler)();
new_handler set_new_handler(new_handler);

Автор: Alek86 9.1.2009, 21:31

что именно интересует?
можно только сказать, что второй вариант предпочтительнее

Автор: ParaPik 10.1.2009, 12:20

Второй вариант безусловно предпочтительнее. Но как я читал, компилятор второй вариант переводит в первый. Ну, и я хотел бы научиться писать объявления функции в первом варианте.

Автор: vinter 10.1.2009, 13:03

Цитата(ParaPik @ 10.1.2009, 13:20

)

Но как я читал, компилятор второй вариант переводит в первый

никто никого не переводит, второй вариант является первым. typedef обьявляет алиасы, не более того.

Автор: ParaPik 10.1.2009, 22:09

По поводу перевода я прочитал в книге Дьюхэрста. Он между прочим написал 2 компилятора для C++. И стаж работы более 10 лет. Так что я не думаю, что он бред написал.

Автор: vinter 10.1.2009, 22:18

ParaPik, он так написал, чтобы понятней было.

Автор: ParaPik 11.1.2009, 09:27

Но тем не менее, откуда вообще взялась тогда эта запутанная конструкция?

Автор: ParaPik 15.1.2009, 22:33

Ну, если нет информации на мой вопрос, так и скажите. Что толку отмалчиваться?

Автор: pan2004 15.1.2009, 22:40

Цитата(ParaPik @ 11.1.2009, 09:27

)

откуда вообще взялась тогда эта запутанная конструкция

Что значит "откуда"? Взбрела она кому-то в голову, вот и взялась smile

Код


void (*set_new_handler(void(*)()))();

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

Код


typedef void (*new_handler)();
new_handler set_new_handler(new_handler);

Автор: ParaPik 16.1.2009, 16:29

А вот возьми и напиши в компиляторе. Я сам удивился, когда увидел результат.

Автор: UnrealMan 16.1.2009, 20:28

Цитата(pan2004 @ 15.1.2009, 22:40

)

и вообще, это не функция, а указатель на функцию

Это не функция и не указатель на функцию. Это объявление функции smile

Цитата(ParaPik @ 16.1.2009, 16:29

)

А вот возьми и напиши в компиляторе.

Боюсь, он не понял, чего ты от него хочешь smile

Автор: Rififi 17.1.2009, 00:10

ParaPik,
Ну, и я хотел бы научиться писать объявления функции в первом варианте.
мега-правило для разбора сложных выражений: http://www.kalinin.ru/programming/cpp/print_17_07_00.shtml

Автор: ParaPik 17.1.2009, 16:43

Сейчас сяду и буду разбираться с текстом с сайта, выложенного Rififi.

Автор: ParaPik 18.1.2009, 13:22

Все разобрался. Вот теперь все понятно.