- Inherited enum - 7 Updates
- "Is C++ fast?" - 11 Updates
| JiiPee <no@notvalid.com>: Jan 26 02:49PM enum which can be inherited would be a cool feature. I need it all the time, like now. Like this: enum class AnimationNameBase {NoName}; struct Animation { AnimationNameBase m_name{AnimationNameBase::NoName}; void doAnimation(AnimationNameBase name) { m_name = name; } }; enum class PlayerAnimationNames : AnimationNameBase {WalkUp, WalkDown, WalkRight}; Then using it: Animation playerAnimation; playerAnimation.doAnimation(PlayerAnimationNames::WalkUp); // code.....then in some function: if(playerAnimation.m_name == PlayerAnimationNames::WalkUp) { // draw walk up } |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 26 07:29PM +0100 On 26.01.2019 15:49, JiiPee wrote: > enum which can be inherited would be a cool feature. I need it all the > time, like now. [snipped example of hypothetical extension of an enum] Well, there is little snag, namely that extension of an enum class, with more values, doesn't produce a derived class but a base class. For example, // Here Wide_enum is a hypothetical extension of Narrow_enum, like, // Wide_enum *inherits* all the values of Narrow_enum & adds more. void foo_narrow( Narrow_enum x ); void foo_wide( Wide_enum x ); void bar() { const Wide_enum ew = Wide_enum::an_extra_value; foo_narrow( ew ); // Oh noes, foo_narrow can't handle that. } void bar_tender() { const Narrow_enum en = Narrow_enum::one_of_the_original_values; foo_wide( en ); // That's OK, foo_wide can handle that! :) } So the enum extension is in a sense the opposite of ordinary inheritance in C++: instead of a specialization, it provides a generalization. There is the same issue with number types, e.g. rational numbers extend and generalize integers, so can't be reasonably modeled as a derived class. I was surprised, half a decade ago or so, to find out that 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 02:51PM -0800 On Saturday, January 26, 2019 at 9:49:34 AM UTC-5, JiiPee wrote: > { > // draw walk up > } There is a proposal for that https://github.com/ginsbach/CppProposal/blob/release_70/ExtendedScopedEnumerations.pdf There was a discussion about that on std-proposals@isocpp.org, which was less than enthusiastic. As Alf notes, it's not inheritance, and it looks strange to use the same syntax as inheritance for what is the opposite relation (the value of the base enum is more constrained, as opposed to a base class that is less constrained.) Daniel |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 26 11:09PM On Sat, 26 Jan 2019 19:29:34 +0100 > [snipped example of hypothetical extension of an enum] > Well, there is little snag, namely that extension of an enum class, with > 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. The more 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. In either case, 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). For virtual functions C++ is invariant on its argument types and covariant on its return types and so sound (on that issue) but more restrictive than necessary. This would be OK type-wise but would not be accepted by C++: class B1 {virtual ~B1();}; class D1 : public B1 {}; class B2 {void do_it(D1 d) {}; virtual ~B2(){};}; class D2: public B2 {void do_it(B1 b) override {};}; // C++ objects D1 d1; D2 d2; d2.do_it(d1); Your bar_tender() is also legitimate type-wise as an example of contravarience but I don't think you can actually write that code 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.) |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 26 11:16PM On Sat, 26 Jan 2019 23:09:30 +0000 > class B1 {virtual ~B1();}; > class D1 : public B1 {}; > class B2 {void do_it(D1 d) {}; virtual ~B2(){};}; That should be: class B2 {virtual void do_it(D1 d) {}; virtual ~B2(){};}; |
| JiiPee <no@notvalid.com>: Jan 26 11:17PM On 26/01/2019 22:51, Daniel wrote: > strange to use the same syntax as inheritance for what is the opposite > relation (the value of the base enum is more constrained, as opposed to a > base class that is less constrained.) oh really? INteresting to know. Would be nice to get something like that.... |
| JiiPee <no@notvalid.com>: Jan 26 11:20PM On 26/01/2019 22:51, Daniel wrote: > relation (the value of the base enum is more constrained, as opposed to a > base class that is less constrained.) > Daniel so I am not the only one thinking about this, :) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 26 08:07AM On Thu, 2019-01-24, Mr Flibble wrote: > Because of idiots such as yourself pushing Java due to not getting C++. > Also, C++ is a much better language now than it was in the 90s; there > wasn't even a C++ standard until 1998. Apart from the ad hominem, how about this expanded theory? In 1996 a lot of people had tried early 1990s C++ either as (a) thinly veiled C or (b) with full Smalltalk-style OOP. I suspect people had failed a lot. Also, new programming languages tended to come from the academic world (and not be useful in practice), or be scripting languages like Perl. Java came from a major company which invested heavily in it, had famous programmers involved, and came with large APIs. That's my theory, but it doesn't feel like an adequate explanation. I haven't done any Java programming, and don't know many Java programmers. One thing Java seems to have is conformity. Java programmers seem to agree on most things; C++ programmers rarely agree on anything. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 26 08:19AM On Fri, 2019-01-25, Daniel wrote: > (1) Pick a standard licensing agreement, such as boost or MIT. People will > feel more comfortable with that. You should have a subset of your work that > you're willing to license that way. Yes please. ... > (3) A lot of people won't use an open source project if it has a dependency > on boost. [citation needed] Why on earth wouldn't they, if they use third-party libraries at all? You can't play it safer than that. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 26 12:10PM +0100 On 26.01.2019 09:07, Jorgen Grahn wrote: > One thing Java seems to have is conformity. Java programmers seem to > agree on most things; C++ programmers rarely agree on anything. That's a crucial element of the mindsets, IMO. With C++ one uses 3rd party libraries, and/or build things from scratch. With Java one uses the language's standard library, a single library with a single way to do most anything a Java programmer wants to do. Cheers!, - Alf |
| Daniel <danielaparker@gmail.com>: Jan 26 03:24AM -0800 On Friday, January 25, 2019 at 4:24:16 PM UTC-5, Vir Campestris wrote: > it have support for something that isn't in the language? > A 3rd party database I'd expect you to have chosen _because_ it has > support for the data type you need. Database vendors typically provide API's that bind to perhaps a dozen different programming languages, and generally restrict themselves to bindings to the standard types in the host language. In languages with richer type systems, such as Java and C#, internal representations of big integer, big decimal, and date/time would be bound to such types. In languages with less rich systems, such as C++, bindings would be limited to strings or perhaps a low level struct, and users left to fend as best they can. It's just one of the factors that accounts for the move away from C++ and to languages that "float better" when interacting with such common API's. That's all. Daniel |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 26 11:50AM > can. It's just one of the factors that accounts for the move away from C++ > and to languages that "float better" when interacting with such common > API's. That's all. Not true/ -- press any key to continue or any other to quit... |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 26 11:50AM > With C++ one uses 3rd party libraries, and/or build things from scratch. > With Java one uses the language's standard library, a single library > with a single way to do most anything a Java programmer wants to do. And that I refuse to program Java in disgust... -- press any key to continue or any other to quit... |
| Manfred <noname@add.invalid>: Jan 26 06:33PM +0100 On 1/26/2019 12:24 PM, Daniel wrote: > can. It's just one of the factors that accounts for the move away from C++ > and to languages that "float better" when interacting with such common > API's. That's all. I think you are misreading what's the role of C++ about API's. It is not the goal of C++ as a language to provide API's for database applications or other specific application domains. It is the role of database vendors to provide C++ APIs if they want to, as well as C, C#, Java and your-favorite-language-of-choice, not the role of the C++ committee. C++ provides a type system whose fundamental elements are tied to the representation of most CPU architectures. On top of that, it does provide all the abstraction infrastructure to build the types required for any application domain. It is not by accident that database services are written in C++. The choice of Java, C# and friends to build a database-friendly type system in the language itself is purely a marketing choice of the vendors of such languages. Unlike C++, that is driven by technology (i.e. performance and efficiency), Sun, Oracle, Microsoft etc. are driven by the market, i.e. sales, which by the way is perfectly reasonable, and thus they favor the width of the audience over technical potential. |
| Daniel <danielaparker@gmail.com>: Jan 26 01:44PM -0800 On Saturday, January 26, 2019 at 12:33:32 PM UTC-5, Manfred wrote: > I think you are misreading what's the role of C++ about API's. > 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. Best regards, Daniel |
| Daniel <danielaparker@gmail.com>: Jan 26 02:14PM -0800 On Saturday, January 26, 2019 at 3:19:19 AM UTC-5, Jorgen Grahn wrote: > [citation needed] > Why on earth wouldn't they, if they use third-party libraries > at all? You can't play it safer than that. It's factual that they wouldn't, which leaves the question as to why. And I think the answer is that people want the libraries that they use to have as few dependencies as possible, and be as convenient to use as possible. That's true even if they were using boost themselves, another library that depended on boost might require a different version. Successful C++ open source libraries such as fmtlib catch, doctest, and nholmann have in common that they are self contained and distributable as header-only libraries, in fact, the four mentioned are distributable as single header-only libraries. Header only libraries have their issues when this is taken too far, but they do sidestep some of the shortcomings of build systems in C++. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 26 10:58PM On 26/01/2019 22:14, Daniel wrote: > And I think the answer is that people want the libraries that they use to > have as few dependencies as possible, and be as convenient to use as possible. That's true even if they were using boost themselves, another library that depended on boost might require a different version. Successful C++ open source libraries such as fmtlib catch, doctest, and nholmann have in common that they are self contained and distributable as header-only libraries, in fact, the four mentioned are distributable as single header-only libraries. Header only libraries have their issues when this is > taken too far, but they do sidestep some of the shortcomings of build systems in C++. Boost is very good at backwards compatibility so different Boost versions 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. With the advent of CMake header-only libraries are less important these days. /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." |
| woodbrian77@gmail.com: Jan 26 03:07PM -0800 On Saturday, January 26, 2019 at 2:19:19 AM UTC-6, Jorgen Grahn wrote: > [citation needed] > Why on earth wouldn't they, if they use third-party libraries > at all? You can't play it safer than that. There's a TV program in the US about shark investors. They routinely want to know "what's proprietary" about this or that. If something isn't proprietary they won't touch it. If you can afford it, go with something proprietary. 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