- Can't understand this warning - 1 Update
- Can't understand this warning - 1 Update
- peformance of wait notify concept of condition variable - 6 Updates
- Virtual Functions and Polymorphism - 2 Updates
| Ian Collins <ian-news@hotmail.com>: Apr 28 08:42AM +1200 On 04/28/17 08:09 AM, Stefan Ram wrote: > main.cpp:15:8: warning: 'D' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [clang-diagnostic-weak-vtables] > struct D : public B > ^ Compiler bug? -- Ian |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 27 08:09PM I tried to make all of my functions out-of-line, yet I still get the warning. Why? And what can I do to get rid of the warning? #include <initializer_list> #include <iostream> #include <memory> #include <ostream> struct B { void n() const; virtual void v() const ; virtual ~B(); }; void ::B::n() const { ::std::cerr << "::B::n\n"; } void ::B::v() const { ::std::cerr << "::B::v\n"; } B::~B() = default; struct D : public B { void n() const; void v() const override; ~D() override; }; void ::D::n() const { ::std::cerr << "::D::n\n"; } void ::D::v() const { ::std::cerr << "::D::v\n"; } D::~D() = default; int main() { ::D const d; ::B const * b = &d; b->n(); b->v(); ::std::cerr << '\n'; d.n(); d.v(); ::std::cerr << '\n'; b->::B::n(); b->::B::v(); ::std::cerr << '\n'; d.::D::n(); d.::D::v(); ::std::cerr << '\n'; } main.cpp:6:8: warning: 'B' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [clang-diagnostic-weak-vtables] struct B ^ main.cpp:15:8: warning: 'D' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [clang-diagnostic-weak-vtables] struct D : public B ^ |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 09:27AM -0400 On 4/27/2017 1:29 AM, kushal bhattacharya wrote: >> In the OP's case, I bet he never has all 500 threads ready to run >> concurrently. > 500 threads are run parrallely i have checked that happening.The thing i am concerned about is about the architechture i am following right now If they are run in parallel, I would agree with others. Your design could be seriously improved. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 27 04:13PM +0200 > ... The point is that there is no reason to create much more threads > than the number of cores, they just tend to eat up all the memory > and start to fight with each other over resources. ... If the threads are i/o-bound, that's not a problem. And doing synchronous i/o and keeping the state in the threads registers and stack is more convenient than doing asychronous i/o. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 27 04:17PM +0200 > Even the model of creating a couple of worker threads per > cpu has issues if all of them are blasting a single mutex. If you have a procuder-consumer-pattern, the mutex is held only for very short intervals and the times preparing the item enqueued or processing the item dequeued is magnitutes longer. So the likehood of a collision shouldn't be high even for 500 threads. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 27 04:19PM +0200 > You don't use one thread per connection, that is a really > bad model if you want your application to scale. Synchronous I/O scales not very much less, but it uses a lot of memory for the threads stacks. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 27 08:38PM +0200 On 27.04.17 07.26, kushal bhattacharya wrote: > by blocking operation when i log something in a file from different threads is it part of blocking operation? Yes. No file I/O, no network I/O while holding a mutex that is shared between hundreds of threads. For debugging purposes this is OK but then you get the performance impact. Marcel |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Apr 27 12:01PM -0700 On Thursday, April 27, 2017 at 7:43:56 PM UTC+5:30, Bonita Montero wrote: > And doing synchronous i/o and keeping the state in the threads > registers and stack is more convenient than doing asychronous > i/o. But the operation here i am doing must be an asynchronous one since the client is firing at very small insterval and that is recieved by these threads for further processing |
| Tim Rentsch <txr@alumni.caltech.edu>: Apr 27 06:41AM -0700 > second definition for a future programmer/instructor. > Finally, is it possible that a virtual member function call is > resolved at compile-time and not at run-time. Jerry Stuckle gave a pretty good answer. The only thing I would add is about compile-time vs run-time resolution. For virtual functions this distinction is purely one of performance improvement, ie, a so-called "optimization", but otherwise makes no difference; that is, the program will behave the same way whether the resolution is done at run-time or compile-time, not counting any difference in how fast it would run. As with most micro-scale performance improvements, generally it is not worth worrying about, and that is especially true for you since you are just starting up the learning curve. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 27 08:13PM +0200 On 27-Apr-17 2:25 AM, Bilal wrote: > [snip] Finally, is it possible that a virtual member function call is > resolved at compile-time and not at run-time. In two cases: • You have turned off the virtual mechanism for a specific call by qualifying the function name with the class where the particular implementation you want, is (or is available by inheritance), e.g. `obj.My_class::foo()`. This is a non-virtual call of a virtual member function. • The compiler has determined, for a particular virtual call, that (1) it knows which implementation the virtual call mechanism would end up executing, and (2) that it can shave off a nanosecond or two by calling that implementation directly, or even inlining the function code. Cheers & hth., - Alf |
| 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