- "Is C++ fast?" - 8 Updates
- Initialization in modern C++ - Timur Doumler - Meeting C++ 2018 - 2 Updates
- Inherited enum - 7 Updates
| Daniel <danielaparker@gmail.com>: Jan 26 03:50PM -0800 On Saturday, January 26, 2019 at 5:58:16 PM UTC-5, Mr Flibble wrote: > should normally be a problem: I only use Boost for features that C++17 > doesn't provide namely Boost.asio and pool allocators which are fairly > stable modules. My observation is that a minuscule number of open source projects become widely popular. A larger but still tiny number achieve some viability, with a modest number of downloads per week, some activity in the issues log, and generating some goodwill for filling some niche not addressed elsewhere. But the vast majority, I would guess over 99 percent, have no users and generate no interest. And that's not to say they're bad either. It's just that the supply of free software vastly exceeds the demand. But even "idiots such as myself not getting C++", as you say, can recognize that you put a huge amount of effort into neolib, and wish you success. Never having gotten beyond the "some viability" level myself, my advice may be of limited value, but I would still encourage you to think about packaging at least a part of neolib without dependencies. Best regards, Daniel |
| woodbrian77@gmail.com: Jan 26 03:57PM -0800 On Saturday, January 26, 2019 at 4:58:16 PM UTC-6, Mr Flibble wrote: > doesn't provide namely Boost.asio and pool allocators which are fairly > stable modules. > With the advent of CMake header-only libraries are less important these days. It sounds like someone needs to get a life. Brian Ebenezer Enterprises http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 27 12:39AM On 26/01/2019 23:50, Daniel wrote: > My observation is that a minuscule number of open source projects become > widely popular. A larger but still tiny number achieve some viability, with a modest number of downloads per week, some activity in the issues log, and generating some goodwill for filling some niche not addressed elsewhere. But the vast majority, I would guess over 99 percent, have no users and > generate no interest. And that's not to say they're bad either. It's just that the supply of free software vastly exceeds the demand. But even "idiots such as myself not getting C++", as you say, can recognize that you put a huge amount of effort into neolib, and wish you success. Never having gotten beyond the "some viability" level myself, my advice may be of limited value, but I would still encourage you to think about packaging at least a part of neolib without dependencies. Calling you an idiot was a natural reaction to someone saying Java is better than C++ in a C++ newsgroup; whether I actually think you really are an idiot is a different matter. The amount of effort I have put into "neolib" pales in comparison with the amount of effort I have put into "neoGFX" which has "neolib" as a dependency. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 27 12:40AM >> stable modules. >> With the advent of CMake header-only libraries are less important these days. > It sounds like someone needs to get a life. Your god doesn't exist you egregious Christian cunt. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Daniel <danielaparker@gmail.com>: Jan 26 04:59PM -0800 On Saturday, January 26, 2019 at 7:39:48 PM UTC-5, Mr Flibble wrote: > Calling you an idiot was a natural reaction to someone saying Java is > better than C++ I made no such statement. It seems to be the practice in this newsgroup to attribute statements to people that they have not made, and follow up with "you don't get it", or some such. Someone else posted that I am mistaken in my belief that "C++ [is] a language to provide API's for database applications or other specific application domains", a belief I had not known that I held. I have come to the conclusion that this is not a good place to attempt conversations :-) Best regards, Daniel |
| Manfred <noname@add.invalid>: Jan 27 06:26PM +0100 On 1/26/2019 10:44 PM, Daniel wrote: >> It is not the goal of C++ as a language to provide API's for database >> applications or other specific application domains. > I think you're misreading my post, as I at no point suggested that. You have been too quick at dismissing my point, and snipped my argument missing the more relevant part. I'll try to be more clear: You suggested that "a richer type system" would be a useful enabler for vendors to use C++ for "common API's", and you explicitly mentioned database vendors. My point is that for such vendors the tie with the application layer is dominant: that's where they make money. So if the market wants a Decimal type, they'll provide such a type with /some/ internal representation, it doesn't matter /which/ specific representation. C++ as a language (and C as well, for what that matters), and the committee, instead, /is/ interested in what is the specific representation of a native type: such representation is key to performance and efficiency, which is the drive of the language, unlike for commercial vendors. Since most architectures do not provide a Decimal representation at the hardware level, and anyway there is no common such representation among architectures, the language does not provide such a type as a native type. In this context, choosing one representation would possibly be efficient for one architecture, but inefficient for another one or for a future one. At the level of the C++ standard this is not what is wanted. On the other hand, C++ provides all the means to define a Decimal type at the application or library level. As a further consideration, I don't think that there is a real "move away" from C++ by database vendors (to stick with this sample domain). In fact they all provide C API's, that are seamlessly usable in C++, and those are even the first and most common API's that they provide, before Java and C#. The fact that C API's are much more common than C++ ones, probably has to do with the fact that formalizing a C++ API implies some impact on the object model at the application level. I can understand that C++ projects may prefer a neutral API like a C one and keep their hands free in designing their own application object model. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 27 09:48PM +0100 On 27.01.2019 18:26, Manfred wrote: > the object model at the application level. I can understand that C++ > projects may prefer a neutral API like a C one and keep their hands free > in designing their own application object model. It raises the question of what representation common database APIs in the financial world use. To wit, as of early 2019 64-bit IEEE `double` /almost/ does not suffice to represent the foreign debt of the USA to the penny. It's right at the limit today. Next year, or in a few years, it will not suffice. Is this like a year-2000 problem or the C time problem coming up on us? Cheers!, - Alf |
| Daniel <danielaparker@gmail.com>: Jan 27 01:33PM -0800 On Sunday, January 27, 2019 at 3:48:55 PM UTC-5, Alf P. Steinbach wrote: > to represent the foreign debt of the USA to the penny. It's right at the > limit today. Next year, or in a few years, it will not suffice. > Is this like a year-2000 problem or the C time problem coming up on us? COBOL could handle fixed decimal, it just had problems with date. A huge amount of financial software is still COBOL running on mainframes. I know one institution that's becoming concerned, because the author of a COBOL program is retiring, and they don't have the source. Management isn't exactly sure what that COBOL program does, but the business thinks it does something, and won't approve taking it out of commission. In the mid to late eighties when mutual fund and other companies were moving to UNIX/C on RISC, and new SQL DBMS's didn't have decimal or money types, customer balances were often stored in double fields. The issue then wasn't the magnitude of the numbers, but rather rounding. I recall one finance guy would log onto the DBMS every night, use SQL to access customer accounts, and add a few pennies into one account and take a few out of another, to fix up some rounding issues with the software. Today we still have a huge COBOL legacy. Of course all modern DBMS's support fixed decimal and money types, and all modern accounting or portfolio management software uses those types. Fixed decimal is such a pervasive type, and there's so much a prior experience with it, that it would seem to me a thing that belongs in standard C++. I accept that this is not a universal opinion, even if I have some difficulty understanding why. In the meantime I think it's fair to say that authors of accounting and portfolio management software have by and large abandoned C++ as their language of choice. Daniel |
| woodbrian77@gmail.com: Jan 27 11:11AM -0800 I liked this talk: https://duckduckgo.com/?q=meeting+c%2B%2B+2018&t=ffab&iax=videos&ia=videos&iai=ZfP4VAK21zc I watched the first few minutes and the last 12 minutes or so. He talks about going from "almost always auto" to "always auto" with 2020 C++. I think I'm still sometimes auto. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 27 09:54PM +0100 > I watched the first few minutes and the last 12 minutes or so. > He talks about going from "almost always auto" to "always auto" with > 2020 C++. I think I'm still sometimes auto. Some people like simple mechanical fit-all-that-they're-interested-in conventions that they use in a social way: those who don't use that solution are not in the in-group and can be criticized and ridiculed. Ha, you're not using "always auto"! So it's your own fault mate! Cheers!, - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 27 12:51AM +0100 On 27.01.2019 00:09, Chris Vine wrote: >> more values, doesn't produce a derived class but a base class. > I am not sure that is the way to look at it. In terms of variance, an > extension of an enum _would_ provide a sub-type of the enum. I generally disagree, but since C++ enums are very low level it's possible to view a C++ enum type as having all the values possible with the enum's underlying type, just that some values have been named. With that view an extension just provides more value names, and so is essentially equivalent to the enum that it extends. As I think of it the sub/super type concept enters the picture only when a more restricted view of enums is adopted, where each possible value has a single unique name in the enumeration, and each named value has a *meaning*. Then two extensions of enum Base, E1 and E2, can both introduce names for the underlying type's value 42, that's not used in Base. With E1 the name of 42 reflects the meaning "we have lift-off and rocket is away, apply the water cannons", while with E2 the name of 42 reflects the meaning "that dang rocket isn't moving, pump more fuel to it". Maybe function foo, being given E2(42) as actual argument for a Base parameter, and knowing only about the Base values, applies water cannons to the bottom of the rocket that isn't moving yet. Because at the time foo was written, the only Base extension yet was E1. Serious SNAFU. That exemplifies, that if sub-type means that an instance of it can be passed where the formal parameter is of a supertype, then every instance of a sub-type should be an instance of the supertype - more generally, one should be able to treat every instance as an instance of the supertype (this is the good old Liskov substitution principle, the LSP). For enum extensions that's opposite. Ignoring that property you risk getting very mutually incompatible enum extensions used as actual arguments for a parameter of the basic original enum type. > conventional way of looking at your example below is that function > arguments can safely be contravariant but not covariant, and that > return values can be covariant and not contravariant. Pure "in"-arguments can be safely contravariant. They need to be const all the way. C++'s lack of support contravariance is consistent with and in my view connected with its lack of support for designating arguments as "in", "in/out" or "out", except that return values are pure "out". > safe conversions are possible: in the case of enum arguments, any > function which can handle the wider case (the sub-type) can handle the > narrow case (the super-type). Not agreeing with the sub/super designations. With normal object oriented inheritance (or extension, as it's called in Eiffel) of sound design, the extension is a sub-type. That terminology can't be transferred to enums without losing the deeper meaning, the reason that they're called that, namely that any instance of a sub-type can be used where a general instance of the super-type is expected. In this sense the super-type encompasses the sub-type. Every instance of the sub-type IS-A super-type instance; every camel is a mammal, the set of mammals is very much larger than the set of camels. It's not the case that every named value of an extended enum is a named value of the base enum. That relationship goes the other way: every named value of the base enum IS-A named value of the extended enum, so the original base enum is the sub-type, and the extension is the sub-type, in this relationship. > D1 d1; > D2 d2; > d2.do_it(d1); Due to the possibility of pointer data members etc. there is no way for a C++ compiler to see, in general, that `D1 d` designates a pure "in" argument for which contra-variance would be OK. But so much else in C++ puts the burden of being sure, on the programmer, so why not also here? I believe that's because there's been no big need for this feature. > legally in C++. (However you might well be able to prove me wrong on > that - you might be able to do something clever with templates, I am > not sure.) One would need to use some Java-like class based enum lookalikes, with implicit value conversion defined instead of inheritance based reference conversion. It's a problem & solution that pops up with smart pointers, e.g. conversion of `shared_ptr<Derived>` to `shared_ptr<Base>`. You really wouldn't want to have `shared_ptr<Derived>` IS-A `shared_ptr<Base>`... >> Barbara Liskov did discuss this crucial point in her papers about Liskov >> substitution. It's just that those who teach her works generally fail to >> even mention this, like they don't understand how important it is. Cheers!, - Alf |
| Daniel <danielaparker@gmail.com>: Jan 26 04:17PM -0800 On Saturday, January 26, 2019 at 6:20:40 PM UTC-5, JiiPee wrote: > so I am not the only one thinking about this, :) No. You might want to consider subscribing to the Google Group std- proposals@isocpp.org, look up some of the articles discussing the proposal, and contributing some examples along the lines of what the commentator below is asking for: "Mechanically WHAT you are proposing is pretty clear. You need to do a better job on the WHY. Concretely, in your motivation section, I would find and highlight some examples in real world open source code where availability of this feature, if it was used, would make things better." The chances of this proposal going anywhere is small, but your support could make a difference, minute as it may be. Daniel |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 27 12:39AM On Sun, 27 Jan 2019 00:51:33 +0100 > That relationship goes the other way: every named value of the base enum > IS-A named value of the extended enum, so the original base enum is the > sub-type, and the extension is the sub-type, in this relationship. On further thought I agree with you on this. In thinking more about it I have tried to persuade myself otherwise but I keep stubbing my toe on the fact that a narrower enum has stronger invariants than a wider enum: extensible enums would in fact be "open" - so yes, they would be polymorphic - but not in a way which can be modelled by inheritance sub-typing. I also agree that having contravariant function arguments would preclude them being used as out parameters. |
| JiiPee <no@notvalid.com>: Jan 27 08:50AM On 27/01/2019 00:17, Daniel wrote: > The chances of this proposal going anywhere is small, but your support could > make a difference, minute as it may be. > Daniel But, reading that article I am not sure if it can be used "like" polymorhism with classes. So can I do what I did in my original message: ###### enum class AnimationNameBase {NoName}; struct Animation { AnimationNameBase m_name{AnimationNameBase::NoName}; void doAnimation(AnimationNameBase name) { m_name = name; } }; // in another file: enum class PlayerAnimationNames : AnimationNameBase {WalkUp, WalkDown, WalkRight}; ######### So that when I create PlayerAnimationNames I do not need to re-compile the Animation-file? So is PlayerAnimationNames totally independent of the Animation file? Like it is in polymorhism. |
| JiiPee <no@notvalid.com>: Jan 27 08:53AM On 27/01/2019 00:17, Daniel wrote: > No. You might want to consider subscribing to the Google Group std- > proposals@isocpp.org, ok thanks |
| JiiPee <no@notvalid.com>: Jan 27 08:57AM On 27/01/2019 00:17, Daniel wrote: >> so I am not the only one thinking about this, :) > No. You might want to consider subscribing to the Google Group std- > proposals@isocpp.org, As I said, I find myself needing this feature almost in all projects I start. But its possible I should do things differently, but its also possible I really need it, donno ... but I feel like I always need it :). Programmers keep using std::string constants to make ID's for objects, but I would rather use enum class type. But many times cannot do it because with enum class the parent class file needs to be re-compiled when adding new enum values etc. So then have to use old enum's like now (so storing ID's /names as integers and using auto converting from old enums to int's). |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 27 02:09PM On 27/01/2019 08:57, JiiPee wrote: > with enum class the parent class file needs to be re-compiled when adding > new enum values etc. So then have to use old enum's like now (so storing > ID's /names as integers and using auto converting from old enums to int's). IDs for objects or object types? Use uint32_t or uint64_t for object ID and UUID for object type. Enums are hard coded and brittle. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| 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