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

Цитата Бобёр @ 05.01.12, 21:04

Почему же нема, стек то вытащить можно.

Можно, если не SEH, хотя уже после поста Qraizer, и это не помеха... Опыта мало с этим. Я на своем веку гдето раза 3 только встречался с всякими косяками в релизе или только на Win7... Еще руку не набил.

Цитата Бобёр @ 05.01.12, 21:04

Ну, как бы 99% пользователям винды это нафиг не надо.

Ну это да... Но о разработчиках могли бы подумать, хотя это комерция, левое бабло, кто придумает круче дампер

Добавлено 05.01.12, 21:14

Цитата KILLER @ 05.01.12, 21:12

кто придумает круче дампер

Вона на codeproject валяюца всякие StackWalker ... кстати ниче, помог тоже один раз

map - это полная карта исполняемого модуля. Что, где, как называется итп.

Добавлено 05.01.12, 22:36
Естественно там будут только публичные имена. Точнее, имена с внешним связыванием. Всякие там глобальные static отсутстуют.

А на счет адресов, если кто то на другой тачке компилил - они такие же? я чето сомневаюсь както...

Добавлено 05.01.12, 22:46

Цитата Qraizer @ 05.01.12, 22:35

map - это полная карта исполняемого модуля. Что, где, как называется итп.

Ну в юниксе - это так, да , в msvs, я помню что делал такой файл зачем то, но не помню такой же он как в юниксе? Я уже понял что такойже...

Для COFF-формата там виртуальные адреса, RVA. Поэтому они, отображаясь в собственное адресное пространство процесса, отличаться могут разве что для DLL. С ними могут быть определённые проблемы, надо знать настоящий адрес загрузки. Но это легко преодолимо - а под XP и ниже ещё и настоятельно рекомендуемо - явным указанием линкеру базовых адресов загрузки DLLs (разумеется, если они не разделяются разными процессами, в этом случае ремапить надо с учётом всех заинтересованных сторон), подбирая их регионы непересекающимися. Для этого и тулзы есть простые, ещё со времён Win9x, они даже уже готовые DLLки умеют вот так вот поредактровать.

Собственно, можно в релизе получить map с подробным описанием, по какому адресу какая строка начинается (в объектник надо сгенерить номера строк). В бинарнике даже следов этой информации не будет, а в map можно записать (с учетом возможности перемещаемой загрузки)

Цитата Qraizer @ 29.12.11, 22:22

Та не. Это всё std::vector<bool> виноват. Скорее для вектора надо было бы через итераторы.

Слабо верится. Потому что vector<bool> - это, всё-таки, вектор, а не string. Хотя, возможно, дело в том, что символы в строке могут быть переменной длины. Но тогда это не удовлетворяет требованию константной сложности операции...

Не, символы в строке не могут быть переменной длины, это в массиве символов могут.
Если серьёзно и без тролльства, то это не имеет отношения к константности операций. Ну будет время обработки UTF-8 строк чуток выше, нежели UTF-32, оно ж всё равно константное.

Интересно, а можно ли в указанных языках реализовать динамические переменные? А ля

var CONTEXT : Int
 
procedure p ()
  CONTEXT++
  printf( "%d\n", CONTEXT )
end
 
procedure p_Test ()
  var c : Int,
      s : String
  with CONTEXT = 0,
       STDOUT  = new StringOutputStream() do
    p()
    c =  CONTEXT
    s = (STDOUT as StringOutputStream).getString()
  end
  printf( "-- %d, %s\n", c, s )
end
 
CONTEXT = 3
printf( "%d\n", CONTEXT )
p_Test()
printf( "%d\n", CONTEXT )

=>

3
-- 1, "1\n"
3

Ничего не понял

Еще вопрос знатокам C#: я тут понатыкался на инфу, что обычный цикл for в большинстве случаев (массивы, числовые диапазоны) показывает заметно лучшую производительность, нежели foreach, так ли это и если да, то почему?

Добавлено 22.01.12, 21:56

Цитата D_KEY @ 22.01.12, 21:41

Ничего не понял

Эм... ну смотри, в блоке with происходит создание новых биндингов для (глобальных) переменных CONTEXT и STDOUT(ее я не объявлял, т.к. она типа искаробки), поэтому при вызове p внутри этого блока она использует эти новые биндинги, т.е. если бы было просто

    var CONTEXT : Int
    
    procedure p ()
      CONTEXT++
      printf( "%d\n", CONTEXT )
    end
    
    procedure p_Test ()
      var c : Int,
          s : String
      CONTEXT = 0 // это изменит глобальное значение
      STDOUT  = new StringOutputStream() // тоже изменит глобальное значение
      p()
      c =  CONTEXT
      s = (STDOUT as StringOutputStream).getString()
      // теперь нужно бы восстановить как было
      // CONTEX = ? // блин, забыл сохранить предыдущее значение
      // STDOUT = ? // и теперь
      printf( "-- %d, %s\n", c, s ) // упс, а печатаем-то мы в строку, а не системный поток
      // ну о потокобезопасности не забыть бы
    end

Соответственно и вывод будет совсем другим.

Цитата korvin @ 22.01.12, 20:17

Интересно, а можно ли в указанных языках реализовать динамические переменные? А ля

Цитата korvin @ 22.01.12, 21:46

Эм... ну смотри, в блоке with происходит создание новых биндингов для (глобальных) переменных CONTEXT и STDOUT(ее я не объявлял, т.к. она типа искаробки), поэтому при вызове p внутри этого блока она использует эти новые биндинги, т.е. если бы было просто

Есть-есть. Нужно просто объявить локальную переменную с тем же именем.

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

Сообщение отредактировано: D_KEY - 22.01.12, 22:11

Цитата Повстанець @ 22.01.12, 21:59

Есть-есть. Нужно просто объявить локальную переменную с тем же именем.

ORLY?

#include <iostream>
 
int CONTEXT;
 
void p () {
    CONTEXT++;
}
 
void p_Test () {
    int CONTEXT = 0;
    p();
    std::cout << CONTEXT << std::endl;
}
 
int main () {
    CONTEXT = 3;
    std::cout << CONTEXT << std::endl;
    p_Test();
    std::cout << CONTEXT << std::endl;
    return 0;
}

=>

3
0
4

а должно быть (в случае динамических переменных)

3
1
3

Добавлено 22.01.12, 22:14

Цитата D_KEY @ 22.01.12, 22:11

korvin, вообще-то это обычная лексическая область видимости.

Вообще-то динамическая.

korvin, сделай p через #define

Цитата D_KEY @ 22.01.12, 22:15

korvin, сделай p через #define

Хорошая шутка, спасибо, посмеялся.