Есть код:

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

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

И тишина...
Где же вы, гении программистской мысли?
Проблема еще частично актуальна.
Методом тыка удалось выяснить, что сбой возникает только при вызове виртуальных функций.
Видимо, вся виртуальность идет прахом, когда не используется 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 не детерминировано, сиречь может изменится в любой версии любого компилятора.

Вот очень занятная статья на эту тему

Чупакабро, т.е Вы решили, что отказавшись от new, Вы отказываетесь от CRT? Я Вам может открою тайну, но прежде чем начнёт исполнятся первая же строчка функции main CRT уже используется на всю катушку. 

Entry Point находится у меня в программе, я немного подшаманил, если вы об этом))

CRT это не только new/delete. Это ещё и 'scalar deleting destructor', 'vector deleting destructor' и собственно тот самый _vftable. Без CRT не выйдет сделать виртуальное наследование. Если уж так не хочется использовать new то можно так:

Да да да! Я так пробовал, см. предыдущую страницу. Работает.

тем не менее это UB

А как это переводится? )))

undefined behavior. В C++ нет решения Вашей проблемы без new. Всё что здесь предлагается в качестве решения является некорректным C++ кодом.

vinter
ну что ж, начнет глючить - придется отказаться от ООП. Пока работает.

Похоже я соврал . Таки можно, главное отключить RTTI и перегрузить operator delete. 

Это сообщение отредактировал(а) DarthTon - 16.10.2013, 12:06

Оно может начать глючить так, что Вы проблему месяц будете искать. А если начнёт у клиента, то там вообще будет песня. Отлаживать программу полную UB будет очень весело. А самое то главное, зачем? Неужели сложно писать на чистом C? Коли уж Вы не можете какой-нибудь установщик осилить(WiX, к примеру)
Ну и напоследок. ООП это не классы, ООП возможен и в чистом C. Классы лишь удобная сущность для реализации ООП подхода, не более того. Поэтому наличие классов в программе не делает её ОО, равно как и их отсутствие не говорит об отсутствии ОО подхода при её написании.

Это довольно распространённая проблема)))
Если не хотите таскать с собой свой вариант этой dll, то можно попробовать воспользоваться следующим советом:
(для C++ проектов я не пробовал; взято отсюда).

зачем огород городить? можно линковать со статическими библиотеками
http://msdn.microsoft.com/ru-ru/library/2kzt1wy3.aspx

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

любой установщик, конечно, использует crt. как же они это делают...   

Кстати да, если у Вас практически нет вызовов CRT, то размер экзешника при этом увеличится незначительно.

Я тебя не понял. Я имел ввиду распространение CRT вместе с исполняемым файлом. А еще лучше установка MSVC redistributable вместе со своим софтом. Это как раз нормальный путь распространения.

Между new и placement new есть разница. Placement new это вот это -
Где тут run-time? Не хотите зависить от хидеров VS - напишите его (placement new) прямо у себя в хидере


Это поддержка exception handling. Отключите его в настройках проекта (и поддержку RTTI тоже)

я намекнул ТС'у что проблема решаема (например авторами инсталляторов) без отказа от crt

Пардон, погорячился. Осеннее обострение.
Ну вот если бы сразу сказали, что placement new не требует рантайма... то и флуда было бы на 2 страницы меньше. ))
В общем проверил, работает. Немного увеличился размер экзешника, но не смертельно.

Как? Таскают рантайм с собой? Линкуются статически? Используют msvcrt.dll, который есть во всех Windows?

читайте больше. лучше - книжки, а не на заборах

Мучаю Шилдта. Но таких тонкостей там не описывается.
Так что, кроме сухой теории полезна практика + гугл + форумы.

Насчет статической линковки - если юзать CRT, то будет трудно уместить экзешник в 64К.
PS. И вроде как в последних студиях msvcrt.lib это просто обвязка для dll...

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

Так вот в чем дело.
Что же вы сразу не сказали?

VSB
Не знаю ))
А это меняет дело?

Ну, вам бы не навязывали использование CRT.
Это же демосцена, если я правильно понимаю?

Хуже - игра (правда, пока совсем в зачаточном состоянии).