Узнать указывает ли указатель

Не по теме:

Сообщение от abit каких таких компилируемых? ) не слышал чтобы подобные проблемы были скажем в haskell за окном на минутку уже 2013, а вы всё о указателях, allacator-ах, счётчиках ссылок, как в 70-х... пора уже доверить это аппаратуре, и boost'овские умные указатели, согласен хороший способ, но не идиальный

Вы ничего серьезнее хелловорлда не писали, видимо. Я вот сейчас пишу курсач на шарпе и просто задолбался уже с GC.
Теоретически, программист на с++ должен постоянно думать о работе с памятью, а GC его от этого полностью избавляет. На практике, из-за GC приходится постоянно думать о памяти.
Например, есть у меня класс длинных чисел(обертка над гмп, стандартный BigInteger из фреймворка тормозит безумно).
в плюсокоде я могу спокойно написать
Я буду уверен, что при c = a * b сработает move конструктор, ну или в с++03 просто сразу же вызовется деструктор для временного объекта.
Если же такое написать в шарпе, то приходится думать, а не создается ли при a * b временный объект, и если создается, то не слишком ли часто... Так как если он создается часто, то GC попросту не успевает проснуться и убрать память, и программа вылетает с OutOfMemoryException. Я так раз пять уже вляпался, каждый раз приходилось менять архитектуру и переписывать на быдлокод, не создающих временных объектов.
Еще я пытаюсь все вычисления проводить в кеше, но на практике особой пользы это не приносит, так как в программу постоянно врывается GC, который портит весь кеш. И в итоге все тормозит :(
В общем, для нетривиальных вычислений GC не подходит абсолютно.
P.S. Для меланхоличного энтерпрайза GC приемлем, тут не спорю.

Не по теме:

Сообщение от diagon не создается ли при a * b временный объект, и если создается, то не слишком ли часто.

Насколько я помню, в шарпах есть конструкция using ( ... ) {}, после которой точно вызывается Dispose(), а GC получает приказ удалить всё using ( здесь ) {}.
Алсо, нередко можно использовать ленивые вычисления.

Не по теме:

Сообщение от AnyOne697 после которой точно вызывается Dispose()

Ээ, она не связана с освобождением памяти. Хотя, в случае с моим MPZInteger можно перенести освобождение памяти из деструктора в Dispose, но тогда появится множество утечек, потому что писать using/dispose для каждого экземпляра немного муторно. А связка using + GC.SuppressFinalize() довольно сильно бьет по перформансу.

Сообщение от AnyOne697 а GC получает приказ удалить всё using ( здесь ) {}

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

Не по теме:

Сообщение от diagon Вы уверены?

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

taras atavin, вы либо тролль, либо не понимаете принципы работы GC. Когда удаляется указатель, тогда и декрементируется счётчик. Указателя нет, соответственно не к чему и обратиться.