Вопрос к программистам на C , Исходники ядра Linux

Ну, если ты враг народа, то давай писать макросами

Цитата linuxfan @ 27.07.06, 17:10

Разводишь меня чтоли? Там же не присваивание, а конструктор копирования. Такое можно (и нужно) оптимизировать. Ты мне соптимизируй a = b + c.

Не развожу. Что тебе запустить уже лдень да?? Так вот.. если лень, то скажу так.. конструктор копирования не выполняеться.. 3 раза выполняется конструктор по умолчанию и ВСЕ!

Цитата

Там же не присваивание, а конструктор копирования

обычно присваивание отличается от конструктора копирования только тем, что возвращает const A &.
И то это делать необязательно, а лишь для ситуаций, когда нам хочется писать a = b = c;

Добавлено 27.07.06, 17:29
(тфу ты блин, Неудачник опередил)

Цитата BugHunter @ 27.07.06, 17:29

обычно присваивание отличается от конструктора копирования только тем, что возвращает const A &.

у присвоения A& возвращается...
int a,b,c;
(a = b) = c;

Добавлено 27.07.06, 17:31
linuxfan
На вот тебе такой код.. а то подумаеш еще что там operator= вызовется..

class A
   {
   public:
      A() {std::cout << "def\n";}
      A(const A&) {std::cout << "copy\n";}
 
      A operator+ (const A&)
         {
         return A();
         }
      A& operator= (const A&)
         {
         std::cout << "=\n";
         return *this;
         }
   };
 
int main()
   {
   A a1,a2;
   A a3 = a1 + a2;
   }

Добавлено 27.07.06, 17:33

Цитата linuxfan @ 27.07.06, 17:10

Лень Или ты не веришь, что можно написать qsort макросом?

Верю. Но я бы не хотел пользоваться программой(тем более ОС) в которой сортировка делается при помощи макроса.
И более чем уверен что такое извращение в серъезных проектах не используют.

LuckLess, видимо ты меня не понимаешь: я тебе внушаю, что оверхед именно на копировании при '+' вызывается.

#include <iostream>
 
class A
{
    public:
        static bool silent;
        A() {if (!silent) std::cout << "def\n";}
        A(const A&) {if (!silent) std::cout << "copy\n";}
 
        const A operator+ (const A &arg)
        {
            A res;
            if (!silent) std::cout << "operator +\n";
            return res;
        }
        A& operator= (const A&) {
            if (!silent) std::cout << "operator = \n";
            return *this;
        }
};
 
bool A::silent = true;
 
int main()
{
    A a1,a2;
    A a3;
    A::silent = false;
    std::cout << "First pass\n";
    a3 = a1 + a2;
    std::cout << "Second pass\n";
    a3 = a1 + a2;
    return 0;
}

Вот результат от gcc:

First pass
def
operator +
operator =
Second pass
def
operator +
operator =

Вот тебе и оверхед: Два временных объекта, потому что operator + . Или ты думаешь, что написал изотерическое сложение гипотетического хрена с несуществующей редькой и доказал высокую эффективность C++?

Цитата LuckLess @ 27.07.06, 17:30

И более чем уверен что такое извращение в серъезных проектах не используют.

Конечно нет. Но ведь можно же.

Добавлено 27.07.06, 18:08
В серьезных проектах макросы иногда используют, чтобы избежать копипаста.

Цитата linuxfan @ 27.07.06, 18:07

Вот тебе и оверхед: Два временных объекта, потому что operator + .

подругому сделать нельзя никак. оверхеда тут нет, так как оверхед == лишнее действие, а тут лишнего ничего нет.
хочеш подругому - использую функции и ссылки или operator+=.

Добавлено 27.07.06, 18:22

Цитата linuxfan @ 27.07.06, 18:07

я тебе внушаю, что оверхед именно на копировании при '+' вызывается.

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

Цитата LuckLess @ 27.07.06, 18:21

