- Is there any latest version available MersenneTwister.h C++ class MTRand? - 1 Update
- Vector with fixed memory size? - 5 Updates
- Undefined Behaviour - 2 Updates
- Remove the last argument from a parameter pack - 3 Updates
- We've won! - 2 Updates
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 17 09:56PM On 14/12/2018 09:05, Manikandan J wrote: > Thanks for the update. > The intention is to use the generator which doesn't have any vulnerability issues. > it was last updated 9 years ago. If any vulnerability there, cannot continue with this. It generates random numbers. Perhaps they aren't random enough for your needs, which is why your concern. But it shouldn't be public facing. Perhaps if you tell us a bit more about why you are worried we can help. Andy |
| Juha Nieminen <nospam@thanks.invalid>: Dec 17 08:50AM >>If you can have an array of objects instead of an array of pointers >>to objects, why would you deliberately choose the latter? > Cache management. I think an array of objects is more cache-friendly than individually allocated objects. (The array of objects will be all in consecutive memory, while the individually allocated objects may end up really scattered in memory, potentially causing memory fragmentation and cache misses.) |
| "Öö Tiib" <ootiib@hot.ee>: Dec 17 12:50AM -0800 On Friday, 14 December 2018 17:21:17 UTC+2, Real Troll wrote: > There is no such thing as right answer or wrong answer. The OP decides > what is right for him or her. The feature of marking something is right > should be removed because, as you say, it is subjective. StackOverflow tries to filter out such questions to what there are no correct answers. The issue there is that asker can mark one of answers as "accepted". Reader of it should just know that people can (and often do) accept incorrect answers. It happens because that answer seemed to fit with asker's expectations or seemed to work for them, not because that question was subjective, controversial or unclear. |
| scott@slp53.sl.home (Scott Lurndal): Dec 17 01:52PM >memory, while the individually allocated objects may end up really >scattered in memory, potentially causing memory fragmentation and >cache misses.) Often (usually), the objects are accessed randomly via the pointers, and the fact that the objects are located contiguously doesn't help in that case. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 17 02:23PM > Often (usually), the objects are accessed randomly via the pointers, and > the fact that the objects are located contiguously doesn't help in > that case. It still reduces memory fragmentation, which may increase efficiency overall. |
| scott@slp53.sl.home (Scott Lurndal): Dec 17 04:08PM >> that case. >It still reduces memory fragmentation, which may increase efficiency >overall. I don't see that as too likely, and highly dependent upon the usage model of the data structure in question. But, YMMV. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 17 02:42AM +0100 On 16.12.2018 17:30, Tim Rentsch wrote: > 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. The reasoning seems clear to me. Consider: auto main( const int n, char** ) -> int { return 42/(n-1); } Invoked with no arguments it will have n == 1 and Undefined Behavior. Otherwise it will have n > 1 and in itself well-defined behavior, although for a high enough number of arguments the behavior is system dependent (e.g. max 8 bits return value in *nix, 32 bits in Windows). So, the UB here depends on the program invocation, the input data. There is no way to say that the program itself, without considering its invocation, has UB or no UB. It has the potential for UB. For some input. [snip-even-more] Cheers! - Alf (hoping he is not adding irrelevancies here, TLDR ;-) ) |
| "Öö Tiib" <ootiib@hot.ee>: Dec 17 04:38AM -0800 On Sunday, 16 December 2018 18:30:31 UTC+2, Tim Rentsch wrote: > 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. I am in dark what reasoning is missing. There simply are no separate things like for example "limits breaching behavior" and "undefined behavior". There is behavior and in some circumstances it can be undefined. > 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.) Can you specifically show how my answers to your questions did not address what was asked? Most usually the needs of resources during execution (and whole flow of execution in general) depends on input data. I basically can't find anything that indicates that what happens on case of exceeding resource limits is somehow defined (or implied to be) as something else but behavior. What it is then? Yes, if the implementation can discover such breach during translation then it can handle it like it handles ill-formed code by diagnosing it during translation but that is special, lucky case and is nowhere required about automatic storage limit. > 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? I also do not want to argue and have only tried to explain my position and how and why it was reached. I don't see where I have tried to hide or dissemble something. It is basically that no one can demonstrate presence of requirements to behavior on case of exceeding limits in C++ standard therefore that behavior is undefined. There are no System.StackOverflowException or things like that in C++. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 17 03:30AM +0100 On 16.12.2018 18:46, Tim Rentsch wrote: > int foo( int ); > have different signatures, but they have the same type. Certainly > one could be used in place of the other. Technically you're right. But it's worth noting that the term "signature" * is defined differently in C++11 and later, than in C++98/C++03, * has a general language independent meaning more like C++03 than C++11. The language independent meaning, and the C++98/C++03 meaning, does not include the function name: C++03 §1.3.10: [quote] the information about a function that participates in overload resolution (13.3): the types of its parameters and, if the function is a class member, the cv- qualifiers (if any) on the function itself and the class in which the member function is declared. 2) The signature of a function template specialization includes the types of its template arguments (14.5.5.1). [/quote] Evidently for C++11 someone tried very hard to really define in detail the meaning of "signature" so that the standard's use of that term could be read pedantically formally, and perhaps so that that term could be used instead of C++03 "type" in certain context (I'm not sure of that, I haven't checked). The "signature" of a /function/ is defined as "name, parameter type list (8.3.5), and enclosing namespace (if any)". Then there is a definition of the "signature" of a /function template/, and a definition of it for /function template specialization/, and a definition of it for /class member function/, and a definition of it for /class member function template/, and a definition of it for /class member function template specialization/, where for the template meanings also the return type is part of the signature. I.e. a simple general definition that resonated well with the term's general use, was replaced with umpteen detailed definitions that are more unnatural in that they include the function name. To me it reads as an attempt to define the term so that it can be used as part of an in-group language to let language lawyers more easily identify each other as such, and to let them identify non-lawyers. Cheers!, - Alf |
| 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). |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 17 02:53AM +0100 On 16.12.2018 18:43, Tim Rentsch wrote: > 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. "The type required by the argument of the constructor" You appear to say the "argument of the constructor" is an intermediate type. Then the "The type required by [the intermediate type]" is? I respectfully can't make sense of your position, except that it seems to require much muddying of waters, this time via "doesn't matter". Maybe it requires someone better at double-think+ than me. Cheers!, - Alf |
| 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. |
| 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