- thread local ctor on main... - 4 Updates
- Remove the last argument from a parameter pack - 3 Updates
- We've won! - 1 Update
- Undefined Behaviour - 1 Update
- Vector with fixed memory size? - 1 Update
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 15 07:46PM -0800 On 12/15/2018 2:05 PM, Paavo Helde wrote: >> if we delete the lines of code that actually use it. > Everything is "before" an event which never happens, so MSVC is arguably > correct here from a legal viewpoint. It does seem to violate the "zero-overhead" principle. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 15 08:11PM -0800 On 12/15/2018 12:37 PM, James Kuyper wrote: > applied only to the names of variables of namespace or block scope and > to the names of static data members." (7.1.1p3). Whether or not it's a > POD type has no relevance. I am very familiar with POSIX thread "specific" data for threads: http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_getspecific.html Never really messed around with C++11 thread specific data. I just wanted to ask this question here wrt when ctor/dtor's can be called. I am not used to a ctor being called before its first use like MSVC does wrt thread_local. I like GCC's behavior better because it fits in with the POSIX way of per-thread data. Fwiw, I think C11 threads are more inline with POSIX: https://en.cppreference.com/w/c/thread/tss_get https://en.cppreference.com/w/c/thread/tss_set There is no ambiguity here. |
| David Brown <david.brown@hesbynett.no>: Dec 16 01:20PM +0100 On 16/12/2018 04:46, Chris M. Thomasson wrote: >> Everything is "before" an event which never happens, so MSVC is >> arguably correct here from a legal viewpoint. > It does seem to violate the "zero-overhead" principle. This is a matter of optimisation and code quality - both compilers generate correct code. And while gcc's method is more efficient in this case, it could be less efficient in other cases (needing more overhead when you actually use the thread locals). The "zero overhead" principle is not about having zero overhead for things in your code that you don't use. It is about having zero overhead for features in the language that you don't use. The idea is that when the language (or the standard library) introduces new features, they will not cause overhead in code that does not use them. Overhead for objects or functions that you don't use is purely a matter of optimisation. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 16 03:00PM -0800 On 12/16/2018 4:20 AM, David Brown wrote: > features, they will not cause overhead in code that does not use them. > Overhead for objects or functions that you don't use is purely a matter > of optimisation. Fair enough. I am just not really used to a thread local ctor being called before I use it, coming from C and POSIX; C11 even. |
| Tim Rentsch <txr@alumni.caltech.edu>: Dec 16 09:46AM -0800 > disconnected from C++. > Alf's point is that it's a design error to directly connect functions > with mismatching signatures. I think you mean type rather than signature. The two functions int bas( int ); int foo( int ); have different signatures, but they have the same type. Certainly one could be used in place of the other. |
| Tim Rentsch <txr@alumni.caltech.edu>: Dec 16 09:51AM -0800 > passing a lambda expression to your connect() function, then the > signature of the lambda expression must match the signal's signature > exactly, even if some arguments are unused in the lambda. I think you mean type rather than signature. Functions have signatures, lambda expressions do not (as the C++ standard uses the term signature). |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 16 06:03PM On Sun, 16 Dec 2018 09:51:51 -0800 > I think you mean type rather than signature. Functions have > signatures, lambda expressions do not (as the C++ standard uses > the term signature). Could you please stop replying to my posts. I find your condescension and overall weirdness unappealing. TIA. |
| Tim Rentsch <txr@alumni.caltech.edu>: Dec 16 09:43AM -0800 >> 'long'. > In the last sentence above you are yourself using the word > 'argument' about a formal argument. No, I'm using the word 'argument' about an actual argument. The formal argument has type 'const long &'. The intermediate actual argument has type 'long'. The orginal source argument has type 'int', and is converted by a standard conversion sequence to a value of type 'long'. > The actual argument is `0`. There is nothing "required by" the > `0`. The source argument is 0. That source argument is converted, per the quoted excerpt above, to a different, intermediate argument. The Standard evidences this distinction by its phrase "source type", used to distinguish the type of the orginal argument from the type of the intermediate argument produced by the standard conversion sequence applied. > The formal argument is `const long&`. There is a type required by > the const long&`. In the given context, that type is `long`. The point of the text in the Standard is to distinguish the type of the intermediate (actual) argument from the type of the formal parameter. Alternatively, we might say the type 'long' is required by the original source argument, 0, because 'long' is the only suitable intermediate type for the source type 'int'. It is the type of the original argument that identifies uniquely the result type of the standard conversion sequence that is being discussed. > conversion sequence result type", which is evidently intended to > refer to the result type of the initial conversion sequence. > In an ISO standard such infinite recursion would be a defect. Calm down. I am not defining types in terms of other types. The Standard says "the type required by the argument of the constructor", and that the phrasing I am following. The point is this: it is the type of the /actual/ argument that determines the result type of the initial standard conversion sequence. Whether we think of that as the original source argument 0 or the intermediate converted argument value (which has type long) doesn't matter; what does matter is that it is an actual argument, not a formal parameter, that is being referenced. The word "argument", meaning actual argument, is being used correctly; it is not being used to reference the the formal parameter, which limits the set of types that are allowed but does not determine uniquely which type is the result of the initial standard conversion sequence - only the type of the actual argument does that. |
| Tim Rentsch <txr@alumni.caltech.edu>: Dec 16 08:30AM -0800 > behavior may be defined. For example if the limits of automatic > storage of executing environment are exceeded or not can > depend on data that is processed. I am disappointed by your response. Basically all you have done is repeat or rephrase things you have said earlier. There are conclusions but no reasoning leading up to them. Also I asked at least half a dozen questions, none of which you gave answers to AFAICT. (At the end you give an answer but it's not an answer to the question I asked.) I don't want to have an argument, I just want to understand what you think and WHY you think it. Rather than explain you just repeat your talking points. It's almost like you're actively avoiding giving more information. What's the point of that? |
| woodbrian77@gmail.com: Dec 16 05:28AM -0800 On Saturday, December 15, 2018 at 2:25:09 AM UTC-6, Juha Nieminen wrote: > individually). The former is also safer (and easier to use safely) > than the latter. > The main situation where you would want to use an array of pointers I would change that to: One situation ... I've not found many users of this library: https://www.boost.org/doc/libs/1_69_0/doc/html/poly_collection.html Maybe there's something wrong with that library? The author spent a lot of time on it and is very experienced. From what I can tell it's one of the good parts of Boost. > if what you actually need is an array of "references". Since you > can't actually use references in an array, you'll have to use > pointers instead.) Brian Ebenezer Enterprises - In G-d we trust. https://github.com/Ebenezer-group/onwards |
| 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