Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата Qraizer @ 23.01.12, 10:25

я просил представить в синтаксисе C++ границы этих скопов:

int x;
 
void f()
{
  int y = ++x;
  {
   int z = ++x;
   {
    int t = ++x;
   }
  }
}

И? Где? И почему?

Здесь только одна привязка для x.

Почему? Скопов же четыре.

Цитата Qraizer @ 23.01.12, 10:29

Почему? Скопов же четыре.

Потому, что ты их(биндинги) не создавал.

Естественно. Но они меня и не интерсуют, я их создам, когда придумаю, как. А я не придумаю, пока не пойму, как управлять его границами в C++-программе.

Сообщение отредактировано: Qraizer - 23.01.12, 10:35

Цитата Qraizer @ 23.01.12, 10:34

Естественно. Но они меня и не интерсуют, я их создам, когда придумаю, как. А я не придумаю, пока не пойму, как управлять его границами в C++-программе.

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

/*"специальная" переменная*/int x = 10;
 
void f()
{
    std::cout << x << std::endl; // здесь мы будем обращаться к тому x, что находится ближе всего в окружающих нас scope'ах по стеку вызовов
}
 
int g()
{
    // в текущем scope x ссылается на глобальную переменную со значением 10
    f(); // 10
    {
        /*биндинг специальной переменной*/int x = 20;
        // теперь x ссылается на локальную привязку
        f(); // 20
    }
    // сново ссылаемся на глобальный x
    f(); // 10
}

Сообщение отредактировано: D_KEY - 23.01.12, 10:43

Т.е. скоп - это обычные {}, что ли? Так бы и сказал сразу.
Теперь: правильно ли я понимаю, что { делает снимок глобальных переменных и помещает прежние значения в стек, а } восстанавливает из вершины стека их значения? При этом стеки ко всему прочему ещё и локальные в нитках.

Цитата Qraizer @ 23.01.12, 10:48

Т.е. скоп - это обычные {}, что ли? Так бы и сказал сразу.
Теперь: правильно ли я понимаю, что { делает снимок глобальных переменных и помещает прежние значения в стек, а } восстанавливает из вершины стека их значения? При этом стеки ко всему прочему ещё и локальные в нитках.

Ну типа того. Т.е. дубовая реализация - это словарь идентификатора нитки и "стека" значений переменной, при создании биндинга делаем push, при смерти биндинга - pop для "стека" переменной нитки.

Ы?

Сообщение отредактировано: korvin - 25.01.12, 22:42

Цитата korvin @ 25.01.12, 22:42

Ы?

Сейчас не могу смотреть подробно, но там вроде банальное нарушение ODR.
По-моему человек решил, что в С++ есть модули

Сообщение отредактировано: D_KEY - 25.01.12, 23:26

Цитата D_KEY @ 25.01.12, 23:22

Сейчас не могу смотреть подробно, но там вроде банальное нарушение ODR.

Угу.

korvin, а что ты хотел этим сказать?

Цитата D_KEY @ 26.01.12, 09:02

korvin, а что ты хотел этим сказать?

Скучно становится в холиварах, да?

Цитата KILLER @ 26.01.12, 09:25

Цитата D_KEY @ 26.01.12, 09:02

korvin, а что ты хотел этим сказать?

Скучно становится в холиварах, да?

Вообще все пропало...
Поговорить что ли об rvalue-ссылках и их аналогах в других языках... Можно, кстати, сравнить с тем же CL, где есть странные функции работы со списками, которые в целях оптимизации портят произвольным образом(зависимым от реализации) исходные списки во время получения результата, при этом если ты воспользовался исходным списком, то ССЗБ. При этом никакого способа что-либо проверить/гарантировать нет. В этом смысле, явная работа с временными объектами(в лиспе для них обычно такие фокусы и используют, как я понял), а так же std::move выглядят как-то интереснее.

Причем все еще сильно зависит от реализации CL:
gcl:

>(defparameter *list* (list 3 6 1 2))
 
*LIST*
 
>(sort *list* #'<)
 
(1 2 3 6)
 
>*list*
 
(3 6)

clisp:

[1]> (defparameter *list* (list 3 6 1 2))
*LIST*
[2]> (sort *list* #'<)
(1 2 3 6)
[3]> *list*
(1 2 3 6)

Цитата D_KEY @ 26.01.12, 10:00

Можно, кстати, сравнить с тем же CL, где есть странные функции работы со списками, которые в целях оптимизации портят произвольным образом(зависимым от реализации) исходные списки во время получения результата, при этом если ты потрудился прочитать стандарт, то ССЗБ.

FIXED

Добавлено 26.01.12, 10:21

Цитата D_KEY @ 26.01.12, 09:02

korvin, а что ты хотел этим сказать?

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

Сообщение отредактировано: korvin - 26.01.12, 10:23

Цитата korvin @ 26.01.12, 10:17

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

Так а причем тут С++ ? Если ты сам написал же:

Цитата korvin @ 26.01.12, 10:17

Можно, кстати, сравнить с тем же CL, где есть странные функции работы со списками, которые в целях оптимизации портят произвольным образом(зависимым от реализации) исходные списки во время получения результата, при этом если ты потрудился прочитать стандарт, то ССЗБ.

Примени эту фразу и к С++. Или чо, хочешь сказать что в Cl томже нельзя сделать вообще никакую логическую ошибку ?