- initialization and copying of class array member - 11 Updates
- C++ move constructors - 1 Update
- C++ condition variable confusion - 6 Updates
- Need help understanding code segment - 1 Update
| Ralf Goertz <me@myprovider.invalid>: Mar 18 08:49AM +0100 Am Sun, 17 Mar 2019 21:26:10 +0000 > I just planted a C-style array because it was the only thing that > could be constexpr. (I wanted a map, but as it's rarely used I felt > the cost of copying it to the heap wasn't worth the RAM). Hm, constexpr std::array<int,3> a{{3,42,1}}; seems to be compiling fine whereas constexpr std::array<std::string,3> b{"3","42","1"}; gives error: the type 'const std::array<std::__cxx11::basic_string<char>, 3>' of constexpr variable 'b' is not lite ral but so does constexpr std::string b[]{"3","42","1"}; I don't see a difference. Did I misunderstand? |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 18 11:01AM On Mon, 18 Mar 2019 08:49:52 +0100 > but so does > constexpr std::string b[]{"3","42","1"}; > I don't see a difference. Did I misunderstand? A constexpr variable must be a literal type. std::string is not a literal type. int (and const char* instantiated with a C literal string) is a literal type. So is a C array of literal types; and as I understand it also a std::array of literal types, because std::array is an aggregate type with implicit destructor. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 18 04:19AM -0700 On Monday, 18 March 2019 13:01:42 UTC+2, Chris Vine wrote: > string) is a literal type. So is a C array of literal types; and as I > understand it also a std::array of literal types, because std::array is > an aggregate type with implicit destructor. It is may be worth to note that std::string_view is literal type that gets common use-cases covered. Like: #include <iostream> #include <string> #include <array> constexpr std::array<std::string_view, 3> arr{"3","42","1"}; int main() { for (auto s : arr) { std::cout << s << std::endl; } } |
| "Öö Tiib" <ootiib@hot.ee>: Mar 18 04:48AM -0700 On Sunday, 17 March 2019 23:26:17 UTC+2, Vir Campestris wrote: > I just planted a C-style array because it was the only thing that could > be constexpr. (I wanted a map, but as it's rarely used I felt the cost > of copying it to the heap wasn't worth the RAM). If you need examples of how to make (compile time comparable, searchable and foldable) maps then Boost.Hana contains one. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 18 08:14AM -0400 > only work for contained objects where it can set their allocator which means > you could end up with a bit of a mess memory wise with the array itself on > the heap but contained objects having storage on the stack. Unlike most of the other standard containers, nowhere in the description of std::array is any mention made of an allocator. It's class template does not take any Allocator type argument, None of it's member functions takes an allocator argument or returns an allocator reference. That's as close as C++ ever comes, for any type, to specifying that memory is not dynamically allocated by this class. Because of what the standard does NOT say about such things, a conforming implementation could still allocate the memory dynamically, but the nature of this class provides no obvious reason to do so. |
| johnbenny@nowhere.co.uk: Mar 18 12:54PM On Sun, 17 Mar 2019 18:34:40 +0100 >you learning from? >You've been taught a load of bollocks. >It can be very useful to the community to learn how that came about. Note to self - don't post when its late. Swap heap and stack in that post. |
| Ralf Goertz <me@myprovider.invalid>: Mar 18 02:46PM +0100 Am Mon, 18 Mar 2019 11:01:21 +0000 > string) is a literal type. So is a C array of literal types; and as I > understand it also a std::array of literal types, because std::array > is an aggregate type with implicit destructor. I still don't get what you are saying. Assuming the "it" on the penultimate lines is supposed to be an "is", aren't you claiming now that a C array of const char* and array<const char *,int> can both be constexpr? How does this relate to your previous statement?: >>> I just planted a C-style array because it was the only thing that >>> could be constexpr. (I wanted a map, but as it's rarely used I felt >>> the cost of copying it to the heap wasn't worth the RAM). In fact, both lines below compile just fine. constexpr std::array<const char*,3> b{"3","42","1"}; constexpr const char* c[]{"3","42","1"}; |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 18 01:57PM On Mon, 18 Mar 2019 12:54:49 +0000 (UTC) > >You've been taught a load of bollocks. > >It can be very useful to the community to learn how that came about. > Note to self - don't post when its late. Swap heap and stack in that post. Whichever way around you meant it, you still have something not quite right in your mental image of this. For the future, (a) if you want to put stack-allocated objects into a container allocated on the heap and have their lifetime tied to the lifetime of the container, copy or move the objects into the container (C++ is pass by value), and (b) if you want to put heap-allocated objects into a container allocated on the stack and have their lifetime tied to the lifetime of the container, pass them by std::unique_ptr, std::shared_ptr or some other handle class. Case (b) (the one which you now say you intended to refer to) happens but is not as common in idiomatic C++ as you might think because, with C++11 move semantics, most classes comprising internals allocated on the heap come with moveable value-type wrappers. An example is std::string: subject to the small string optimization, the bytes of the underlying string are allocated on the heap but the std::string type is a type which can be moved into a container in a way which amounts to a passing of internal pointers together with an internal int or two. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 18 02:10PM On Mon, 18 Mar 2019 14:46:21 +0100 > penultimate lines is supposed to be an "is", aren't you claiming now > that a C array of const char* and array<const char *,int> can both be > constexpr? I am saying that, yes, provided they are initialized by a C string literal. (For what it is worth, the 'it' is correct gramatically - there is an implicit repeat of the "so is" from the preceding part of the sentence, which is a form of elision which maybe does not exist in German.) > How does this relate to your previous statement?: I didn't make a previous statement. I was answering what I perceived to be your perplexity over the fact that std::array<int,n> could be constexpr but std::array<std::string,n> could not. If that is not what you meant then I don't understand your post. > In fact, both lines below compile just fine. > constexpr std::array<const char*,3> b{"3","42","1"}; > constexpr const char* c[]{"3","42","1"}; Indeed they do, as they should, because they are initialized by C string literals. |
| Ralf Goertz <me@myprovider.invalid>: Mar 18 04:34PM +0100 Am Mon, 18 Mar 2019 14:10:09 +0000 > implicit repeat of the "so is" from the preceding part of the > sentence, which is a form of elision which maybe does not exist in > German.) Yes, thanks. I shouldn't try to correct a native speaker. After rereading your sentence I fail to see what was bugging me in the first place. > > How does this relate to your previous statement?: > I didn't make a previous statement. I am sorry, you're right, that was Andy. > that std::array<int,n> could be constexpr but > std::array<std::string,n> could not. If that is not what you meant > then I don't understand your post. Actually, I was not perplexed about that. I merely wanted to give examples of what can and what cannot be constexpr and state that I found no difference between the two with respect to C and C++ style arrays. My confusion was and remains to be what Andy said. The answer to you is irrelevant as I thought I was talking to Andy. |
| Vir Campestris <vir.campestris@invalid.invalid>: Mar 18 09:26PM On 18/03/2019 07:49, Ralf Goertz wrote: > but so does > constexpr std::string b[]{"3","42","1"}; > I don't see a difference. Did I misunderstand? Interesting. IIRC (and I don't have the code to hand) it was std::array<std::pair<const char*, enumtype> , 8> lookup = {{"a", ea}, {"b", eb} (etc) OTOH for various reasons we're on GCC 4 (yes, FOUR!) and some of us are trying to drag the codebase kicking and screaming into the modern age. Perhaps it was the old compiler. Andy -- (The code is at work, and I'm at home now) |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 18 09:46AM -0700 >>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>>>> C++17 has guaranteed copy construction elision, where earlier >>>>> standards just /permitted/ it. [..long discussion..] >> I would be interested to hear what you find out. > I think you'd better check Stack Overflow for an answer about how the > wording works. My experience with stackoverflow is that it's a pretty mixed bag. In this case though looking at stackoverflow led me pretty quickly to a particular page on cppreference, which definitely helped. Thank you for making the suggestion. > function produce a certain commonly known result (which is what you > actually need), then you're in the in-group, e.g. SO-recognized C++ > language lawyers. I have only just started looking into this in detail, but my impression so far is that the confusion is largely historical in making. > But from my point of view that's a silliness, and there's no honor in > being in that group. I don't pretend to understand the social norms on stackoverflow. If I can find what I'm looking for, that's fine, I'll take it, and otherwise it's off to look in other venues. |
| Sam <sam@email-scan.com>: Mar 17 09:04PM -0400 > >This is a MIME GnuPG-signed message. If you see this text, it means that > >your E-mail or Usenet software does not support MIME signed messages. > Perhaps don't use MIME in usenet. We use MIME in the 21st century. |
| Sam <sam@email-scan.com>: Mar 17 09:07PM -0400 > needed? > If I didn't understand why its needed sammy my little friend, I wouldn't be > trying to use it. Just a few minutes ago you wrote: "I still don't see the point of the above loop." So you still don't understand it, apparently. That's ok, someday you will. It took me only a few minutes to figure it out, the first time I encountered this topic, a long long time ago, in a galaxy far, far away. But not everyone is as smart as me. |
| Sam <sam@email-scan.com>: Mar 17 09:12PM -0400 Ben Bacarisse writes: > > child thread: > > while(!pred()) wait(lock); > You may have got confused because of the term "condition variable". Nah. He's not confused. He's just butthurt because C++ is hard to learn, and hard to use correctly; and he wishes it that C++ was much easier, and much simpler. He was under the impression that one can slap together random pieces of C++ in random order, and as long as it compiles correctly it will work exactly as intended, bug-free. But it's not exactly turning out according to plan, and the dream of becoming an elite C++ uberhacker overnight is proving to be quite elusive; hence the butthurt. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 18 01:35AM > He's just butthurt because C++ is hard to learn, and hard to use > correctly; and he wishes it that C++ was much easier, and much > simpler. I disagree, but that's not really important because Usenet works best when replies might be useful to more people than the one person the reply appears to be to. -- Ben. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 18 03:01AM -0700 > >and/or pipes. These work great with threads as well. > They do, but using them means you get the extra complexity of their API > without the safety that seperate processes provide. What you mean by complexity? Message queue is most conceivable for human brain way to communicate between active threads. It is general case: potentially lot of messages, from potentially several threads, losslessly to one thread. Every other synchronization element can be viewed as special (constrained or relaxed) case of it or as component for building such. Separate processes just make it harder to violate that logic. The "safety" when we use multiprocessing instead of multithreading is against ourselves and unfortunately there are no silver bullets against ourselves. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 18 11:54AM On Sun, 17 Mar 2019 21:12:42 -0400 > exactly as intended, bug-free. But it's not exactly turning out > according to plan, and the dream of becoming an elite C++ uberhacker > overnight is proving to be quite elusive; hence the butthurt. I think this elitist meme is misplaced. Bear in mind that there are some language communities which consider that those who program in C++ are neanderthals because of the language's verbosity, weak type system and/or difficulty in expressing some abstractions succinctly. C++ as a programming language is considerably less popular than it once was, probably in part because of these things (the prevalence of garbage collection these days has probably also played a part). The problem with learning to use condition variables (and for that matter, windows event objects) correctly is that writing any multi-threaded application with shared mutable state is difficult, and more so when using primitives like condition variables and mutexes (and even more so when using atomics). rust seems to be the latest attempt to improve the concurrency experience for shared state, with its linear/affine type system. Go's built-in message passing and coroutines (goroutines) are also interesting. and Erlang has had message passing as a core language concept from the outset. |
| Peabody <waybackNO584SPAM44@yahoo.com>: Mar 18 12:17AM -0500 I was able to contact the guy who posted the Github repo on Scripter, and he agreed to compile the new version. We've done one attempt, and have one bug to fix. It looks promising. |
| 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