- template declaration synthax - 10 Updates
- "Jonathan Blow: "C++ is a weird mess"" - 1 Update
- Some C++14 code - 8 Updates
- Special link-list algorithm help - 3 Updates
- About Embarcadero and Delphi and FreePascal.. - 1 Update
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 09 10:06PM +0300 On 9.07.2018 21:14, Soviet_Mario wrote: > { > private: > char [Param] zBuf; enum A { small = 512, large = 10000 }; template <A Param> class Buffer { private: char zBuf[Param]; }; int main() { Buffer<A::large> x; } |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 09 09:04PM +0200 On 09.07.2018 20:22, Soviet_Mario wrote: >> ... >> ... >> } For example template< int param > class Buffer ... > I also wanted to ask a question : whether or not (and how) in "plain" > C++ would be possible to specify (always in a template) a typename WITH > RESTRICTIONS (as in VStudio extension). Check out `std::enable_if` & friends. For example, template< class Number, class = enable_if_t< is_integral_v<Number> > auto mod( Number a, Number b ) -> Number { return a%b; } > With restriction I mean, a typename parameter must be within a subset of > types, specified in some form (ex. in brackets). You might be able to leverage std::tuple for that. Otherwise, it can be a good exercise to make your own type list. [snip] Cheers!, - Alf |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 09 09:17PM +0200 Il 09/07/2018 21:04, Alf P. Steinbach ha scritto: > template< class Number, class = enable_if_t< > is_integral_v<Number> > > auto mod( Number a, Number b ) -> Number { return a%b; } I'm going to document myself about this feature, thanks for signalling me ! >> within a subset of types, specified in some form (ex. in >> brackets). > You might be able to leverage std::tuple for that. oh ... I used to think this feature was only supported by BOOST (who was very complex to compile and slow). I'm very glad that now tuple become part of standard ! > Otherwise, it can be a good exercise to make your own type > list. No tnx, I'm just grasping trying to use more rock solid components written by more skilled progrtammers and debugged well. I've lost all my juvenile hubris in trying these things :) TY there's only one case when I try to code myself : when I really can't understand the logic of the existing components and doubt about using them as intended. In that case, I prefer to suspect where errors may hide to suspecting period. -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 09 09:18PM +0200 Il 09/07/2018 21:06, Paavo Helde ha scritto: > int main() { > Buffer<A::large> x; > } perfect, always crystal clear :) -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 09 08:14PM +0200 how can one declare a typename (in the template declaration) to be an enumvalue ? Or else, is it possible to passa a "typeless" (= less strict) integral value to a template ? I remember 15 y ago I found how to declare templates with compile time resolved fixed (but parametric) size arrays like in template <?? "int" Param> class Buffer { private: char [Param] zBuf; ... ... } the enum solution would be better for other reasons (memory alignment, interoperability with other pieces of sw expecting "fixed size" chunks of memory flexible but not arbitrary) Tnx in advance for suggestions :\ -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 09 08:22PM +0200 Il 09/07/2018 20:14, Soviet_Mario ha scritto: > ... > ... > } sorry I mispressed RETURN before completing the post :\ I also wanted to ask a question : whether or not (and how) in "plain" C++ would be possible to specify (always in a template) a typename WITH RESTRICTIONS (as in VStudio extension). With restriction I mean, a typename parameter must be within a subset of types, specified in some form (ex. in brackets). I'm not intersted to obtain INTERFACE filter, just to filter types. That is for the fact that non necessarily a template logic is consistent with every type ! I mean, a template built fo manage number and quantities in calculation would be meaningless passing "std::string" as a typename parameter (as strings can hold illegal number values). How to restrict the space of typenames to a subset, stating legal types ? Re-thanks -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| red floyd <dont.bother@its.invalid>: Jul 09 01:24PM -0700 On 7/9/2018 12:18 PM, Soviet_Mario wrote: > perfect, always crystal clear :) Paavo has given the correct answer, but you might want to declare as follows: #include <array> enum A { small = 512, large = 10000 }; template <A param> class Buffer { private: std:array<char, param> zBuf; // other methods here }; std:array has no extra overhead. |
| scott@slp53.sl.home (Scott Lurndal): Jul 09 08:41PM >// other methods here >}; >std:array has no extra overhead. Personally, I'd rather see 'char zBuf[param];'. I see no benefit in another layer of abstraction over a native type. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 09 09:49PM +0100 On 09/07/2018 21:24, red floyd wrote: > std:array has no extra overhead. Maybe, but it does need a second colon std::array (as I'm sure you know, but the OP might not.) Andy |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jul 10 01:26AM +0200 Il 09/07/2018 22:41, Scott Lurndal ha scritto: >> std:array has no extra overhead. > Personally, I'd rather see 'char zBuf[param];'. I see no benefit in > another layer of abstraction over a native type. I agree, in case of a STATIC array who does not offer dynamic resizing and other extras ... -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jul 09 06:14PM -0500 "Jonathan Blow: "C++ is a weird mess"" https://www.gamesindustry.biz/articles/2018-07-02-jonathan-blow-c-is-a-weird-mess Just because one is correct does not mean that one's solutions are any better. Lynn |
| Juha Nieminen <nospam@thanks.invalid>: Jul 09 07:57AM > move( *this ).Itemlist::operator<<( item ) > ); > } You have an uncanny ability of writing C++ in a form that causes even a very experienced C++ programmer to have to spend an unreasonable amount of time staring at the code trying to figure out what it means. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 09 10:23AM +0200 On 09.07.2018 09:57, Juha Nieminen wrote: > You have an uncanny ability of writing C++ in a form that causes even a > very experienced C++ programmer to have to spend an unreasonable amount > of time staring at the code trying to figure out what it means. That's interesting, when ignoring the personal jab. On what line does it get problematic for you? As reported, for me, very late at night, it was the `static_cast`, somehow then conflating the rules for rvalue-ref-as-return with the rules of rvalue-ref-as-argument. Cheers!, - Alf |
| bitrex <user@example.net>: Jul 09 09:34AM -0400 On 07/09/2018 04:23 AM, Alf P. Steinbach wrote: > rules of rvalue-ref-as-argument. > Cheers!, > - Alf If one is actually utilizing the new features the modern C++ standards have available code is often not going to look a lot like what "very experienced" C++ programmers remember it looking like in 1997 that's just the way it is. |
| woodbrian77@gmail.com: Jul 09 06:38AM -0700 On Monday, July 9, 2018 at 2:58:07 AM UTC-5, Juha Nieminen wrote: > You have an uncanny ability of writing C++ in a form that causes even a > very experienced C++ programmer to have to spend an unreasonable amount > of time staring at the code trying to figure out what it means. That's his schtick. It's a thick accent he's been honing for years. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
| Bart <bc@freeuk.com>: Jul 09 03:37PM +0100 On 09/07/2018 14:34, bitrex wrote: > have available code is often not going to look a lot like what "very > experienced" C++ programmers remember it looking like in 1997 that's > just the way it is. It sounds like C++ programmers expect new features to be more complicated and harder to understand than what is already in the language. In contrast, I consider a useful new feature ought to make things simpler and easier. I actually haven't got a clue what the code at the top is doing. However in the clc group, C++ is frequently sold as a language which is so much easier and better than C because it has so many built-in solutions to things that have to be re-implemented in C. It's odd then that I rarely come across a C++ example which I can follow compared to the C equivalent. Or maybe the C++ experts here just like to show off their skills at writing incomprehensible code, which is not typical of normal programs. -- bart |
| bitrex <user@example.net>: Jul 09 11:27AM -0400 On 07/09/2018 10:37 AM, Bart wrote: > in the clc group, C++ is frequently sold as a language which is so much > easier and better than C because it has so many built-in solutions to > things that have to be re-implemented in C. Sounds like they're "selling" C++ wrong, whomever is selling it that way. The _runtime_ component of C++, the actual stuff that gets parsed directly into object code, is really nothing much more than a mild superset of C, a simplistic 1970s-style statically-typed language. That's component #1 of C++. Component #2 is a powerful modern compile-time meta-programming language that's used to manipulate the component #1s into zero-overhead abstractions. > compared to the C equivalent. Or maybe the C++ experts here just like to > show off their skills at writing incomprehensible code, which is not > typical of normal programs. They're exploiting Component #2 for what it's good for. If you're not doing that you're...basically just programming in a kind of dumpy obtuse variant of C I won't deny it, there's really not much advantage to using C++ at that point over many other modern compiled languages like Go, Rust, and so forth. Standing by itself Component #1 ain't shit, or at least no more or less the shit than C. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 09 05:56PM +0200 On 09.07.2018 16:37, Bart wrote: > complicated and harder to understand than what is already in the language. > In contrast, I consider a useful new feature ought to make things > simpler and easier. I agree with that. > I actually haven't got a clue what the code at the top is doing. Yes, it's pretty intricate code, using C++14 language features, which look odd and have strange rules. Here's a breakdown: struct Sub : Text_item , Itemlist ^ Declares a class called Sub, that inherits from -- Is A -- class Text_item and from class Itemlist. What Text_item and Itemlist are doesn't matter. template< class Item > ^ Introduces a template of something, that can be used with a type that can be wildly different types in different usage contexts. The concrete type used in any given context is called Item in this definition. auto operator<<( Item item ) && -> Sub&& ^ The "auto operator<<(" starts a declaration of a member function called "operator<<". "auto" says that the return type is specified after the function head, either implicitly via a "return" statement (a C++14 deduced return type) or explicitly via a "->" return type specification (C++11 trailing return type syntax). The function name "operator<<" means that this function can be called via operator notation, e.g. the invocation "o << an_item", which is how e.g. iostreams work. "( Item item )" is the function's formal argument list, just like in C. Here an Item is passed by value. "&&" means that this function can only be called via an rvalue expression, essentially calling it on a temporary. More precisely it can also be called on the result of a function that returns an rvalue reference, because that acts as if it were a temporary. So, the "&&" is an rvalue qualification of the member function. There are also lvalue qualification "&", and const lvalue qualification "const &". -> Sub&& Specifies that the return type is rvalue-reference-to-Sub, i.e. (as-if) a reference to a temporary Sub object. return static_cast<Sub&&>( move( *this ).Itemlist::operator<<( item ) ); ^ This rather ungrokable mess just invokes the base class "operator<<", and, via the "static_cast", downcasts the result to this class. It should IMHO have been trivial to do that, it's just a /forwarding/ of the call to a base class method, but it isn't trivial. Instead of downcasting the base class' result it could have been separated into two statements like this: move( *this ).Itemlist::operator<<( item ); return move( *this ); That's perhaps better for discussion. The "move( *this )" doesn't actually move anything. It uses "std::move" as a /cast/ to create an rvalue reference to the current object, needed in the first line because the base class "operator<<" can only be called via an rvalue expression. The ".Itemlist::operator<<" then refers to the "operator" defined in the base class "Itemlist". And the "( item )" expresses the call with "item" as argument, just like in C. "move( *this )" is also needed in the return statement, since this "operator<<", like the one in the base class, returns an rvalue reference. In the originally posted code there is no "move( *this )" for the result because that's expressed by a "static_cast". > in the clc group, C++ is frequently sold as a language which is so much > easier and better than C because it has so many built-in solutions to > things that have to be re-implemented in C. The rvalue stuff in this code addresses problems that stem from what I'd call a cognitive dissonance in the C++ type system. The original C lvalue versus rvalue expression classification was presumably useful to help the compiler put temporary results in registers, where on most machines one couldn't take the address. Also one couldn't assign to rvalues. The put-in-registers made for execution efficiency, and the can't-assign-to made for programmer efficiency; it all made sense. In C++ there are rvalue expressions that denote objects of arbitrary size and complexity, that necessarily do live in main memory, and that generally /can/ be assigned to. That doesn't make so much sense. So the code to handle this, with the old distinction still ruling, gets ungood. > compared to the C equivalent. Or maybe the C++ experts here just like to > show off their skills at writing incomprehensible code, which is not > typical of normal programs. There must be many books and articles about C++ that cater to C programmers. If nothing else, I enjoyed learning C++ from the original "The C++ Programming Language" by Bjarne Stroustrup. I think that was published in 1985. That first edition was of the same general form as the earlier "The C Programming Language" by Kernighan & Ritchie. The first edition of TCPPL was about the pre-standard simpler language that's still to be found within all the complexity of modern C++. I think that book was before exceptions and templates. Exceptions were introduced around 1989, IIRC, templates later. Cheers!, - Alf |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 09 09:52PM +0100 On 09/07/2018 15:37, Bart wrote: > compared to the C equivalent. Or maybe the C++ experts here just like to > show off their skills at writing incomprehensible code, which is not > typical of normal programs. The last heavyweight bit of C I wrote was a hash set. I had to use C as it was running bare metal, so I couldn't use anything nice like new. I can assure you that the several pages of code were a lot harder to read than the C++ equivalent, most of which would have just pulled in STL. Andy |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 08 07:47PM -0400 On 7/8/2018 5:39 PM, Kenny McCormack wrote: >>> I wish you great success on your language, Bart. >> I want to see an early stage of CAlive online. That way, we can actually >> start coding for it. To Chris: CAlive will be released on or about Christmas 2019 (James 4:15 "Lord willing"). > This is actually not an entirely uncommon phenomenon, where an idea is so > good that its keepers cannot let it get out, lest it be soiled by the > outside world. The outside world is, after all, a very dirty place. CAlive undoubtedly has flaws. I am one man, limited in my abilities. I do not want to develop CAlive alone. I keep asking for help. When God sends someone else, we together will make CAlive better than I'm able to make it on my own. Until then, I'm giving the best I have to give from within. -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 08 08:13PM -0700 On 7/8/2018 4:47 PM, Rick C. Hodgin wrote: >>> start coding for it. > To Chris: CAlive will be released on or about Christmas 2019 (James > 4:15 "Lord willing"). Nice to hear. Would that be for the beta? |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 09 07:56AM -0400 On 7/8/2018 11:13 PM, Chris M. Thomasson wrote: >> To Chris: CAlive will be released on or about Christmas 2019 (James >> 4:15 "Lord willing"). > Nice to hear. Would that be for the beta? We shall see, yes?. I could suffer an injury between now and then and not get it completed. I could have some full on inspiration which causes me to get it completed by Easter 2019. You never know. My plans are (James 4:15) to have it ready for prime time in the initial release, to produce production-ready code and allow developers to start running CAlive apps at that time, to contribute bug reports, to give ideas and extensions for how things could bet tweaked. I have mentioned this before, I plan a 1.0 release, and expect a 1.1 release to follow shortly after to fix bugs I was unaware of, then 1.2, 1.3, etc. My internal goal/mindset is the 2.0 version will be the one I use to do development on my own operating system, so that will probably be mid-2020 I shift my development away from RDC/CAlive/Visual FreePro, Jr., and move toward my kernel. I'd like to have it functional by 2023, and then to turn my attention toward my CPU and have it taped out by design and working in an FPGA by 2025. It's all goals and plans though. We shall see what tomorrow holds. ----- I proceed with this mindset (this is my heart as I go forward): https://www.biblegateway.com/passage/?search=James+4%3A13-15&version=KJV,NIV 13 Go to now, ye that say, To day or to morrow we will go into such a city, and continue there a year, and buy and sell, and get gain: 14 Whereas ye know not what shall be on the morrow. For what is your life? It is even a vapour, that appeareth for a little time, and then vanisheth away. 15 For that ye ought to say, If the Lord will, we shall live, and do this, or that. Any and all of "my plans" will only succeed if it is part of His will. I am not a self-made man. I am a component of His creation, and a minor cog at that. Things must align per His plans, or none of what I plan will come to fruition. -- Rick C. Hodgin |
| Sky89 <Sky89@sky68.com>: Jul 08 08:08PM -0400 Hello.. About Embarcadero and Delphi and FreePascal.. As you have noticed i am an "inventor" of many scalable algorithms and there implementations, and as you have noticed Embarcadero company that actually sells its Delphi product has pushed to adopt the ARC memory manager despite it being not the right choice for highly parallel applications, so i have decided to invent a "scalable" reference counting with efficient support for weak references that is suited also for "highly" parallel applications and i have implemented it in Delphi and FreePascal, and you will not find it on C++ or Rust or Delphi, here is my "invention" and read about it and download it from bellow: Scalable reference counting with efficient support for weak references version 1.12 Author: Amine Moulay Ramdane Description: I have enhanced my scalable algorithm and now it is much powerful, now my scalable algorithm implementation works also as a "scalable" counter that supports both "increment" and "decrement" using two scalable counting networks, please take a look at my new scalable algorithm implementation inside the source code.. This is my scalable reference counting with efficient support for weak references, and since problems that cannot be solved without weak references are rare, so this library does scale very well, this scalable reference counting is implemented using scalable counting networks that eliminate completely false sharing , so it is fully scalable on multicore processors and manycore processors and this scalable algorithm is optimized, and this library does work on both Windows and Linux (x86), and it is easy to port to Mac OS X. I have modified my scalable algorithm, now as you will notice i am not using decrement with support for antitokens in the balancers of the scalable counting networks, i am only using an "increment", please look at my new scalable algorithm inside the zip file, i think it is working correctly. Also notice that the returned value of _Release() method will be valid if it is equal to 0. I have optimized it more, now i am using only tokens and no antitokens in the balancers of the scalable counting networks, so i am only supporting increment, not decrement, so you have to be smart to invent it correctly, this is what i have done, so look at the AMInterfacedObject.pas file inside my zip file, you will notice that it uses counting_network_next_value() function, counting_network_next_value() increments the scalable counting network by 1, the _AddRef() method is simple, it increment by 1 to increment the reference to the object, but look inside the _Release() method it calls counting_network_next_value() three times, and my invention is calling counting_network_next_value(cn1) first inside the _Release() method to be able to make my scalable algorithm works, so just debug it more and you will notice that my scalable algorithm is smart and it is working correctly, i have debugged it and i think it is working correctly. I have to prove my scalable reference counting algorithm, like with mathematical proof, so i will use logic to prove like in PhD papers: You will find the code of my scalable reference counting inside AMInterfacedObject.pas inside the zip file here: If you look inside the code there is two methods, _AddRef() and _Release() methods, i am using two scalable counting networks, think about them like counters, so in the _AddRef() method i am executing the following: v1 := counting_network_next_value(cn1); cn1 is the scalable counting network, and counting_network_next_value() is a function that increment the scalable counting network by 1. In the _Release() method i am executing the following: v2 := counting_network_next_value(cn1); v1 := counting_network_next_value(cn2); v1 := counting_network_next_value(cn2); So my scalable algorithm is "smart", because the logical proof is that i am calling counting_network_next_value(cn1) first in the above, so this allows my scalable algorithm to work correctly, because we are advancing cn1 by 1 to obtain the value of cn1, so the other threads are advancing also cn1 by one inside _Release() , it is the last thread that is advancing cn1 by 1 that will make the reference counter equal to 0 , and _AddRef() method is the same and it is easy to reason about, so this scalable algorithm is working. Please look more carefully at my algorithm and you will notice that it is working as i have just logically proved it. Please read also the following to understand better: Here is the parameters of the constructor: First parameter is: The width of the scalable counting networks that permits my scalable refererence counting algorithm to be scalable, this parameter must be 1 to 31, it is now at 4 , this is the power, so it is equal to 2 power 4 , that means 2^4=16, and you have to pass this counting networks width to the n of following formula: (n*log(n)*(1+log(n)))/4 The log of the formula is in base 2 This formula gives the number of gates of the scalable counting networks, and if we replace n by 16, this will equal 80 gates, that means you can scale the scalable counting networks to 80 cores, and beyond 80 cores you will start to have contention. Second parameter is: a boolean that tells if reference counting is used or not, it is by default to true, that means that reference counting is used. About the weak references support: the Weak<T> type supports assignment from and to T and makes it usable as if you had a variable of T. It has the IsAlive property to check if the reference is still valid and not a dangling pointer. The Target property can be used if you want access to members of the reference. Note: the use of the IsAlive property on our weak reference, this tells us whether the referenced object is still available, and provides a safe way to get a concrete reference to the parent. I have ported efficient weak references support to Linux by implementing efficient code hooking, look at my DSharp.Core.Detour.pas file for Linux that i have written to see how i have implemented it in the Linux library. Please look at the example.dpr and test.pas demos to see how weak references work etc. Call _AddRef() and _Release() methods to manually increment or decrement the number of references to the object. Weak references support is done by hooking the TObject.FreeInstance method so every object destruction is noticed and if a weak reference for that object exists it gets removed from the internal dictionary where all weak references are stored. While it works I am aware that this is hacky approach and it might not work if someone overrides the FreeInstance method and does not call inherited. You can download it from: https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references - Platform: Windows and Linux(x86) Language: FPC Pascal v3.1.x+ / Delphi 2007+: http://www.freepascal.org/ Required FPC switches: -O3 -Sd -Sd for delphi mode.... Required Delphi switches: -$H+ -DDelphi For Delphi XE versions and Delphi Tokyo use the -DXE switch The defines options inside defines.inc are: {$DEFINE CPU32} for 32 bit systems {$DEFINE CPU64} for 64 bit systems Thank you, Amine Moulay Ramdane. |
| 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