- More about computing and parallel computing.. - 3 Updates
- Microsoft to explore using Rust - 1 Update
- Why does this work on Xcode ??? - 7 Updates
- [niubbo] convert a string representing a valid date to some "binary" date - 2 Updates
- how/why it is written ... int &numberRef; vs int& numberRef; - 4 Updates
- how/why it is written ... int &numberRef; vs int& numberRef; - 6 Updates
- [niubbo] aggregate types built in a function and returned by value (on stack). Shallow or Deep copy ? - 2 Updates
| Horizon68 <horizon@horizon.com>: Jul 17 11:52AM -0700 Hello, More about computing and parallel computing.. The important guaranties of Memory Safety in Rust are: 1- No Null Pointer Dereferences 2- No Dangling Pointers 3- No Buffer Overruns I think i have solved Null Pointer Dereferences and also solved Dangling Pointers and also solved memory leaks for Delphi and Freepascal by inventing my "scalable" reference counting with efficient support for weak references and i have implemented it in Delphi and Freepascal, and reference counting in Rust and C++ is "not" scalable. About the (3) above that is Buffer Overruns, read here about Delphi and Freepascal: What's a buffer overflow and how to avoid it in Delphi? http://delphi.cjcsoft.net/viewthread.php?tid=49495 About Deadlock and Race conditions in Delphi and Freepascal: I have ported DelphiConcurrent to Freepascal, and i have also extended them with the support of my scalable RWLocks for Windows and Linux and with the support of my scalable lock called MLock for Windows and Linux and i have also added the support for a Mutex for Windows and Linux, please look inside the DelphiConcurrent.pas and FreepascalConcurrent.pas files inside the zip file to understand more. You can download DelphiConcurrent and FreepascalConcurrent for Delphi and Freepascal from: https://sites.google.com/site/scalable68/delphiconcurrent-and-freepascalconcurrent DelphiConcurrent and FreepascalConcurrent by Moualek Adlene is a new way to build Delphi applications which involve parallel executed code based on threads like application servers. DelphiConcurrent provides to the programmers the internal mechanisms to write safer multi-thread code while taking a special care of performance and genericity. In concurrent applications a DEADLOCK may occurs when two threads or more try to lock two consecutive shared resources or more but in a different order. With DelphiConcurrent and FreepascalConcurrent, a DEADLOCK is detected and automatically skipped - before he occurs - and the programmer has an explicit exception describing the multi-thread problem instead of a blocking DEADLOCK which freeze the application with no output log (and perhaps also the linked clients sessions if we talk about an application server). Amine Moulay Ramdane has extended them with the support of his scalable RWLocks for Windows and Linux and with the support of his scalable lock called MLock for Windows and Linux and he has also added the support for a Mutex for Windows and Linux, please look inside the DelphiConcurrent.pas and FreepascalConcurrent.pas files to understand more. And please read the html file inside to learn more how to use it. About race conditions now: My scalable Adder is here.. As you have noticed i have just posted previously my modified versions of DelphiConcurrent and FreepascalConcurrent to deal with deadlocks in parallel programs. But i have just read the following about how to avoid race conditions in Parallel programming in most cases.. Here it is: https://vitaliburkov.wordpress.com/2011/10/28/parallel-programming-with-delphi-part-ii-resolving-race-conditions/ This is why i have invented my following powerful scalable Adder to help you do the same as the above, please take a look at its source code to understand more, here it is: https://sites.google.com/site/scalable68/scalable-adder-for-delphi-and-freepascal Other than that, about composability of lock-based systems now: Design your systems to be composable. Among the more galling claims of the detractors of lock-based systems is the notion that they are somehow uncomposable: "Locks and condition variables do not support modular programming," reads one typically brazen claim, "building large programs by gluing together smaller programs[:] locks make this impossible."9 The claim, of course, is incorrect. For evidence one need only point at the composition of lock-based systems such as databases and operating systems into larger systems that remain entirely unaware of lower-level locking. There are two ways to make lock-based systems completely composable, and each has its own place. First (and most obviously), one can make locking entirely internal to the subsystem. For example, in concurrent operating systems, control never returns to user level with in-kernel locks held; the locks used to implement the system itself are entirely behind the system call interface that constitutes the interface to the system. More generally, this model can work whenever a crisp interface exists between software components: as long as control flow is never returned to the caller with locks held, the subsystem will remain composable. Second (and perhaps counterintuitively), one can achieve concurrency and composability by having no locks whatsoever. In this case, there must be no global subsystem state—subsystem state must be captured in per-instance state, and it must be up to consumers of the subsystem to assure that they do not access their instance in parallel. By leaving locking up to the client of the subsystem, the subsystem itself can be used concurrently by different subsystems and in different contexts. A concrete example of this is the AVL tree implementation used extensively in the Solaris kernel. As with any balanced binary tree, the implementation is sufficiently complex to merit componentization, but by not having any global state, the implementation may be used concurrently by disjoint subsystems—the only constraint is that manipulation of a single AVL tree instance must be serialized. Read more here: https://queue.acm.org/detail.cfm?id=1454462 And about Message Passing Process Communication Model and Shared Memory Process Communication Model: An advantage of shared memory model is that memory communication is faster as compared to the message passing model on the same machine. However, shared memory model may create problems such as synchronization and memory protection that need to be addressed. Message passing's major flaw is the inversion of control–it is a moral equivalent of gotos in un-structured programming (it's about time somebody said that message passing is considered harmful). Also some research shows that the total effort to write an MPI application is significantly higher than that required to write a shared-memory version of it. And more about my scalable reference counting with efficient support for weak references: My invention that is my scalable reference counting with efficient support for weak references version 1.35 is here.. Here i am again, i have just updated my scalable reference counting with efficient support for weak references to version 1.35, I have just added a TAMInterfacedPersistent that is a scalable reference counted version, and now i think i have just made it complete and powerful. Because I have just read the following web page: https://www.codeproject.com/Articles/1252175/Fixing-Delphis-Interface-Limitations But i don't agree with the writting of the guy of the above web page, because i think you have to understand the "spirit" of Delphi, here is why: A component is supposed to be owned and destroyed by something else, "typically" a form (and "typically" means in english: in "most" cases, and this is the most important thing to understand). In that scenario, reference count is not used. If you pass a component as an interface reference, it would be very unfortunate if it was destroyed when the method returns. Therefore, reference counting in TComponent has been removed. Also because i have just added TAMInterfacedPersistent to my invention. To use scalable reference counting with Delphi and FreePascal, just replace TInterfacedObject with my TAMInterfacedObject that is the scalable reference counted version, and just replace TInterfacedPersistent with my TAMInterfacedPersistent that is the scalable reference counted version, and you will find both my TAMInterfacedObject and my TAMInterfacedPersistent inside the AMInterfacedObject.pas file, and to know how to use weak references please take a look at the demo that i have included called example.dpr and look inside my zip file at the tutorial about weak references, and to know how to use delegation take a look at the demo that i have included called test_delegation.pas, and take a look inside my zip file at the tutorial about delegation that learns you how to use delegation. I think my Scalable reference counting with efficient support for weak references is stable and fast, and it works on both Windows and Linux, and my scalable reference counting scales on multicore and NUMA systems, and you will not find it in C++ or Rust, and i don't think you will find it anywhere, and you have to know that this invention of mine solves the problem of dangling pointers and it solves the problem of memory leaks and my scalable reference counting is "scalable". And please read the readme file inside the zip file that i have just extended to make you understand more. You can download my new scalable reference counting with efficient support for weak references version 1.35 from: https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references Thank you, Amine Moulay Ramdane. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jul 17 09:17PM +0200 Can you please stop your manic off-topic postings here? |
| Horizon68 <horizon@horizon.com>: Jul 17 12:34PM -0700 On 7/17/2019 12:17 PM, Bonita Montero wrote: > Can you please stop your manic off-topic postings here? Don't worry, i am posting just very few posts here. Thank you, Amine Moulay Ramdane. |
| Horizon68 <horizon@horizon.com>: Jul 17 11:35AM -0700 Hello, Microsoft to explore using Rust Rust has been gaining in popularity and Microsoft intends to see if it can hold up to its demands. 70% OF ALL MICROSOFT PATCHES ARE FOR MEMORY-RELATED BUGS The reason for this high percentage is because Windows and most other Microsoft products have been written mostly in C and C++, two "memory-unsafe" programming languages that allow developers fine-grained control of the memory addresses and where code can be executed. Microsoft plans to explore using the Rust programming language as an alternative to C, C++, and others, as a way to improve the security posture of its and everyone else's apps. The announcement was made yesterday by Gavin Thomas, Principal Security Engineering Manager for the Microsoft Security Response Center (MSRC). "You're probably used to thinking about the Microsoft Security Response Center as a group that responds to incidents and vulnerabilities," Thomas said. "We are a response organization, but we also have a proactive role, and in a new blog series we will highlight Microsoft's exploration of safer system programming languages, starting with Rust." The end game is to find a way to move developers from the aging C and C++ programming language to so-called "memory-safe languages." Memory-safe languages, such as Rust, are designed from the ground up with protections against memory corruption vulnerabilities, such as buffer overflows, race conditions, memory leaks, use-after free and memory pointer-related bugs. C#, a programming language developed by Microsoft, also features some memory access improvements but is not as advanced as Rust. Read more here: https://www.zdnet.com/article/microsoft-to-explore-using-rust/ Thank you, Amine Moulay Ramdane. |
| Bob Langelaan <bobl0456@gmail.com>: Jul 16 10:03PM -0700 Several of my students have submitted the following solution (or something very similar) for a recursive function to add the contents of an array: // Returns true if the supplied value is found in the array of values // and false otherwise template <typename type, size_t size> bool isMember(const array<type,size> & myArray, const int n, const type value) { if ( n < 0 ) { return false; } else if ( myArray[n] == value ) { return true; } return isMember( myArray, n - 1, value ); } Clearly it should not work since the line: else if ( myArray[n] == value ) will attemppt to reference an out of bounds element past the end of the array the first time the function is invoked. The above code has a runtime error, as expected, when executed on MS VS C++ 2017 but evidently not on the Xcode IDE. I have two questions: - why does the runtime not catch the fact that the array is referenced out of bounds as with MS VS C++? - is there a compiler option that my students using Xcode could use so this logic error is caught at runtime? Thanks in advance. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 17 08:46AM +0300 On 17.07.2019 8:03, Bob Langelaan wrote: > Several of my students have submitted the following solution (or something very similar) for a recursive function to add the contents of an array: The function does not appear to add any contents to anywhere. > Clearly it should not work since the line: > else if ( myArray[n] == value ) > will attemppt to reference an out of bounds element past the end of the array the first time the function is invoked. Only if n >= size when first invoked. One can easily call it with size-1 instead for example, making it to work perfectly well (assuming size>0 && size-1<=INT_MAX). The above code has a runtime error, as expected, Why do you expect a specific behavior from UB? Clearly, to get a runtime error one should have written myArray.at(n) instead. MSVC++ has defined this particular piece of UB by having the "checked iterators" feature switched on by default in Debug builds (in earlier MSVC++ versions, also in Release builds). One can turn this feature off by defining suitable macros. when executed on MS VS C++ 2017 but evidently not on the Xcode IDE. > I have two questions: > - why does the runtime not catch the fact that the array is referenced out of bounds as with MS VS C++? Because clang or gcc does not have any "checked iterators" feature switched on by default. > - is there a compiler option that my students using Xcode could use so this logic error is caught at runtime? Not sure, but that would rely on non-standard extensions anyway. Teach your students std::array::at() instead. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 17 12:06AM -0700 On Wednesday, 17 July 2019 08:03:16 UTC+3, Bob Langelaan wrote: > - is there a compiler option that my students using Xcode could use so this logic error is caught at runtime? clang has -D_LIBCPP_DEBUG for debug bounds checking. I don't have mac in front of me at the moment to check if it works with your code. Similarly gcc has -D_LIBCPP_DEBUG for that. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 17 07:46AM > will attemppt to reference an out of bounds element past the > end of the array the first time the function is invoked. > The above code has a runtime error, It may be a "runtime error" in the logical sense, but not in the standard sense. The standard says it's undefined behavior, which is a completely different thing. > as expected, when executed on MS VS C++ 2017 but evidently > not on the Xcode IDE. Neither compiler is doing a wrong thing. Since it's undefined behavior, they can do whatever they want. Throwing some kind of error, crashing, behaving in a weird way, or seemingly working "correctly" are all valid actions. Undefined behavior means anything goes, nothing is guaranteed. > - why does the runtime not catch the fact that the array is > referenced out of bounds as with MS VS C++? Because the standard doesn't require it, and most compilers will not add such boundary checks for efficiency reasons. Adding a boundary check to every single array access is expensive. I'm certain that VS C++ will also not add such boundary checks if you specify enough optimization parameters (and/or remove enough debugging parameters). |
| "Öö Tiib" <ootiib@hot.ee>: Jul 17 01:44AM -0700 On Wednesday, 17 July 2019 10:06:39 UTC+3, Öö Tiib wrote: > I don't have mac in front of me at the moment to check if it works > with your code. > Similarly gcc has -D_LIBCPP_DEBUG for that. Sorry, gcc has -D_GLIBCXX_DEBUG |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 17 09:12AM -0400 On 7/17/19 1:03 AM, Bob Langelaan wrote: > Several of my students have submitted the following solution (or something very similar) for a recursive function to add the contents of an array: > // Returns true if the supplied value is found in the array of values > // and false otherwise I don't see how such a function would be of any use when adding the contents of the array. What value would you supply to it, and why? > Clearly it should not work since the line: > else if ( myArray[n] == value ) > will attemppt to reference an out of bounds element past the end of the array the first time the function is invoked. Only if it's invoked with the wrong value; the first time it should be invoked with size-1 as the second argument. > The above code has a runtime error, as expected, when executed on MS VS C++ 2017 but evidently not on the Xcode IDE. > I have two questions: > - why does the runtime not catch the fact that the array is referenced out of bounds as with MS VS C++? Because you used myArray[n], for which the defined behavior is *(a.begin() + n) (Table 88, 26.2.3p14). That expression dereferences a past-the-end iterator value. A past-the-end iterator value is not required to be dereferenceable (Table 95, 27.2.3p2: ++r returns either a value which is guaranteed to be dereferenceable, or a past-the-end iterator). The undefined behavior of dereferencing a past-the-end iterator includes, as one possibility, a runtime error (as MSVC C++ does), but that is not required. If you want guaranteed runtime bounds checking, use myArray.at(n) (26.2.3p15). > - is there a compiler option that my students using Xcode could use so this logic error is caught at runtime? No, but there is a way to modify the code to guarantee such checking: use at(). |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 17 05:01PM +0200 On 17.07.2019 07:03, Bob Langelaan wrote: > Several of my students have submitted the following solution (or > something very similar) for a recursive function to add the contents > of an array: The presented code doesn't "add the contents", I guess that's just typo. > } > return isMember( myArray, n - 1, value ); > } The two main problems with this function are: * Passing `value` by value may incur severe copying inefficiency. * The tail recursion may easily consume all stack space and yield UB. The last problem is because C++ does not guarantee tail recursion optimization, so it's a pretty dangerous thing to do for an O(n) algorithm as this is. It's generally OK for O(log n), as long as things are done properly such as here, if one passed `value` by reference to `const`. > else if ( myArray[n] == value ) > will attemppt to reference an out of bounds element past the end of > the array the first time the function is invoked. Only if `n` is the array size or larger in the first call. Since `n` is of signed type `int` the reasonable deduction from the signature and implementation is that the function is intended to be called with `n` as the index of the last item to be checked. Tip: in 64-bit Windows `int` is just 32-bit. The function is then unable to handle large arrays in that environment. Using `ptrdiff_t` or C++20 `ssize_t` supports also large arrays in a 64-bit address space. > The above code has a runtime error, as expected, when executed on MS > VS C++ 2017 but evidently not on the Xcode IDE. You can in general not count on any specific behavior for UB. It can even vary from run to run of the same program. However, particular compilers can support ways of handling situations that for portable code would be UB. > I have two questions: > - why does the runtime not catch the fact that the array is > referenced out of bounds as with MS VS C++? Because you didn't ask for it. MSVC is one of the compilers supporting bounds checking of the standard library containers, but you have to ask for it. I believe it's the default in a Visual Studio project Debug build. > - is there a compiler option that my students using Xcode could use > so this logic error is caught at runtime? Xcode is an IDE, for the Mac; it uses a compiler but isn't a compiler. Unless XCode has a general setting for bounds checking you will have to use the relevant option for the /compiler/ you use. Typically bounds checking is requested by defining some preprocessing symbol in the build, via compiler option `-D` (or '/D' with Visual C++). By default your compiler will be clang, and I seem to recall that the apparent g++ on the mac is clang in disguise, but I'm not sure. I don't have a Mac. Anyway look up the options in the compiler's documentation. > Thanks in advance. Cheers!, - Alf |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 17 03:49PM +0200 This one will surely sound very trivial to the skilled programmers ... I'm searching various standard binary date/time formats, but I'm not finding functions that "build" a binary object from a (valid, localized or not) string representation of a date and/or time. (the equivalent to strtod or atof for numbers) In the string class, when dealing comparisons, I am trying to implement also date comparisons (which requires a conversion from textual, human readable, to binary format supporting comparisons in itself) .... and, well, I'm not managing to find a "reverse" conversion (while there is plenty of functions outputting any binary data format to textual format). Also with scanf, I can't find any viable patch. One thing : I'd need an input function smart enough to support various date and/or time human-readable representations, possibly ALL of them, a rather variable scenario (short vs long, localized, UTC, just date, just time, both, separators ? named day / month ?) It is the kind of piece of code one would never want to write by hand. the string object will just have a bool flag like "IsDateTime" set by the user, but the synthax of the representation should be as much general as possible, so I need a parsing function .... standard if there are some ... any suggestion ? TY -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 17 04:30PM +0200 On 17/07/19 16:14, Stefan Ram wrote: > See: strftime, asctime from <ctime>, wcsftime from <cwchar> > and put_time/get_time from <iomanip>. > Also check out 27.4.5 The time category [category.time] in n4800. thanks, I'll inquire about them ! ah, meanwhile I did found sth here https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html which is still not satisfactory, as this function require the FORMAT of the textual data be known in advance, a demand that cannot be fulfilled ... I'm gonna read your suggestions. Ciao -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 17 12:32PM >how/why it is written ... int &numberRef; vs int& numberRef; I have a C scanner (lexer) right behind my retina, so to my brain int &numberRef is /exactly/ the same as int& numberRef . Well, I may have exaggerated a little. But I am sure that I don't see as much difference as some other people might see there. When I think about it, I might prefer int & numberRef in my own code, but for a beginner, int &numberRef might be helpful to remember the syntax (hoping that it was learned at all!). In the courses I give, I do not teach comma-separated init-declarators. So, my init-declarator-lists there always have at most one init-declarator. The reality cannot be permanently hidden from beginners. So, I /would/ actually teach comma-separated init-declarators if the courses would be longer. But since my courses are very short, I have to use some simplifications. |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 17 12:59PM >deep copy In Smalltalk, there are two different standard messages: anObject deepCopy anObject shallowCopy . So an early C++ library, the NIH class library, had support for shallow and deep copies in every object, trying to impose the qualities of Smalltalk on C++. Today, in C++, one prefers concrete classes which might act as resource handles but behave like built-in types and whose types are not contained in deep inheritance hierarchies and which do not required the use of pointers. These semantics then dictate the meaning of "copy" without the need to distinguish between deep and shallow copies. So, when one asks oneself "what should 'copy' mean in the case of a string?", one should try to imitate what "copy" means in the case of an "int". |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 17 02:09PM >(the equivalent to strtod or atof for numbers) See: strftime, asctime from <ctime>, wcsftime from <cwchar> and put_time/get_tim/get_timee from <iomanip>. Also check out 27.4.5 The time category [category.time] in n4800. |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 17 02:14PM Supersedes: <strftime-20190717150010@ram.dialup.fu-berlin.de> >(the equivalent to strtod or atof for numbers) See: strftime, asctime from <ctime>, wcsftime from <cwchar> and put_time/get_time from <iomanip>. Also check out 27.4.5 The time category [category.time] in n4800. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 17 07:06AM +0200 On 16.07.2019 12:45, David Brown wrote: > On 16/07/2019 11:52, Alf P. Steinbach wrote: > I'm snipping most of what you wrote - going through it point for point > would be, well, pointless. Yes, nine fallacies in one posting is a lot. And I only pointed out the top-level ones. > when it contains your special language. The fact that it can be > compiled by a C++ compiler, assuming one goes to the bother of finding > and downloading your library, is irrelevant. The first sentence contains two assertions, both incorrect. The last sentence is an assertion that is incorrect. I don't think they qualify as fallacies, they're just being wrong about things, having an incorrect perception, so it's an improvement. :) > incomprehensible at worst. But I dislike the way he says it. >> Ninth fallacy, in the denial area. > And you wonder why people aren't always appreciative of your posts. It's not true that people are not usually appreciative of my posts. Consequently it's not true that I've wondered about that, either. Since you know that I haven't wondered about this, that last incorrectness is a lie. --- That's usually the way it goes: self-contradictions, an avalanche of fallacies, topical blindness, pure associations and generalizations, followed by plain lies. Then there's a further known pattern of development if the discussion about the topic continues, then involving more social tools. I suggest we just stop it. --- Since you haven't resorted to those techniques in other areas of discussion here, since in fact you're generally one of the most decent people in the group and generally know what you're talking about, it doesn't matter much, I think. We can simply agree to not discuss this topic where you (apparently) go emotionally overboard. > world" way. You are not alone in this - there are other numpties who > insist on adding "::std::" to everything, or who post with a layout and > spacing style that is, to be diplomatic, "unique". Yes, the matter of style and how that's perceived, that's a valid point. Still that is only vaguely associated with the usefulness or not of restricting oneself to C++ template notation for pointer declarations. Which by the way is objectively a constraint on the notation, not a different notation. Though it may look different in style. I know of no other way to use prefix `const` consistently, disregarding the to me abhorrent practice of /naming/ every part. > language - not what you personally believe to be the "best" language. > If that means posting code in a style that you consider sub-par, then > that is what you do. But here you go again, with a groundless accusation. And an apparent quote that isn't a quote. I'm just mentioning it in order to not let it go by unchallenged as an apparent truth, because it's a more personal thing. Such accusations (and the self-contradictions, and the fallacies, and...) mean that you not only fail to see things as they are, the usual blindness effect, but also see things that don't exist. We should not discuss this further. > Of course you can then have your own threads extolling the virtues of > your methods - they are interesting in their own rights, just not > usually as answers to other people's queries. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Jul 17 08:17AM +0200 On 17/07/2019 07:06, Alf P. Steinbach wrote: <snip> I think I'll leave it at that. Hopefully the next time we correspond in a thread, things will go better. mvh., David |
| Juha Nieminen <nospam@thanks.invalid>: Jul 17 07:24AM > Neither B nor BCPL had types. C was originally "B with types". Is that the reason why in pre-standard C specifying types was optional, and if you didn't specify them, they defaulted to int? |
| Juha Nieminen <nospam@thanks.invalid>: Jul 17 07:25AM > For example, especially Juha and Mr. Fibble in this group complain > strenuously about my sometimes use of `P_<Type>` rather than `Type*`, I have never done such a thing. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 17 12:53PM +0100 >> Neither B nor BCPL had types. C was originally "B with types". > Is that the reason why in pre-standard C specifying types was > optional, and if you didn't specify them, they defaulted to int? Almost certainly. In B you'd write auto a, b, c; in a function a just a, b, c; at file scope. I am sure it was considered a good idea to be able to convert B programs to "new B" and later to early C with as few edits as possible. -- Ben. |
| scott@slp53.sl.home (Scott Lurndal): Jul 17 02:03PM >> compiled by a C++ compiler, assuming one goes to the bother of finding >> and downloading your library, is irrelevant. >The first sentence contains two assertions, both incorrect. I will admit that I also ignore your code as not useful and your coding style as baroque and unreadable. So at least two people in the group ignore your code when it contains your special language. I believe David's assertion to be correct in this case. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 17 07:36AM > outside a copy by-value of the built object to the caller, > placed "partially" on the stack, the final copy will be > shallow or deep ? It's up that type returned by that function how it behaves when copied. For example, if the returned type is std::vector, copying it will make a deep copy (although in this case that will most probably be skipped because of return value optimization). If the returned type is std::shared_ptr, copying it will, essentially, be a shallow copy (the managed object will not be copied; all std::shared_ptr instances copied from the original will share the same managed object). If it's your own type, your own class, that's being returned, then it's up to you how it behaves when copied. The first part of your question is completely unrelated to this and I don't really understand why you think it's relevant. It doesn't matter *where* that function is called from. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 17 01:41AM -0700 On Tuesday, 16 July 2019 15:37:32 UTC+3, Soviet_Mario wrote: > of the) built object ? > In this case, the inefficient COPY-constructor would not be > invoked ... Yes, there is hidden parameter pointing at uninitialized memory. > > The function is allowed to construct the object that it is going > > to return at that address and so elide copying when returning. > intresting ... I knew nothing about this mechanism Also where copy elision is allowed but compiler does not find a way to elide copy there it is typically required to move if move constructors are available. Read that too, it is less formal and accurate but bit easier to read than standard: https://en.cppreference.com/w/cpp/language/copy_elision > I thought (wrongly) it would have been invoked also in > returning objects on the stack. But if this does not happen, > much better ! I meant that people sometimes add side effects to their copy/move constructors and destructors. For example output to some log. Then are surprised to not see the log entries they expected. > > has become quite complicated topic. > I was afraid so, but I have to do some MyString class, and > there the dynamic management is unavoidable I fear Usual advice is to use standard library classes (like std::string) as data members (or sometimes as private bases) of your class. These do memory management for you and so you have to write only the special functionality of your MyString. > > "rule of five", "rule of zero" and "rule of four (and half)". > I had just read about resource acquisition is > initialization. Never heard of the other bibl. For historic reasons the C++ compiler generates some public code for classes implicitly (if it can). That code can be correct or incorrect depending on logic of class and so people have made rules how to ensure that it does not cause any issues. > HAS-A pattern, which I'm more confident of) > actually I'm using C++ more like "a better C" and little > more, or C-with-templates. When you work alone then it is fine, but success is easier to achieve when using code written by others and so cooperating with others. |
| 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