- Some C++14 code - 3 Updates
- Available C++ Libraries FAQ - 1 Update
- "Jonathan Blow: "C++ is a weird mess"" - 16 Updates
- Special link-list algorithm help - 1 Update
- Special link-list algorithm help - 1 Update
| Juha Nieminen <nospam@thanks.invalid>: Jul 14 06:48PM >> it. It's just going to break the program really badly. > If things are that complicated then I might suggest that neither C++ nor > C is the right language. What do you mean? The above scenario is *trivial* in C++: //-------------------------------- struct A { std::vector<int> v1, v2; }; struct B { std::vector<A> a1, a2; }; std::vector<B> bVector; //-------------------------------- C++ was *designed* to handle the above situation just right, without much hassle. C wasn't. |
| Bart <bc@freeuk.com>: Jul 14 11:07PM +0100 On 14/07/2018 19:48, Juha Nieminen wrote: > //-------------------------------- > C++ was *designed* to handle the above situation just right, > without much hassle. I seized on the word 'maps' and envisioned something more elaborate than your example, involving structs, vectors and maps in various arrangements. But even with something like the above, I don't think this is quite as trivial as you suggest. A scripting language (even mine which is lower level than most) really could handle this stuff trivially and would probably run rings around any C++ code. (I tried to put something together that uses your data structures (not C++ and not static), see example in sig; this uses flex strings rather than int vectors for some extra interest.) > C wasn't. You tend to adapt code, algorithms and data structures to suit the language. Unless those arrays absolutely need random access and need to be counted arrays (ie. carrying their length with them), then in C I might write them as simply-linked lists, especially with elements more involved than simple ints. I've been using a language at the C level for decades without needing all the stuff in C++ (although string handlng is a PITA). For higher level requirements I've worked out how to balance low-level static code and scripting code. -- bart ---------------------------------------------- import sys record A = (var v1, v2) record B = (var a1, a2) proc start= bVector := () to random(10) do # random(10) returns values 0 to 9 x := () to random(10) do x append:= A(randomstring(), randomstring()) od bVector append:= B(x, tail(x)) od forall x in bvector do println =x.a1 println =x.a2 od end function randomstring= x:="" to random(10) do x +:= random('A'..'Z') od return x end ---------------------------------------------- Output: X.A1= ((S,LZFR),(JECVY,HRFNL),(VZXLIH,F),(GMCOGQ,)) X.A2= ((JECVY,HRFNL),(VZXLIH,F),(GMCOGQ,)) X.A1= ((ZAMOPYE,O),(TZQDFTW,PR),(NLVJUX,ZXDFBH),(SEBQW,OO)) X.A2= ((TZQDFTW,PR),(NLVJUX,ZXDFBH),(SEBQW,OO)) X.A1= ((VI,AADD),(YX,WV),(VTVKXW,IRZFHMIY)) X.A2= ((YX,WV),(VTVKXW,IRZFHMIY)) X.A1= ((VHSEYW,PQQIWI),(JUDUZRCFI,JLZIS),(NSDFAK,CZJCF),(XNKJRIS,AUUTPQC),(D,PI),(FBOIVYB,),(,HW),(N C,EBTEVT)) X.A2= ((JUDUZRCFI,JLZIS),(NSDFAK,CZJCF),(XNKJRIS,AUUTPQC),(D,PI),(FBOIVYB,),(,HW),(NC,EBTEVT)) X.A1= ((JY,JDTBLPI),(,HNGD)) X.A2= ((,HNGD)) X.A1= ((TY,NGKTQPI)) X.A2= () X.A1= ((GGCYRO,),(D,N),(ETB,EUQVF),(UKS,QUXR),(,PVR)) X.A2= ((D,N),(ETB,EUQVF),(UKS,QUXR),(,PVR)) |
| Ian Collins <ian-news@hotmail.com>: Jul 15 11:12AM +1200 On 15/07/18 10:07, Bart wrote: > all the stuff in C++ (although string handlng is a PITA). For higher > level requirements I've worked out how to balance low-level static code > and scripting code. Some of us need performance from higher level code... -- Ian. |
| Nikki Locke <nikki@trumphurst.com>: Jul 14 10:23PM Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not fill in the form at http://www.trumphurst.com/cpplibs/cppsub.php Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 13 07:41PM -0400 On 7/13/2018 7:12 PM, Rick C. Hodgin wrote: > Studio Debugger. > Visual Studio GDB Debugger > https://www.youtube.com/watch?v=-3toI8L3Oug To be clear about this, you can do Linux development by having a Windows VM running in Linux, installing Visual Studio in there. You can share a network drive to access your Linux partition, and do direct development in Visual Studio on your Linux OS and disk. You can cooperatively do VS development, and other development. VS has always been able to use the GCC toolchain (with MinGW or CYGWIN) from inside VS using 3rd party compilation tools. It is simply more integrated now from VS2015 on. VS2017 is also free to download and use for open source projects, or single-developer projects: https://visualstudio.microsoft.com/vs/community/ Single developer: "Any individual developer can use Visual Studio Community to create their own free or paid apps." Open source: "An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects." -- Rick C. Hodgin |
| Ian Collins <ian-news@hotmail.com>: Jul 14 02:39PM +1200 On 14/07/18 11:41, Rick C. Hodgin wrote: > You can share a network drive to access your Linux partition, > and do direct development in Visual Studio on your Linux OS and > disk. There are many ways of doing Linux development, that is possibly the worst. If you are doing Linux development and like Microsoft tools, use Visual Studio Code. If you prefer a Windows desktop, use Visual Studio for development and WSL for your native builds. -- Ian. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 14 05:50AM +0200 On 14.07.2018 04:39, Ian Collins wrote: > If you are doing Linux development and like Microsoft tools, use Visual > Studio Code. If you prefer a Windows desktop, use Visual Studio for > development and WSL for your native builds. Assuming WSL means Windows Subsystem for Linux, and further assuming that that's the beast that one can install by enabling dev-mode in Windows 10, well I tried it and as of Windows 10 it's still a beta. About the first it did was mess up a few files: the integration between the file systems is sort of alpha, if at all tested. I uninstalled it quickly. Better to run a real Linux in a virtual box or on separate machine. The integration with Windows is better in VirtualBox than what I got with WSL. WSL is just nothing like the earlier Subsystem for Unix. I can understand that people enable dev-mode in order to get symbolic links enabled though, but instead of symlinks I just use `mklink /j source ...` to create junctions for out of source VS projects. It works fine except that Visual Studio, as probably opposed to the compiler's handling of `#pragma once`, doesn't understand that a file accessed via two different paths are the same file, so a little annoying when I just double-click a diagnostic, fix something and rebuild: hey, changes made outside of the editor, would you like to reload, blah blah... Of course I forgot all about that behavior when some MS system (VS? their web pages?) recently asked what I'd like improved in VS. I just answered speed of getting up and running, and of loading solutions. But really, when I /consider/ it, what they first should fix in order to please just me, would be recognition of different paths = same file. Cheers!, - Alf |
| Ian Collins <ian-news@hotmail.com>: Jul 14 04:19PM +1200 On 14/07/18 15:50, Alf P. Steinbach wrote: > About the first it did was mess up a few files: the integration between > the file systems is sort of alpha, if at all tested. I uninstalled it > quickly. Odd, probably 40-50 developers on my team are running it! > Better to run a real Linux in a virtual box or on separate machine. Real machine, yes, Virtual Box - no. We used to work that way but dumped it in favour of WSL (which is effectively Ubuntu on Windows) or docker for Linux builds. -- Ian |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 13 09:25PM -0700 On 7/13/2018 4:41 PM, Rick C. Hodgin wrote: >> https://www.youtube.com/watch?v=-3toI8L3Oug > To be clear about this, you can do Linux development by having > a Windows VM running in Linux, installing Visual Studio in there. Why do that? If you want an IDE, just install Linux, then a Linux version of an IDE that you like, perhaps, say: https://code.visualstudio.com/insiders/#linux Or any other Linux IDE. Of course, one can just use VIM. Command line? Sure. No problem. Side note: Sometimes I think there can be an "addictive" quality to IDE's... [...] |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 14 07:56AM -0400 On 7/13/2018 10:39 PM, Ian Collins wrote: > If you are doing Linux development and like Microsoft tools, use Visual > Studio Code. If you prefer a Windows desktop, use Visual Studio for > development and WSL for your native builds. Using Visual Studio, you can do the bulk of your development with native MSVC++ and Visual Studio tools, including its native debugger, edit-and-conntinue abilities, and then do your periodic compiles with GCC/GDB and do testing through the same tool and interface. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 14 07:59AM -0400 On 7/14/2018 12:25 AM, Chris M. Thomasson wrote: > Sometimes I think there can be an "addictive" quality to IDE's... Have you ever used Visual Studio? There is no comparison in other tools to that developer platform. I've never seen another one that even comes close. The integration, the edit-and-continue, the ease of debugging. It is the most powerful x86-based debugging tool I've ever seen. If you have one that's on par, I'll look at it as I truly hate Microsoft and seek to leave their OS and tools forever. -- Rick C. Hodgin |
| gazelle@shell.xmission.com (Kenny McCormack): Jul 14 03:18PM In article <picoiu$d0k$3@dont-email.me>, >It is the most powerful x86-based debugging tool I've ever seen. >If you have one that's on par, I'll look at it as I truly hate >Microsoft and seek to leave their OS and tools forever. You shouldn't be singing the praises of their flagship product and then claiming to hate them. It just doesn't wash. Not, of course, that you and spouting nonsense aren't already on a first name basis with each other. -- A Catholic woman tells her husband to buy Viagra. A Jewish woman tells her husband to buy Pfizer. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 14 12:20PM -0400 On 7/14/2018 11:18 AM, Kenny McCormack wrote: >> Microsoft and seek to leave their OS and tools forever. > You shouldn't be singing the praises of their flagship product and then > claiming to hate them. It just doesn't wash. Why not? It's the best software developer tool there is. At least until I get CAlive's IDE working. Nyuck nyuck. :-) > Not, of course, that you and spouting nonsense aren't already on a first > name basis with each other. Oh. Harsh. Tell me, Kenny (may I call you Kenny?), what color is the sky in your world? -- Rick C. Hodgin |
| Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Jul 14 06:27PM +0200 Am 14.07.2018 um 13:59 schrieb Rick C. Hodgin: > tools to that developer platform. I've never seen another one that > even comes close. The integration, the edit-and-continue, the ease > of debugging. The IDE may be good, but this is immediately put to waste by the horrible C++ compiler which comes with it. In my experience, it is slow, produces inefficient code (compared to Intel or mingw), is still not fully compliant with the standard (although the current iteration has come much closer), and frequently produces completely incomprehensible error messages. > It is the most powerful x86-based debugging tool I've ever seen. I'm in C/C++ development for more than 30 years now, and in my experience a good compiler (fast, compliant, with meaningful warnings and errors) spares much more time than a good debugger. Which is kind of last-resort anyways - if you spend much time in the debugger, your design and/or your unit tests were bad. The difference is so big, that i'm developing new code on Linux most of the time these days, using the "pretty" Visual Studio merely as a bare-bone compiler for production builds... |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 14 12:41PM -0400 On 7/14/2018 12:27 PM, Hergen Lehmann wrote: > mingw), is still not fully compliant with the standard (although the current > iteration has come much closer), and frequently produces completely > incomprehensible error messages. Have you seen statistics? In addition, you can use 3rd party compilers with Visual Studio. Intel's compilers integrate directly. You simply need to choose your target compiler when compiling and Visual Studio does the rest for you. The edit-and-continue abilities of the MSVC++ compiler make its development worthwhile. When you need to do a release build with greater optimization, then use the other tool. > much more time than a good debugger. Which is kind of last-resort anyways - > if you spend much time in the debugger, your design and/or your unit tests > were bad. All developer work differently. I like an edit-and-continue compiler, and don't really care that much about performance. 99.9% of the apps I develop run fast enough for what their target is, and usually the slowest component is the user. > The difference is so big, that i'm developing new code on Linux most of the > time these days, using the "pretty" Visual Studio merely as a bare-bone > compiler for production builds... Glad it works for you that way. Keep on keepin' on. :-) -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 14 02:12PM -0400 On 7/14/2018 12:27 PM, Hergen Lehmann wrote: >> of debugging. > The IDE may be good, but this is immediately put to waste by the horrible C++ > compiler which comes with it. I'm curious about this thinking. As a developer, I spend most of my time writing code. I want to be in a capable tool to minimize the time I spend spinning my wheels, or doing repetitive tasks that are better handled by the tool I'm using. As such, the IDE, the integrated debugger that is so power and easy to use, these add up to a far greater component during development. It is only then later, after the code is developed, that performance becomes an issue. How is it that your development cycle is otherwise, and to such an ex- tent you would abandon Visual Studio and use another toolset which may not have the powerful IDE abilities of Visual Studio, all because the compiler is perhaps faster to compile, and produces more optimized code? Why would you be doing your development in optimized code anyway? It takes notably longer to compile, and you lose the ability to have all of your symbols across certain optimizations. I would think you would want to do development in a debug mode with few optimizations, and then when finished do some final testing in a release mode with full optimizations. ----- Can you explain the mindset? How much time do you gain with the faster compiler and more optimized code during hours, days, weeks, months, years, of developer time at the keyboard writing and testing code? -- Rick C. Hodgin |
| Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Jul 14 08:25PM +0200 Am 14.07.2018 um 18:41 schrieb Rick C. Hodgin: >> (although the current iteration has come much closer), and frequently >> produces completely incomprehensible error messages. > Have you seen statistics? In my current main project (which is mostly network I/O and multi-threaded, sequential processing without much potential for local optimizations), i experience a difference in code efficiency of around 30%-50%, with another 30-50% being caused by the operating system. In the end, the same code is on average twice as fast on Linux/g++ compared to Windows/msvc++ (with Windows/Intel somewhere in-between). That's a lot! > Intel's compilers integrate directly. You simply need to choose > your target compiler when compiling and Visual Studio does the > rest for you. Yeah, but the Intel compiler is production-only and way too slow for quick edit-and-testing cycles. gcc/mingw on the other hand does NOT integrate into Visual Studio, while clang is still alpha on Windows. And that's it for the well-established compilers. In the end, there is no real alternative during development. I either had to live with the crude MSVC++ or switch to a completely different development platform - which i did in the end, because i was tired of thinking whether me or the compiler is dumb all the time. > The edit-and-continue abilities of the MSVC++ compiler make its > development worthwhile. Unfortunately, that doesn't work to well with C++. Many edits affect header files and in turn require re-compilation and re-linking of larger parts of the code - which takes more than twice the time on MSVC++ compared to g++. > compiler, and don't really care that much about performance. > 99.9% of the apps I develop run fast enough for what their > target is, and usually the slowest component is the user. Well, i'm in the server business. While in most installations performance is just "good enough", others are pushing the limits or gradually grew into that state. Unfortunately, these are also the ones, where the customer pays lots of money for a 24/7 service contract and expects a quick response to anything which may pop up, including performance issues. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 14 03:00PM -0400 On 7/14/2018 2:25 PM, Hergen Lehmann wrote: > 30-50% being caused by the operating system. In the end, the same code is on > average twice as fast on Linux/g++ compared to Windows/msvc++ (with > Windows/Intel somewhere in-between). That's a lot! 30% to 50% is a lot. But if the code is running a simple text editor, the user will never see it. Is it a bottleneck in network processing on your system? Does it need that extra 30% to 50% to handle maximum network throughput? > edit-and-testing cycles. gcc/mingw on the other hand does NOT integrate into > Visual Studio, while clang is still alpha on Windows. And that's it for the > well-established compilers. Visual Studio 2015 and 2017 do integrate GCC into their toolchain: At 1:01: www.youtube.com/watch?v=-3toI8L3Oug&t=1m1s At 1:47 he speaks about the MinGW environment, and how to setup the compiler so it works in an NMake environment. > live with the crude MSVC++ or switch to a completely different development > platform - which i did in the end, because i was tired of thinking whether me > or the compiler is dumb all the time. Got it. I've been looking since the early 2000s for a better platform. I found one that was close on Solaris, but it's no longer supported outside of proprietary software models, so that's a dead-end. > Unfortunately, that doesn't work to well with C++. Many edits affect header > files and in turn require re-compilation and re-linking of larger parts of > the code - which takes more than twice the time on MSVC++ compared to g++. It depends on how you do your development. If you're doing things that require some major recompilation, break out your source files into much smaller files with only those functions you're working on at the moment, and then it will compile much faster, and the change code applied will be much faster. Having the ability to maintain your place in the app, your existing data already processed, and update your algorithm is, to me, a far greater asset. > Well, i'm in the server business. While in most installations performance is > just "good enough", others are pushing the limits or gradually grew into that > state. I have some server software I use and have written on my server, but I don't have such high traffic that it is ever performance limited. In fact, I typically don't see even 10% CPU usage when a dozen or more users are on my site. > Unfortunately, these are also the ones, where the customer pays lots of money > for a 24/7 service contract and expects a quick response to anything which > may pop up, including performance issues. Those are constraints unique to a business model. They are not for everyone. The projects I work with are primarily in-house developed projects, and we provide a similar service but performance related to compute is not an issue, though we do have some performance issues with our backend database. I also work on open source projects, and I do have some performance issues on my GUI, but it's because I'm doing a thing a particular way by choice. It enables a feature that I find to be a desirable thing, but it does impact performance. I get about 6 fps max on business forms, and for some people that's an issue. I'll stick with MSVC++ for nearly everything, and cringe each time I have to go to a GCC+GDB or other Linux-based toolchain. :-) -- Rick C. Hodgin |
| Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Jul 14 09:11PM +0200 Am 14.07.2018 um 20:12 schrieb Rick C. Hodgin: > time writing code. I want to be in a capable tool to minimize the time > I spend spinning my wheels, or doing repetitive tasks that are better > handled by the tool I'm using. Yeah, and the most important tool is the compiler itself. I need to trust it that - the code behaves the way it should according to the language standard, - the optimizer works well enough that i do not need to spend many hours optimizing the source code and can put emphasis on readability, - error/warning messages point right to the issue, - the turnaround time between editing, compiling and testing is quick enough to immediately test every small change. > As such, the IDE, the integrated debugger that is so power and easy to > use, these add up to a far greater component during development. The IDE is mostly an editor for me. I rarely use the debugger, because the code is studded with lots of consistency checks and debug output, which can be turned on on demand. I need to take this approach, because the application is running 24/7 on permanent load in production scenarios, and i simply cannot reproduce most errors by single-stepping through it. Multi-threading is another hurdle. Did you ever try to step through a piece of code in the debugger, which is executed by a dozen threads at the same time? And some parts don't even work in the debugger, because network communication will run into timeouts. > not have the powerful IDE abilities of Visual Studio, all because the > compiler is perhaps faster to compile, and produces more optimized > code? As i said, i need to trust the compiler. I cannot trust MSVC++, because it still has lots of shortcomings and deviations from the language standard. Each and every error may be on my part or on the compiler's. Some developers try to avoid these hurdles by collecting experience with the compilers quirks and writing MSVC-optimized code, but i definitely don't want to go this way at a time where MS's influence is dwindling and their strategists try to push everyone away from C/C++ and into their own C#. > Why would you be doing your development in optimized code anyway? It > takes notably longer to compile, On MSVC, yes. With g++ or clang, compilation speed isn't much affected by optimization settings, while at the same time the optimization results are much better. But the main reason is, that parts of the code simply run too slow in their non-optimized version to meet protocol requirements. C++ and especially the STL relies *A LOT* on optimization by the compiler! > faster compiler and more optimized code during hours, days, weeks, > months, years, of developer time at the keyboard writing and testing > code? Depends on the development phase. When adding new stuff, good turnaround times save at least an hour every day for code writing and testing. When doing production builds, good automatic optimization saves LOTS of hours for optimizing the source code and even more hours by avoiding the errors resulting from heavily optimized (hardly readable) source code. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 14 11:00PM +0100 On 14/07/2018 17:27, Hergen Lehmann wrote: > The IDE may be good, but this is immediately put to waste by the > horrible C++ compiler which comes with it. You're absolutely right. It got worse - we were writing managed C++, because we wanted the power of C++ and the pretty front ends from C#. C++ will do more than C#. Anything you couldn't do in C# the debugger didn't understand. This was 5 years ago, mind. I did try Visual Studio talking to a Linux box. For a couple of weeks. It just doesn't understand the filesystem - kept setting the execute bit on source files for example. I gave up. BTW @Chris - one of our guys uses EMACS... Andy |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 14 12:21PM -0400 On 7/14/2018 11:40 AM, Stefan Ram wrote: > - and all lines have less than 72 characters. > main.cpp > [snip] Owe! My eyes! :-) -- Rick C. Hodgin |
| ram@zedat.fu-berlin.de (Stefan Ram): Jul 14 03:40PM >the code is written in BAD STYLE, not making proper use of >modern auto pointers, not having The new version of the code - uses modern auto pointers, - has a non-recursive tree destructor, - and all lines have less than 72 characters. main.cpp #include <iostream> #include <ostream> #include <sstream> #include <string> #include <memory> using namespace ::std::literals; struct tree { ::std::string tag; ::std::unique_ptr< tree >car; ::std::unique_ptr< tree >cdr; tree(): tag{}, car{ nullptr }, cdr{ nullptr } {} tree( tree && other )noexcept: tag{ ::std::move( other.tag )}, car{ ::std::move( other.car )}, cdr{ ::std::move( other.cdr )} {} explicit tree( ::std::string const & s ): tag{ s }, car{ nullptr }, cdr{ nullptr } {} explicit tree( char ch ): tag{ ch }, car{ nullptr }, cdr{ nullptr } {} tree ( ::std::string const & s, ::std::unique_ptr< tree >&&car, ::std::unique_ptr< tree >&&cdr ): tag{ s }, car{ ::std::move( car )}, cdr{ ::std::move( cdr )} {} tree & operator=( tree && other )noexcept { tag=other.tag; car = ::std::move(other.car); cdr = ::std::move(other.cdr); return *this; } void print( int depth ) { ::std::cout << ::std::string( 2 * depth, ' ' ) << this->tag << '\n'; if( this->car )car->print( depth + 1 ); if( this->cdr )cdr->print( depth + 1 ); } void print(){ print( 0 ); } ~tree() { int j{ 0 }; tree * p{ nullptr }; tree * q{ nullptr }; while( car || cdr ) { if( car ){ p = car.get(); q = p; } else if( cdr ){ p = cdr.get(); q = p; } while( p->car || p->cdr ) { if( p->car ){ q = p; p = p->car.get(); j = 0; } else if( p->cdr ){ q = p; p = p->cdr.get(); j = 1; }} if( q != p )if( j )q->cdr = nullptr; else q->car = nullptr; if( q == cdr.get() )cdr = nullptr; else if( q == car.get() )car = nullptr; }}}; using treep = ::std::unique_ptr< tree >; template< class scanner >struct parser { scanner s; parser( ::std::string s ): s{ s } {} auto identifier(){ return ::std::make_unique< tree >( s.get() ); } auto primary() { treep result = nullptr; if( '(' == s.peek() ) { s.get(); result = expression(); s.get(); } else result = identifier(); return result; } auto multiplication() { treep result = primary(); while( '*' == s.peek() ) { s.get(); result = ::std::make_unique< tree > ( "Mul "s, ::std::move( result ), primary() ); } return result; } auto addition() { ::std::unique_ptr< tree >result = multiplication(); while( '+' == s.peek() ) { s.get(); result = ::std::make_unique< tree > ( "Add "s, ::std::move( result ), multiplication() ); } return result; } auto assignment() { ::std::unique_ptr< tree >result = addition(); while( '=' == s.peek() ) { s.get(); result = ::std::make_unique< tree > ( "Assign "s, ::std::move( result ), addition()); } return result; } treep expression(){ return assignment(); }}; int main() { using p = ::parser< ::std::stringstream >; auto test = []( ::std::string const & s ) { p{ s }.expression()->print(); }; test( "a=(b+c)*d"s ); } transcript Assign a Mul Add b c d |
| 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