Есть код:

Третья строка выдает ошибку доступа к памяти.
Если объект создавать так:

то все работает (кто бы сомневался).
Я вот понимаю, что для создания объекта недостаточно просто выделить под него память...
но что еще нужно-то сделать?

И тишина...
Где же вы, гении программистской мысли?
Проблема еще частично актуальна.
Методом тыка удалось выяснить, что сбой возникает только при вызове виртуальных функций.
Видимо, вся виртуальность идет прахом, когда не используется new, и программа не может получить фактический адрес функции.
ыыыыыыыыыыыыыыыы..... ладно, гутен морган, пора спать

Это сообщение отредактировал(а) Чупакабро - 15.10.2013, 23:42

Ну, загляните сюда на предмет Placement new...

Довольно любопытно почему таки падает. Единственное что приходит в голову это перегруженный оператор присваивания. 

Alexeis, падает потомучто UB во второй строчке: *(pTerrains[x * 3 + y]). Это есть разыменование невалидного указателя; всё, что идёт дальше значения не имеет. feodorv дал автору темы абсолютно верный ответ, который исчерпывает вопрос.

Это сообщение отредактировал(а) vinter - 16.10.2013, 09:43

Спасибо, почитал, но это немножко не то. Там рассказывается, как разместить объект по заранее известному адресу. Но у меня такой задачи нет. Задача в том, чтобы отказаться от использования рантайма студии (msvcrt.lib / msvcrt.dll) и, в частности, от new.


В итоге, полазив по интернетам, нашел, в чем проблема.
Для каждого экземпляра класса с виртуальными функциями создается скрытый указатель на таблицу виртуальных функций. При том способе, который использую я, такого указателя не создается (или он создается, но туда записывается нулевой адрес).
В качестве решения нужно явно указывать версию используемой функции:


Добавлено через 3 минуты и 21 секунду

Как же тогда правильно вызывать конструктор?

feodorv привёл правильные ссылки.

Это сообщение отредактировал(а) vinter - 16.10.2013, 09:55

Да чего тогда огород городить:

Я бы так и сделал, но
мне нужно сделать создание объекта без использования new
как мне еще это выделить, чтобы заметили?

Это сообщение отредактировал(а) Чупакабро - 16.10.2013, 10:03

  Возможно оператор копирования, не копирует адрес VMT. Вообще да, логично. Представим себе ситуацию что справа у нас объект не того же самого класса, а его наследник приведенный к нашему классу и разыменованный. В этом случае объект слева от знака равно получил бы указатель на VMT наследника, что несомненно является неверным поведением. Поэтому оператор копирования не трогает указатель на VMT и у объекта остается его родной не инициализированный указатель.
  Присоединяюсь к vinter и feodorv. Именно так следует действовать когда размещение объекта не стандартное.

Добавлено через 1 минуту и 58 секунд
Чупакабро, new это вызов конструктора + выделение памяти. Если выделение памяти заменить на свое, то new будет делать лишь вызов конструктора. Именно это и нужно сделать в данной ситуации. Ну или же самому записать указатель на VMT в объект. Это вполне реально если знать его смещение относительно начала объекта.

Ок, поэкспериментирую. По идее, там нулевое смещение, как я вычитал.

Это невозможно в C++. Используйте другой язык.

Сначала:

Потом:

Тогда не используйте сложных класов, переходите на структуры, инициализируйте их явным образом, вместо виртуальных функций используйте указатели на функции, и, да, переходите на C   

Чем Вам msvcrt.lib / msvcrt.dll насолили? И, гм, разве try/catch не в рантайме?

  В этом конкретном объекте может. На самом деле зависит от иерархии объектов. Если первый же предок имеет VMT то первая VMT будет первым полем. При множественном наследовании будет несколько таблиц VMT и они будут размещены с различными смещениями.

эээ... даже не знаю, что на это сказать))


error LNK: Cannot find symbol '___CxxFrameHandler3'
походу в рантайме
рантайм насолил тем, что нужно а) обеспечить запуск приложения на чистой системе, в которой может не быть msvcrtXX от моей студии (поэтому отказываемся от dll),  б) минимизировать размер приложения (поэтому отказываемся от статической линковки).


В данной конкретной программе от виртуальных функций наверное откажусь. Хотя, как я понимаю, проблема с ними решаема.

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