Я тебе дал пример с копированием.

Ну пардон, если я некорректно выразился. Я-то имел ввиду именно присваивание при использовании бинарного оператора. Там оверхед в создании временного объекта для хранения результата операции. По уму бы хотелось так:

....
const A& operator +(const A& arg,A& res) {
   /* складываем как-нибудь *this и arg, помещая значение в res */
  return res;
}

Но такая запись добавляет дополнительных хлопот по возможной очистке предварительной результата, но избегает создания временного объекта. пусть бы лучше компилер озабачивался выбором res: либо временный объект, либо сразу lvalue для рядомстоящего присваивания.

Цитата linuxfan @ 27.07.06, 18:30

либо временный объект, либо сразу lvalue для рядомстоящего присваивания.

Он и возвращает сразу lvalue для рядом стоящего присваиваня.
и это присваивание это лвалуе использует.

да, для присвоения и operator+ есть незначительный оверхед.
но кто использует большие обхекты с operator+ в связке??
ну тут дело рук опять в общем

Ну так это один из провалов идеологии C++. Импиративная парадигма с A& sum(const A&,const A&,A&) тут гораздо оптимальнее.
Надо пример объектов, для которых такое поведение operator+ проблема? std::string. Там неспроста с прокси-объектами и подсчетом ссылок заморачивались. Без gc с памятью при таком поведении операторов один геморрой (скажем спасибо boost::shared_ptr )

Цитата linuxfan @ 27.07.06, 18:45

Ну так это один из провалов идеологии C++. Импиративная парадигма с A& sum(const A&,const A&,A&) тут гораздо оптимальнее.

никакой это не провал. для больших объектов это легко оптимизируется.
для маленьких незначительно. к примеру.

class BigObject
   {
   private:
      bool temp;
      std::vector<int> BigBuffer;
   public:
      BigObject () : temp(false){}
      BigObject operator+ (const BigObject& obj)
         {
         BigObject tempObj(obj);
         //тут сложение.
         tempObj.temp = true;
         return tempObj;
         }
      BigObject& operator= (BigObject& bf)
         {
         if (bf.temp)
            BigBuffer.swap (bf.BigBuffer);//очень быстро выполняется
         else
            BigBuffer.assign (bf.BigBuffer.begin(), bf.BigBuffer.end());//копирование данных
         }
   };

и вообще. давай уже покажи где оверхед в СРАВНЕНИИ с С!
покажи код(а не надуманный пример) на С который сложно написать на С++ не потеряв в производительности.

Добавлено 27.07.06, 18:58
вообще такого рода проблема - это не проблема С++ а проблема архитектуры в целом.
если бы возвращаемое значение передавалось не через регистр. а вместо этого в вункцию push-ился доп. параиетр с адремов того мета, куда надо вернуть значение, то былоб значительно оптимальней.

Цитата LuckLess @ 27.07.06, 18:53

в вункцию push-ился доп. параиетр с адремов того мета, куда надо вернуть значение, то былоб значительно оптимальней.

Именно так.
А пример сходу придумать сложно. Ведь в крайнем случае можно в C++ всегда написать точно так же как и в C. Или мы ограничиваемся чистым C++? Тогда прошу уточнить степень "чистоты"
Потому как есть некоторые нестандартизованные стандартом трюки (alloca, например -- в чистом C++ подобных вещей вообще нет), за счет которых "не совсем чистый" C может вырваться вперед.

Цитата linuxfan @ 27.07.06, 19:06

А пример сходу придумать сложно. Ведь в крайнем случае можно в C++ всегда написать точно так же как и в C.

Чистый С++ как и Чистый С(С99).
на С++ собстно будут использоватся STL и ООП в разумных ессесно пределах.
на С соответственно сруктурное программирование и сишная библиотека.

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

Ну давай поиграемся с COM

Навай WinAPI + Чистый язык.

Я не знаю ни COM ни WinAPI Меня кормит Linux