- "Address Sanitizer in Visual C++" by Shao Voon Wong - 2 Updates
- static initialisation fiasco - 2 Updates
- Call destructor on object of any type - 2 Updates
| Lynn McGuire <lynnmcguire5@gmail.com>: Aug 10 04:32PM -0500 "Address Sanitizer in Visual C++" by Shao Voon Wong https://www.codeproject.com/Articles/5269130/Address-Sanitizer-in-Visual-Cplusplus "Use Address Sanitizer in Visual C++ to detect memory address problems." "In this blog, I'll demonstrate how to utilize Address Sanitizer (ASan) in Visual C++ to check for memory problems. MSVC team ported the Clang ASan to the Windows platform in 2019 and since it is still at an experimental stage, be sure to expect kinks to be ironed out." I wonder how much it slows down your software. Lynn |
| rick.c.hodgin@gmail.com: Aug 10 04:04PM -0700 On Monday, August 10, 2020 at 5:32:44 PM UTC-4, Lynn McGuire wrote: > experimental stage, be sure to expect kinks to be ironed out." > I wonder how much it slows down your software. > Lynn Thank you, Lynn, for posting this. +1 There are several videos from 2012-2017 by Kostya Serebryany: https://www.youtube.com/watch?v=Q2C2lP8_tNE He discusses the hit, but it's been a while. I don't remember what it was. He does mention it's tolerable compared toother tools like valgrind. -- Rick C. Hodgin |
| Juha Nieminen <nospam@thanks.invalid>: Aug 10 06:06AM >> Calling getFred() from any translation unit makes the right thing will >> happen. Ditto for Barney. > in some cases this can cause the static de-initialisation fiasco I don't think it's a good idea for a destructor to rely on outside resources which might or might not exist by the time the destructor is called. If class A depends on an object of class B, then it may be better if that object is a member of A, not an outside object. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 10 11:07AM On Mon, 2020-08-10, Juha Nieminen wrote: >>> Calling getFred() from any translation unit makes the right thing will >>> happen. Ditto for Barney. >> in some cases this can cause the static de-initialisation fiasco I haven't paid attention to the thread, and may be misunderstanding, but ... > I don't think it's a good idea for a destructor to rely on outside resources > which might or might not exist by the time the destructor is called. Wouldn't that apply just as much during the object's normal lifetime? struct A { B& b; // ... }; We can do this only if we have control over the relative lifetimes of the A and the B, and then we can have control during A's destruction too. To me, this is often a standard part of the design. My main() often looks something like A a; B b(a); C c(a); D d(b, c); ... Although I concede that: - Destructors shouldn't do too much "global stuff" in either case. - This breaks horribly if you start having global objects, std::shared_ptr to them, threads and shared libraries. But (see above) then you don't have control over lifetimes. > If class A depends on an object of class B, then it may be better if that > object is a member of A, not an outside object. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Aug 10 12:36AM -0700 Let's say there's an object called "obj", and we don't know its type. We can call its destructor as follows: typedef remove_cv<remove_ref<decltype(obj)>::type>::type Typeof_obj; obj.~Typeof_obj(); Should it not be possible to do the following? obj.~(typename std::remove_cv<std::remove_reference<decltype(obj)>::type>::type)(); This won't compile for me with g++, it gives this error: other.cpp: In function 'int main()': other.cpp:8:10: error: expected class-name before '(' token obj.~(typename std::remove_cv<std::remove_reference<decltype(obj)>::type>::type)(); ^ other.cpp:8:84: error: expected '(' before ')' token obj.~(typename std::remove_cv<std::remove_reference<decltype(obj)>::type>::type)(); |
| Christian Gollwitzer <auriocus@gmx.de>: Aug 10 09:44AM +0200 Am 10.08.20 um 09:36 schrieb Frederick Gotham: > ^ > other.cpp:8:84: error: expected '(' before ')' token > obj.~(typename std::remove_cv<std::remove_reference<decltype(obj)>::type>::type)(); See here how to do it: https://isocpp.org/wiki/faq/dtors#placement-delete Christian |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment