Здравствуйте, gid_vvp, Вы писали:
_>Привет
_>подскажите плиз плюсы и минусы обоих рантаймов вообще и для MS VC++ в часности
_>например в статическом рунтайме от студии течёт type_id::name
_>или этоАвтор(ы): Роман Хациев
Дата: 27.02.2002
Если вы пытались работать с экземплярами классов STL, передавая их в DLL, или получая оттуда, а потом бросили это занятие из-за непонятных ошибок, возникающих в вашей программе, то эта заметка для вас. Даже если видимых проблем в вашей программе нет, то все равно прочитайте эту заметку, чтобы знать что делать, когда они появятся :)
ИМХО, если несколько модулей обмениваются между собой — используй динамический рантайм.
Здравствуйте, gid_vvp, Вы писали:
_>подскажите плиз плюсы и минусы обоих рантаймов вообще и для MS VC++ в часности
_>или этоАвтор(ы): Роман Хациев
Дата: 27.02.2002
Если вы пытались работать с экземплярами классов STL, передавая их в DLL, или получая оттуда, а потом бросили это занятие из-за непонятных ошибок, возникающих в вашей программе, то эта заметка для вас. Даже если видимых проблем в вашей программе нет, то все равно прочитайте эту заметку, чтобы знать что делать, когда они появятся :)
Имею приложение из пары десятков dll-библиотек, в интерфейсах используются stl объекты. Приложение началось на vc2003, побывало на vc2005, теперь на 2008. Полёт нормальный. Главное не забывать контролировать, что у всех своих библиотек рантайм динамический. А насчет внешней среды, тут лучше нейтральные интерфейсы, а то ведь есть еще и C++Builder, и много чего еще.
На 2005 и 2008 есть небольшие трудности с распространением рантайма — ну тут надо просто один раз внимательно изучить msdn. Манифесты и прочее...
_>например в статическом рунтайме от студии течёт type_id::name
Еще один плюс в пользу динамического.
Здравствуйте, gid_vvp, Вы писали:
_>например в статическом рунтайме от студии течёт type_id::name
Имеется ввиду демангленное type_info::name()? Так оно вроде не течёт, а "продолжает жить до завершения приложения"
Это серьёзная проблема? Если же добавлять освобождение памяти в atexit, навскидку — придётся избегать проблем с очередностью вызовов. Правда, я не знаю как обстоит на самом деле, и чем dll отличается.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
_>>например в статическом рунтайме от студии течёт type_id::name
GN>Имеется ввиду демангленное type_info::name()? Так оно вроде не течёт, а "продолжает жить до завершения приложения"
собственно, это тоже самое что и течёт
GN> Это серьёзная проблема?
впринципе это проблема
GN> Если же добавлять освобождение памяти в atexit, навскидку — придётся избегать проблем с очередностью вызовов. Правда, я не знаю как обстоит на самом деле, и чем dll отличается.
а можно немного подробнее, что имелось ввиду?
Здравствуйте, gid_vvp, Вы писали:
_>собственно, это тоже самое что и течёт
По крайней мере множественные вызовы не приводят к новым аллокациям. Хотя это слишком оптимистично, стоит добавить про однопоточность
GN>> Это серьёзная проблема?
_>впринципе это проблема
Это понятно. Хочется понять, насколько важно её решить, она есть не только у MS.
_>а можно немного подробнее, что имелось ввиду?
Можно куда-то сохранить адрес демангленной строки, что бы освободить при завершении приложения. Однако, в деструкторах статических объектов тоже может использоваться type_info::name() что придётся учесть.
Самый простой способ решить — возвращать замангленное имя.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
GN>Самый простой способ решить — возвращать замангленное имя.
собственно хочется выяснить есть ли у динамического рантайма проблемы и минусы которые сведут на нет решение проблемы с утечкой
