- How to concat two constexpr c-string? - 9 Updates
- What is visitor pattern? - 13 Updates
- Sieve of Eratosthenes - 3 Updates
| wij <wyniijj5@gmail.com>: Aug 26 03:01AM -0700 constexpr const char K1[]="abc"; constexpr const char K2[]="efg"; constexpr const char K3[]= ??? // "abcefg" expected I'd like K3 to be "abcefg", how should I do? |
| "Öö Tiib" <ootiib@hot.ee>: Aug 26 03:44AM -0700 On Saturday, 26 August 2023 at 13:01:52 UTC+3, wij wrote: > constexpr const char K2[]="efg"; > constexpr const char K3[]= ??? // "abcefg" expected > I'd like K3 to be "abcefg", how should I do? You can not make any functions that return char array (or whatever other raw array) so there are no way. Raw arrays can't be passed by value in C++. You can make std::array compile time as it can be passed. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 12:51PM +0200 Am 26.08.2023 um 12:01 schrieb wij: > constexpr const char K2[]="efg"; > constexpr const char K3[]= ??? // "abcefg" expected > I'd like K3 to be "abcefg", how should I do? Not quite what you're looking for, but would you be happy with it? #include <string_view> constexpr char const *concatted = "abcdefg"; constexpr std::string_view first( concatted, 3 ), second( concatted + 3, 3 ); |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 01:15PM +0200 Am 26.08.2023 um 12:51 schrieb Bonita Montero: > constexpr std::string_view > first( concatted, 3 ), > second( concatted + 3, 3 ); Or more C++-ish: constexpr std::string_view concatted( "abcdefg" ), first( concatted.data(), 3 ), second( concatted.data() + 3, 3 ); |
| wij <wyniijj5@gmail.com>: Aug 26 06:17AM -0700 On Saturday, August 26, 2023 at 6:44:44 PM UTC+8, Öö Tiib wrote: > You can not make any functions that return char array (or whatever other > raw array) so there are no way. Raw arrays can't be passed by value in C++. > You can make std::array compile time as it can be passed. I saw an example made for C++11, it looked strange... I don't have any idea: (can I make the initialization of str3 successful?) //------------- // copy from https://juejin.cn/s/c%2B%2B%20concat%20constexpr%20string%20literals // #include <iostream> constexpr const char* operator+(const char* lhs, const char* rhs) { int size_lhs = 0, size_rhs = 0; while (lhs[size_lhs] != '\0') ++size_lhs; while (rhs[size_rhs] != '\0') ++size_rhs; char* result = new char[size_lhs + size_rhs + 1]; int i = 0; for (; i < size_lhs; ++i) result[i] = lhs[i]; for (int j = 0; j < size_rhs; ++j, ++i) result[i] = rhs[j]; result[i] = '\0'; return result; } int main() { constexpr const char* str1 = "hello"; constexpr const char* str2 = " world"; constexpr const char* str3 = str1 + str2; std::cout << str3 << std::endl; return 0; } |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 03:22PM +0200 Am 26.08.2023 um 15:17 schrieb wij: > result[i] = '\0'; > return result; > } Why do you make a function calling new constexpr ? |
| wij <wyniijj5@gmail.com>: Aug 26 06:33AM -0700 On Saturday, August 26, 2023 at 9:22:18 PM UTC+8, Bonita Montero wrote: > > return result; > > } > Why do you make a function calling new constexpr ? 1. I am not familiar with "constexpr" 2. The example is found on https://juejin.cn/s/c%2B%2B%20concat%20constexpr%20string%20literals , not made by me 3. I want the initialization effect like the str3 in the example |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 03:57PM +0200 Am 26.08.2023 um 15:33 schrieb wij: > 1. I am not familiar with "constexpr" There are three constexprs: 3. If you declare a function constexpr the compiler is requested to compile-time evaluate the function if possible. If you have a dynamic memory allocation that couldn't be compile-time evaluateable. 1. If you declare a variable constexpr the value assigned to it must be compile-time evaluateable. Functions used to initialize the variable must be constexpr and actually compile-time evaluatable. 2. If you have an if constexpr( expr ) expr must be compile-time evaluateable. Functions called by expr must be also compie-time evaluateable like with 2. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Aug 26 10:04PM +0200 On 2023-08-26 12:01 PM, wij wrote: > constexpr const char K2[]="efg"; > constexpr const char K3[]= ??? // "abcefg" expected > I'd like K3 to be "abcefg", how should I do? It depends on your requirements. If you're free to use the preprocessor you can do simply #define K1 "abc" #define K2 "efg" #define K3 K1 K2 constexpr auto& k1 = K1; constexpr auto& k2 = K2; constexpr auto& k3 = K3; Easy peasy. :-) - Alf |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 26 12:55AM -0400 Öö Tiib wrote: >> the actual logic visit(C), at which the programmer is likely to focus, >> is written all right). > Can't. ??? You forgot to add accept function to C. Then your object of dynamic type C will be happily dispatched to VisitorX::visitElementA by A::accept. You can not leak knowledge of particular operation implemented > same for A and B and different for C and D. You can only leave out > handling of D in derived visitor if D is never processed by that visitor, > so std::abort() suits you. what do argue against? > are still real in real projects, and ignoring these is called code smell. > I can not be expected to teach all that knowledge of decades in one post. > Lets take step by step? You are still to provide an example. For now, there nothing to take apart step by step except for my code that you are not even trying to take apart. > ... while third does not want information about D to be ever sent to it. > Now you have 3 different visitors making XML for each endpoint and any > logic in base visitor about first hurts other two. What does your "Because" refer to? There is no "why" in my text (and no question mark at all). I thought you disliked walls of words? What are "endpoints"? I do not understand what "make XML for an endpoint" means. I likely format XML to whatever output stream the visitor caller provides. If that stream is an endpoint, what significance it has to this discussion? >> let's not argue with anything I did not say, it's really irritating, I >> will gladly give you an example, just explain why {ABCD} above is no good. > I tried to. No, your words above do not refer to my argument even grammatically. >> solution. > True about adding virtual method, just that adding 3 virtual functions for XML > generation code into every class will clutter code of those classes. You are essentially repeating arguments for Visitor from advantage/drawback statements on my first post. What purpose is this repetition supposed to serve in this discussion? > Especially if you want (some of) same classes to be used in other project > that does not communicate with said end-points at all. what is "end-points"? I am addressing every your point but your "responses" don't even refer to mine. Can you keep to the point and not go on tangents please? I will make last honest effort to structure this discussion to something legible: do you agree that we disagree on the following points: 1. That my examples demonstrate adding an op to a correctly built Visitor pattern, assuming verbally described scaffolding (I say yes, you say no) 2. That any correct implementation of a Visitor pattern in C++ shall use that specific implementation of DD that GoF and Wikipedia happen to use. (I say no, you say yes) ? It is the implication of my opinions on #1 and #2 above that Visitor can be tought on smaller and more to-the-point examples. But we don't need to argue about this until we put to bed #1 and #2. Agree? >>> case over type, so that kind of victory wasn't achieved. >> There is no such thing as "coupling in general". > Where I said the quoted text "coupling in general"? What you mean by it? You mentioned coupling without specifying what particular coupling you meant in what particular code so it is impossible for me to guess what you mean. Therefore I reasonably called your reference to coupling as reference to "coupling in general". > And why you switch to visitors when discussing benefits of virtual > methods? It was you who went on tangent about virtual functions asking me to think why "virtual methods were added" and then provided incorrect answer to your own question. I simply corrected that incorrect answer of yours. > visitor only once to every class visited, no need to add 3 virtual methods to > generate XML for 3 different endpoints. But can't simplify from there, > otherwise the pattern is broken. Another bareword. How exactly this breaks the pattern? Does operation start to behave not as specified? -- IMO, no. Do we introduce extra participant to the pattern to "save" the desired behavior by adding extra entity? -- IMO, no. Do we force a compilation unit depend on more entities? -- IMO, no. So, what exactly do we break? >> further operations adds zero dependencies, don't require recompilation. > No class needs to be recompiled when 4th server needing obscure > abomination of JSON is added. When did I say the opposite? I just counted the number of dependencies (that have to be there from the outset). Every type in the hierarchy becomes dependent on any other type because its accept method depends on AbstractVisitor and it has methods dependent on every type in the hierarchy, at least its forward declaration. This may be also true for my approach if specific type implementation is dispatched with virtual cast function (because we need to define them at the base class) or not if we use typeid or enum or pattern matching. > you, you are not NYSE that financial institutions themselves have to care how > to be conformant with. You are probably sucking the client-side butt holes of > theirs. See below why you are likely NYSE if you care about supporting different financial institutions. > banks (even in multiple countries)? I suggest urgently to read up on > Silicon Valley Bank, Signature Bank, First Republic Bank and Heartland > Tri-State Bank ... your bank may be next. Is your purpose to throw as many tangents as needed to get me confused? If I have account in a couple of banks, am I suppose to write a program to do my banking? >>>> calling combinations of virtual functions *from within the top-level >>>> method implementing the operation*) >>> That is not use-case of visitor pattern. Bareword again. Nowhere in Visitor pattern rationale and motivation does it say that it should only be used when the behavior of an op on different hierarchy types should not have commonalities. All it says that operations are unrelated one to another. One actually has to expect there will be commonalities on applying an op to objects of different types of the hierarchy; else why are these types are in this same hierarchy? >> many operations. I do not intend to repeat this again unless you provide >> good reasoning. > I did, you just do not read. I read everything your wrote. >> articles use same "Asteroid-Spaceship" example (DD) to exemplify either. > Wikipedia is correct, but multiple dispatch is way over head when you can't > apparently figure what is double dispatch ... so go not into multiple. Who does not read here? Trying once again: WIKIPEDIA C++ EXAMPLES ON MD ACTUALLY DEMONSTRATE DD. How can a simple example of MD that is DD be over head if you insist that another example of DD (actually, implemented in a messier manner) has to be understood first? >> there is usually more functions to write; but otherwise, nothing too >> exciting. > You can't understand rectangle yet so parallelepiped is way too early. Now your are convincing. >> Visitor pattern in C++" is boring and error-prone enough (see above >> about maintenance) to not be the first choice in explaining Visitor. > Then you are out of luck hah? > as you talk about something that is not visitor > pattern. I do not talk about a particular implementation of it that you are so fond of, correct. > function. The visitor takes the instance reference as input, and implements > the goal through **double dispatch**." > You argue with that and GoF not me. where? You should have emphasized the word "appropriate" rather than "all". Double dispatch is correctly emphasized, but your fondness to one particular kind of it does not mean there is no others. > programming language. Don't confuse unrelated paradigms into > visitor that is pattern of object-oriented programming and uses double > dispatch. They are only unrelated in your mind. Design patterns are not libraries, they can be implemented in different ways and in different paradigms. > dc.drawRedRectangle(br); > } > Can easily transform into free function if Shape is bad place. You do repeat.. my code. Where is your beloved DD now? All of a sudden you are checking the shape type with isConfexPolygon(). Makes sense, you are beginning to get it. Although it is unclear why assert(isOval()); is not supposed to fire so you have some work to do. >> particular implementation as ff it were the definition. > It is multiple dispatch, but do not go there as multiple dispatch you can't > grasp yet. very convincing. hominem unius libri timeo >> and textures from an example on visitor? You are welcome to provide your >> own code (the above does not work). > It was doing exactly same as your posted code. What is that "it"? One more nonsense and plonk your posts. >> expect, not providing a single complete counterexample for the same problem. > The visitor pattern examples are present in GoF book and in Wikipedia > article. You argue with those, what is the point of me adding one more? [plonked] |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 26 01:05AM -0400 Bonita Montero wrote: > I suggested a way to make the vistitor pattern implementable with much > less code and more maintainable. The visitor neither need an addtional > base-class and implementation class. Visitor does not need anything, it simply solves a particular class of problems that happens to include a structure of objects of multiple types. Your visitor implementation is invalid if it cannot solve a valid visitor problem. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 26 01:17AM -0400 Michael S wrote: > After trying, with limited success, to follow the discussion between Öö Tiib and Pavel, > I am coming to conclusion that continued ignorance about Visitor Pattern is best both > for my blood pressure and for my programming skills. You are right, no good deed goes unpunished. I should have known better. -Pavel |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 09:24AM +0200 Am 26.08.2023 um 07:05 schrieb Pavel: > of problems that happens to include a structure of objects of multiple > types. Your visitor implementation is invalid if it cannot solve a valid > visitor problem. Either I didn't describe the difference to what you imagine correctly or you just didn't understand me. In the Visitor pattern, the Visitor needs a base class with a virtual method to derive from, and the derived object is passed by reference to the Visitor function of the objects being visited. However, the derived and the base class are superfluous with functional programming. Since C++11 you can simply request a function<> object and conveniently you just pass a lambda that when called, a temporary function<> object is created that represents the interface to the object that can be visited. |
| Muttley@dastardlyhq.com: Aug 26 08:01AM On Sat, 26 Aug 2023 09:24:35 +0200 >function<> object and conveniently you just pass a lambda that when >called, a temporary function<> object is created that represents the >interface to the object that can be visited. This sort of programming is the equivalent of touchscreens in cars - looks great and impresses the "Ooo shiny!" crowd but adds little to the main functionality of the car and just adds needless complexity with more scope for failure. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 11:29AM +0200 > great and impresses the "Ooo shiny!" crowd but adds little to the main > functionality of the car and just adds needless complexity with more scope > for failure. My solution is less complexity because you don't need to declare a base class and a derived class. Just declare the parameter as a function object and pass a lambda which is automatically crated. That's for sure at maximally the tenth of the code. You can have functional programming in C++ since 2011. That's a long time you didn't notice its potential. |
| Muttley@dastardlyhq.com: Aug 26 03:00PM On Sat, 26 Aug 2023 11:29:34 +0200 >That's for sure at maximally the tenth of the code. >You can have functional programming in C++ since 2011. That's a >long time you didn't notice its potential. People who say you can have functional programming in C++ don't understand functional programming. Its more than just no cost recursion , its also polymorphism by *VALUE*. That is not and probably never will be possible in C++. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:08PM +0200 > People who say you can have functional programming in C++ don't understand > functional programming. Its more than just no cost recursion , its also > polymorphism by *VALUE*. ... That's what I described and you didn't notice it. A function<>-object is always polymorphic. I bet you never used function<>-objects in C++. |
| Muttley@dastardlyhq.com: Aug 26 03:15PM On Sat, 26 Aug 2023 17:08:15 +0200 >> polymorphism by *VALUE*. ... >That's what I described and you didn't notice it. A function<>-object >is always polymorphic. I bet you never used function<>-objects in C++. Given they're necessary for the STL what do you think? Which part of "by value" is confusing you? But if you insist on claiming its possible show us how you'd do polymorphism for a function with a single int param for say the values 0, 2, 3, 10 -> 100 and a default. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:24PM +0200 > Which part of "by value" is confusing you? But if you insist on claiming its > possible show us how you'd do polymorphism for a function with a single int > param for say the values 0, 2, 3, 10 -> 100 and a default. You can't describe what you want and you don't understand function<> -objects. Stick with C. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:26PM +0200 > Which part of "by value" is confusing you? But if you insist on claiming its > possible show us how you'd do polymorphism for a function with a single int > param for say the values 0, 2, 3, 10 -> 100 and a default. Somehow you are also quite disturbed. I wanted to tell nru that the visitor pattern in C++ can be greatly simplified with a c++11 function<> object and you are offended by this mere statement that you have to explain the possibilities of C++11 as insufficient at this point to put you above me. The therapist that matches you has yet to be born. |
| Muttley@dastardlyhq.com: Aug 26 03:36PM On Sat, 26 Aug 2023 17:24:00 +0200 >> param for say the values 0, 2, 3, 10 -> 100 and a default. >You can't describe what you want and you don't understand function<> >-objects. Stick with C. Translation: I can't do it because its not possible but don't have the balls to admit I was wrong. Go back to writing your next piece of lame shit code to post on here in order to show off. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:39PM +0200 >> -objects. Stick with C. > Translation: I can't do it because its not possible but don't have the balls > to admit I was wrong. Of course I can't do that because your requirements are too diffuse. |
| Muttley@dastardlyhq.com: Aug 26 08:03AM On Fri, 25 Aug 2023 18:18:09 +0200 >>> Comment it and show that you understand it. >> Sorry pal, ... >That's what I expected. The arrogance that you expect people to have to figure out your code then comment on it is quite breathtaking. >> If you work for a fintec then I pity the devs who will have to maintain >> your code in the future. More than likely they'll toss it and start again. >The company I work for has more skilled staff like you. Ah, you think you're so much better than everyone else there. What a surprise. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 10:16AM +0200 >>> your code in the future. More than likely they'll toss it and start again. >> The company I work for has more skilled staff like you. > Ah, you think you're so much better than everyone else there. What a surprise. Stick with your C code and continue to ask beginner's C++ questions. |
| Muttley@dastardlyhq.com: Aug 26 08:27AM On Sat, 26 Aug 2023 10:16:48 +0200 >> Ah, you think you're so much better than everyone else there. What a >surprise. >Stick with your C code and continue to ask beginner's C++ questions. Do carry on with your pompous assery, I'll get some popcorn :) |
| 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