| Juha Nieminen <nospam@thanks.invalid>: Sep 11 07:34AM > to the constructor. > The base class might then even store the values it is passed and you > don't have to make getValues virtual. There are many such virtual functions, which derived classes can optionally specialize in order to affect how the base class behaves. It wouldn't make much sense to make them all mandatory, and have the base class needlessly increase its own size by storing all of those values within itself (especially since these are often values that are not tied to a specific object, but are the same for all objects of the same derived type.) The values in question shouldn't be added to the public constructor, because they are not a business of the outside code. It's an internal implementation detail. I suppose I could make an overloaded protected constructor just for this purpose, but this is also somewhat dubious design, because I'm now making the protected interface less abstract (from the perspective of derived classes). Now the derived class would need to "know" that the base class requires the value in its constructor. If in the future the base class constructor is changed to require another value, all the derived classes would need to be changed as well (even if that value is one that's already handled by an existing virtual function). It also feels like borderline code repetition (because the derived class needs to be passing the same value to the base class in two places). |
| Juha Nieminen <nospam@thanks.invalid>: Sep 11 07:41AM > One must ask _where_ does the derived class get the values > from? If from the derived constructor, then they could have been > passed to the base class constructor as well. See my other reply for why this just doesn't feen like the best possible design. > after creating the object). As the object is fully realized by > the time the init member is called, the base class init function > can use the virtual functions without issue. The problem is that now the calling code would need to be burdened by having to explicitly call an "init()" function for each object that's created. (It's not possible to have the derived class constructor call it because, remember, the base class can be instantiated itself, and thus it would need to call its own init() function. It would end up being called twice, the first time with the wrong vtable if this is actually a derived class object.) |
| scott@slp53.sl.home (Scott Lurndal): Sep 11 12:50PM >Bjarne discusses some aspects of why the 1990's two-phase construction >solution is bad, in <url: http://www.stroustrup.com/3rd_safe0.html> Bad is your value judgement, not reflected by the reference, which simply generalizes that the two-phase construction paradigm has its own set of constraints that must be worked within while not explicitly acknowleging that such implementations solve viable problems efficiently. >(search the PDF for "init"), but he fails to address why it was so >commonly used, namely to solve your problem in a child's way, sort of. It was used for years before RAII was even a gleam in someone's eye. Calling a child's way is foolish and insulting. |
| scott@slp53.sl.home (Scott Lurndal): Sep 11 12:51PM >The problem is that now the calling code would need to be burdened >by having to explicitly call an "init()" function for each object >that's created. Yes, of course. How is that a problem? |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 11 04:21PM +0300 On 11.09.2017 15:51, Scott Lurndal wrote: >> by having to explicitly call an "init()" function for each object >> that's created. > Yes, of course. How is that a problem? Seconded. There is nothing wrong in using 'init' if the alternatives are worse. If the class is instantiated in many places or you don't like two-line creation code, make a small factory function and call this instead. Cheers Paavo |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 12 12:25AM +0200 On 9/11/2017 2:50 PM, Scott Lurndal wrote: >> Bjarne discusses some aspects of why the 1990's two-phase construction >> solution is bad, in <url: http://www.stroustrup.com/3rd_safe0.html> > Bad is your value judgement, Yes. > not reflected by the reference, Wrong. > its own set of constraints that must be worked within while not > explicitly acknowleging that such implementations solve viable problems > efficiently. Wrong. >> (search the PDF for "init"), but he fails to address why it was so >> commonly used, namely to solve your problem in a child's way, sort of. > It was used for years before RAII was even a gleam in someone's eye. Yes. > Calling a child's way is foolish Wrong. > and insulting. Yes. Cheers & hth., - Alf |
| "K. Frank" <kfrank29.c@gmail.com>: Sep 11 10:18AM -0700 Hi Group! Ping? Why can the outer braces in an std::array brace initializer be elided when the element initializers are variables, but not when they are themselves brace initializers? I tried the code below with another online compiler: https://www.jdoodle.com/online-compiler-c++14 that explicitly claims c++14 support, and I get the same result as reported before. Full details below, but in short: std::array<std::vector<unsigned>, 2> avux {{ vu0, vu1 }}; -- compiles std::array<std::vector<unsigned>, 2> avux { vu0, vu1 }; -- compiles with outer braces elided but std::array<std::vector<unsigned>, 2> avuy {{ { 1, 2, 3 }, { 4, 5 } }}; -- compiles std::array<std::vector<unsigned>, 2> avuz { { 1, 2, 3 }, { 4, 5 } }; -- does not compile with outer braces elided Explained by the language? Bug in g++? Thanks. K. Frank On Monday, September 4, 2017 at 7:43:01 PM UTC-4, K. Frank wrote: |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Sep 10 10:17PM -0700 On 9/10/2017 2:42 PM, Ian Collins wrote: > Don't use preprocessor "constants". > If you are going to use C standard library functions, just use the C > headers. What about: ______________________________ #include <cstdint> #include <cstdlib> #include <iostream> #if ! defined (CT_CLSIZE_DEFAULT) # define CT_CLSIZE_DEFAULT 128 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment