- TIL: C++17 sequences assignment the wrong way. - 2 Updates
- Geodetic Development Tool - 5 Updates
- Tricky! - 8 Updates
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 30 07:22AM -0700 > Therefore some kind of right-to-left sequencing is part > of the semantics the assignment already always had, in > any language. This summary sentence is utter nonsense. |
Keith Thompson <kst-u@mib.org>: Jul 30 01:08PM -0700 >> of the semantics the assignment already always had, in >> any language. > This summary sentence is utter nonsense. What does the phrase "This summary sentence" refer to? -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
killet@killetsoft.de: Jul 30 01:18AM -0700 Hi, who develops programs with geodetic functionality like coordinate transformations, datum shifts or distance calculations, can use geodetic functions from my Geodetic Development Tool GeoDLL. The Dynamic Link Library can easily be used with most of the modern programming languages like C, C++, C#, Basic, Delphi, Pascal, Java, Fortran, xSharp, MS-Office and others to add geodetic functionality to own applications. For many programming languages Interfaces and Examples are available. GeoDLL is a Geodetic Development Tool or a Geodetic Function Library for worldwide 2D and 3D Coordinate Transformations and Datum Shifts with highest accuracy and for calculating Meridian Convergence and many Extra Parameters. Furthermore: Helmert and Molodensky Parameters, NTv2, HARN, INSPIRE, EPSG, Digital Elevation Model (DEM), distance and Time Zone calculations and much more. GeoDLL is available as 32Bit and 64Bit DLL and as C / C++ source code. The DLL is very fast, save and compact thanks to the consistent development in C / C++ with Microsoft Visual Studio. The geodetic functions are available in 32bit and 64bit architecture. All functions are prepared for multithreading and server operating. You find a free downloadable test version on https://www.killetsoft.de/p_gdla_e.htm Notes about the NTv2 support can be found here: https://www.killetsoft.de/p_gdln_e.htm Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm Fred Email: info_at_killetsoft.de |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 30 12:44PM +0200 > You find a free downloadable test version on https://www.killetsoft.de/p_gdla_e.htm > Notes about the NTv2 support can be found here: https://www.killetsoft.de/p_gdln_e.htm > Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm Sounds nice but I don't understand why a geodetic library needs to be Windows-specific? Cheers!, - Alf |
"Öö Tiib" <ootiib@hot.ee>: Jul 30 05:42AM -0700 On Tuesday, 30 July 2019 13:45:11 UTC+3, Alf P. Steinbach wrote: > > Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm > Sounds nice but I don't understand why a geodetic library needs to be > Windows-specific? It was likely just spam and poster does not read replies. Cursory eyeballing the site finds indications that perhaps they just hope you buy the codes and do porting yourself: "GDLLSOURCE GeoDLL complete C++ source code of all groups EUR 4000.00" by https://www.killetsoft.de/p_prei_e.htm#geodll "The source is extensively written in ANSI-C++, so that the migration to arbitrary operating systems and hardware platforms is possible with minor modifications." by https://www.killetsoft.de/p_gdla_e.htm |
Fred Killet <info_nospam_@killetsoft.de>: Jul 30 04:32PM +0200 Yes, 20000 lines of source code with geodetic functions have their price. However, WINDOWS programmers have the advantage to integrate geodetic functions as a DLL. That is already possible from 500 euros. Fred |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 30 06:11PM On Tue, 2019-07-30, Öö Tiib wrote: > On Tuesday, 30 July 2019 13:45:11 UTC+3, Alf P. Steinbach wrote: ... > It was likely just spam and poster does not read replies. Cursory > eyeballing the site finds indications that perhaps they just hope > you buy the codes and do porting yourself: I have a feeling there's a good ecosystem around libproj, QGis and so on for Free Software-oriented people ... although my experience is limited to conversions between coordinate systems, using libproj. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Sam <sam@email-scan.com>: Jul 29 08:51PM -0400 Bonita Montero writes: > tion returns a pointer to the next state function. I.e I would > write: "while( (fn = state->*fn()) != nullptr );". I see no way > to define the type of fn since it is recursive. Correct, but you can get pretty close, something like this: |
Sam <sam@email-scan.com>: Jul 29 08:52PM -0400 Bonita Montero writes: > tion returns a pointer to the next state function. I.e I would > write: "while( (fn = state->*fn()) != nullptr );". I see no way > to define the type of fn since it is recursive. Correct, but you can get pretty close, something like this: #include <iostream> class state_machine { public: struct next_state_ret; typedef next_state_ret (state_machine::*next_state)(); struct next_state_ret { next_state_ret (state_machine::*stateptr)()=nullptr; operator bool() const { return stateptr != nullptr; } }; inline next_state_ret transition(next_state_ret current_state) { return (this->*(current_state.stateptr))(); } static next_state_ret initial_state() { return {&state_machine::initial}; } next_state_ret initial() { std::cout << "Initial state" << std::endl; return { &state_machine::state1 }; } next_state_ret state1() { std::cout << "State 1" << std::endl; return { &state_machine::state2 }; } next_state_ret state2() { std::cout << "State 2" << std::endl; return { nullptr }; } }; int main() { state_machine sm; auto state=sm.initial_state(); while (state) { state=sm.transition(state); } return 0; } |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 30 01:58PM +0100 On Mon, 29 Jul 2019 13:49:47 +0200 > tion returns a pointer to the next state function. I.e I would > write: "while( (fn = state->*fn()) != nullptr );". I see no way > to define the type of fn since it is recursive. Are you after some kind of lazy list (aka streams)? If so I have stream/node classes with macros and supporting functions (including stream_take()/stream_for_each() functions which are analogous to your while block), which I can post: if so do you want the stream also to memoize or just act lazily? But you may be after something else. |
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 30 07:31AM -0700 > std::cout << "B: " << param << '\n'; > return DoSomethingA; > } Did you not understand the question? Your "solution" doesn't do anything like what he is asking for. |
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 30 08:03AM -0700 > a more dynamic language like Python, but have to be rewritten with > some indirection for a language with strong static type checking > like C++. The problem here is not strong static type checking but the lack of recursive types in C++. A language can have recursive types and also have strong static type checking. > the textual simplicity of the source code. Since it doesn't give > that textual simplicity in C++, it's not a good way in C++. It's > doable, just not in any practical way. That depends on what is meant by "practical". It can be done like this: #include <iostream> class State { using Nexter = ...; public: State(){} Nexter r0(){ return &State::r1; } Nexter r1(){ return &State::r2; } Nexter r2(){ return &State::rn; } Nexter rn(){ return 0; } }; void run_state_machine(){ State *s = new State; for( auto f = &State::r0; f; f = (s->*f)() ){ ::std::cout << "Got one\n"; } } with a fairly short (five-ish lines) elaboration for the "...". Personally I think this approach offers a fairly nice textual simplicity, and is eminently practical. If someone thinks five lines of overhead is too much, the "..." can be made into a template, giving using Nexter = WrapMemberFunctionPointer< State >; which provides an even nicer source text. |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 30 11:20AM -0400 On 7/30/2019 11:03 AM, Tim Rentsch wrote: > ::std::cout << "Got one\n"; > } > } A better solution might be a state machine that can iterate N times setup at instantiation, and then optionally reset when exhausted so it can be re-entered the second time (untested, but generally speaking this concept should work): #include <iostream> class State { using Nexter = ...; public: State(int nStateCount) { nState_ = -1; nStateMax_ = max(1, nStateCount); } Nexter next(bool lReset = false) { if (++nState < nStateMax) return &this->next; // Return self // When we get here, we're done with this state traversal if (lReset) nState = -1; // Prepare for the next one // Indicate this state is exhausted return null; } void reset(int nState = -1) { nState_ = max(-1, min(nState, nStateMax)); } int state(void) { return nState_; } int max(void) { return nStateMax_; } private: int nState_; int nStateMax_; }; void run_state_machine() { State* s = new State(4); ... -- Rick C. Hodgin |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 30 06:00PM +0200 On 30.07.2019 17:03, Tim Rentsch wrote: >> that textual simplicity in C++, it's not a good way in C++. It's >> doable, just not in any practical way. > That depends on what is meant by "practical". Short and clear source code and reasonably good efficiency. > ::std::cout << "Got one\n"; > } > } Yes, that's mainly the basic technique I had in mind: an extra level of indirection, the solution to every computer science problem. Nit-picks: (1) a State instance doesn't actually hold state, yet the member functions are not `static`, and (2) there's a needless dynamic allocation and memory leak. Fixing those issue, it can go like this (in practice one would have some input argument to each function, so it can decide which state to go to): class State { struct Nexter { using Func = auto() -> Nexter; Func* m_p_func; operator Func* () const { return m_p_func; } Nexter( Func* const f ): m_p_func( f ) {} }; State() = delete; public: static auto r0() -> Nexter { return &State::r1; } static auto r1() -> Nexter { return &State::r2; } static auto r2() -> Nexter { return &State::rn; } static auto rn() -> Nexter { return nullptr; } }; #include <iostream> using namespace std; auto main() -> int { for( auto f = &State::r0; f; f = f() ) { cout << "State " << reinterpret_cast<void const*>( f ) << "." << endl; } } Here the reinterpret_cast is only conditionally supported by the standard (since C++11, in order to support Posix), so it's not 100% portable. I guess that on a Harvard architecture it won't compile. But then one would have more labor-intensive problems to deal with... > with a fairly short (five-ish lines) elaboration for the "...". Not sure what you're thinking of there? > can be made into a template, giving > using Nexter = WrapMemberFunctionPointer< State >; > which provides an even nicer source text. Well, to my mind the indirection adds complexity so that even though the code is short it's not IMO /clear/, and for debugging it's not so clear which state one is in, just by looking at a function address. But, subjective opinion. ;-) Cheers!, - Alf |
"Öö Tiib" <ootiib@hot.ee>: Jul 30 09:22AM -0700 On Tuesday, 30 July 2019 17:32:11 UTC+3, Tim Rentsch wrote: > > are you trying to achieve. > Did you not understand the question? Your "solution" > doesn't do anything like what he is asking for. Yes, I tried to express that doubt. Can't you read? Your habit to answer in useless manner starts to feel strange. Additionally ... I suspect that Bonita is she. |
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