- Let'me learn. - 6 Updates
- Extension of OpenMPCon submission deadline - 1 Update
- neoGFX - 18 Updates
| thu ra <athuyar296@gmail.com>: Jun 01 12:01AM -0700 Hello, ladies and gentlemen My name is Thu Ra from Myanmar(Burma). I want to learn programming. Please, teach me. Thank you. |
| thu ra <athuyar296@gmail.com>: Jun 01 01:51AM -0700 On Thursday, June 1, 2017 at 1:31:56 PM UTC+6:30, thu ra wrote: |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 01 11:51AM +0200 On 01-Jun-17 9:01 AM, thu ra wrote: > Hello, ladies and gentlemen My name is Thu Ra from Myanmar(Burma). I > want to learn programming. Please, teach me. Thank you. In this group we discuss programming in the C++ language, so you're technically off-topic. Still, some words of advice: C++ is a difficult language even for professionals, and even more difficult for beginners. Very. It's my impression that most young beginners today use some variant of JavaScript. They use online JavaScript exploration sites like JSFiddle, and they use local JavaScript programming environments like "node.js". The "node.js" environment has some excellent tutorials. I suggest you try it. Just google "node.js tutorials". Cheers & hth., - Alf |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 01 04:57PM On Thu, 2017-06-01, Alf P. Steinbach wrote: > technically off-topic. > Still, some words of advice: C++ is a difficult language even for > professionals, and even more difficult for beginners. Very. Hey, why scare away potential new C++ programmers? We need them. If you stay away from the C subset and the most esoteric stuff, I don't think it's that difficult. I'm not accusing you of this, but IMO a problem with C++ is people's desire to complicate things, to create interesting problems. C++ is a good language for that too, but I'd rather get useful things done. A more real problem for beginners may be that there's little instant gratification. Not counting unit tests, it takes some work to create something that actually runs and does anything useful. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 01 10:02AM -0700 On Thursday, June 1, 2017 at 3:01:56 AM UTC-4, thu ra wrote: > Hello, ladies and gentlemen > My name is Thu Ra from Myanmar(Burma). I want to learn programming. > Please, teach me. Thank you. If you would like to learn C and some C++, I can teach you. If you want to learn everything in C++ it's beyond my knowledge base. But if you learn C and some C++, you can do 90% of C++ development until a few years ago. Email me if interested. Thank you, Rick C. Hodgin |
| "Öö Tiib" <ootiib@hot.ee>: Jun 01 10:33AM -0700 On Thursday, 1 June 2017 19:57:32 UTC+3, Jorgen Grahn wrote: > > Still, some words of advice: C++ is a difficult language even for > > professionals, and even more difficult for beginners. Very. > Hey, why scare away potential new C++ programmers? We need them. But such words can scare away only the cowardly. I'm not sure that we need them. ;) |
| OpenMP ARB <openmpinfo@gmail.com>: Jun 01 10:32AM -0700 Do you have something to share with the OpenMP community? Submit a short abstract by June 15 to OpenMPCon for an opportunity to present! The deadline to submit a talk for OpenMPCon 2017 has been extended to June 15, 2017 and we encourage everyone to help us create an interesting agenda for the OpenMP Community meeting by submitting relevant talks, such as: • A new tool with OpenMP support • Extension of the functionality of your tool with better OpenMP support • How you and your organization uses OpenMP in applications • Ideas to extend OpenMP which can lead to an interesting discussion • Any other interesting news in the context of OpenMP Go to http://openmpcon.org/conf2017/call-for-submissions/ for additional information on submission to OpenMPCon to present your work. ***************************************************************** OpenMPCon2017 September 18-20, 2017 Stony Brook, New York, USA http://www.openmpcon.org IMPORTANT DATE: Abstract Deadline: June 15, 2017 ***************************************************************** Sponsored by: OpenMP ARB Description: OpenMPCon is the annual OpenMP Developers conference organized by the OpenMP community, for the community. OpenMPCon takes place 18-20 September in Stony Brook, NY, USA and will focus on the practical usage of OpenMP and other directive based languages, to deliver high-performance computing through parallel processing. Submissions: Submissions are requested from industry experts, developers, and academia on all topics related to OpenMP, including but not limited to: application development from any discipline, algorithms, performance analysis, tools and libraries, optimization, verification, portability and education. Sessions can be in the form of technical presentations, tutorials and workshops, posters, or panel discussions. All submissions should be in the form of short abstracts (minimum 300 words, maximum 1,000 words) and must be handed in as a PDF document. All submissions will go through a peer review process. Session material will be posted on the OpenMPCon website and will be available to conference attendees. Topics of interest include, but are not limited to: * How you Use OpenMP * Guidelines of OpenMP * Tips, tricks, gotchas of OpenMP * Performance of OpenMP * Conformance, build, options of OpenMP compilers/runtime implementations * Latest OpenMP and older releases and how it changes life for users * Accelerator, and heterogeneous computing (GPUs, accelerators, FPGA) * Tasks, task groups and task dependencies * Scientific, HPC workloads * Commercial, analytic workload * Oil and Gas use of OpenMP * Research on OpenMP (although a good research paper should be submitted to IWOMP) * Manufacturing, games, graphics, operating system, device drivers, and networking domains for OpenMP * Comparisons with other parallel languages * Future of OpenMP * Reduction * Base language (C++, C, Fortran) with OpenMP * Affinity * SIMD and vectors * Memory model, atomics, locks, mutexes, barriers & critical sections in OpenMP * OpenMP APIs and environment variables * Cancellation and Error Model * Technical Reports, TR1, TR2 * Arrays shaping in OpenMP * OpenMP concurrency and parallelism * OpenMP designs * Cancellation * Interoperability * Event programming, futures * Governance, ARB, committee logistics * OpenMP website, discussion groups, forums, wikis * Conferences, language meetings, IWOMP * Speculative execution and transactional memory * Software development tools for OpenMP * Relation with other (MPI, OpenCL, OpenACC, ISO, etc) * History of OpenMP * Tutorial-style sessions GENERAL CHAIRS Michael Klemm, OpenMP ARB CEO PROGRAM CHAIR Dirk Schmidl, RWTH Aachen PROGRAM COMMITTEE James Beyer, NVIDIA Michael Klemm, Intel Naoya Maruyama, RIKEN AICS Helen He, Lawrence Berkeley National Lab MARKETING AND SOCIAL MEDIA CHAIR Matthijs van Waveren CONFERENCE MANAGEMENT Kathleen Mattson Tim Lewis |
| Mr Flibble <flibble@i42.co.uk>: Jun 01 01:52AM +0100 On 31/05/2017 18:59, Rick C. Hodgin wrote: > Jesus Christ. That's not the case. I did not see the advantage > of having that feature when most of the time I would think you > would want additional information for the click event. Stop polluting this newsgroup with your proselytising (which includes meta-proselytising). It is rare to want additional information about a simple button click event other than the fact that the event has happened. You are confusing mouse button click events with button widget "clicked" events. [snip] > It is slower than doing it a direct way, but it allows full and > custom expansion of add-on properties, events, methods, and other > objects at runtime. Your code looks like horrible old fashioned C code (which I am not interested in) rather than modern new C++ code (which I am interested in). Unions? Seriously? /Flibble |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 06:14PM -0700 On Wednesday, May 31, 2017 at 8:52:34 PM UTC-4, Mr Flibble wrote: > Unions? Seriously? Unions. Seriously. Behold ... The Mighty Union Brigade! https://groups.google.com/d/msg/comp.lang.c/qt1b1yZesws/-LJbJ90jnYYJ Thank you, Rick C. Hodgin |
| Mr Flibble <flibble@i42.co.uk>: Jun 01 02:21AM +0100 On 01/06/2017 02:14, Rick C. Hodgin wrote: > Unions. Seriously. > Behold ... The Mighty Union Brigade! > https://groups.google.com/d/msg/comp.lang.c/qt1b1yZesws/-LJbJ90jnYYJ No fucking way am I going to read all that crap. The need to use unions in modern C++ is rare as using them outside of library code is nearly always a mistake (as is the case here). /Flibble |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 06:30PM -0700 On Wednesday, May 31, 2017 at 9:22:02 PM UTC-4, Mr Flibble wrote: > > Behold ... The Mighty Union Brigade! > > https://groups.google.com/d/msg/comp.lang.c/qt1b1yZesws/-LJbJ90jnYYJ > No .. way am I going to read all that crap. It's a song. You have to hear the tune in your mind. It's kind of like a marching song, like the opening part of the "I'm A Lumberjack And I'm Okay" song by Monty Python. > The need to use unions in modern C++ is rare as using them outside of > library code is nearly always a mistake (as is the case here). I use them to simplify syntax, so I can store store in an unsigned integer, or void* the value of some more complex form. I've actually defined the ability in my CAlive language to automatically reference every named variable by its underscore form (such as _fred for fred) so that it is in that case referenced as an unsigned integer of the equivalent size. It is a way to make code more clean without having complex casting, or even having to have the auto keyword. Thank you, Rick C. Hodgin |
| Mr Flibble <flibble@i42.co.uk>: Jun 01 02:38AM +0100 On 01/06/2017 02:30, Rick C. Hodgin wrote: > equivalent size. > It is a way to make code more clean without having complex casting, > or even having to have the auto keyword. No it isn't because your proprietary language is not C++ and we are only concerned with C++ here. /Flibble |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 31 06:46PM -0700 On Wednesday, May 31, 2017 at 9:38:22 PM UTC-4, Mr Flibble wrote: > > or even having to have the auto keyword. > No it isn't because your proprietary language is not C++ and we are only > concerned with C++ here. I think C++ is way too complex. I think C is lacking. I think what's needed is a happy medium for 99% of code. Enter CAlive. It's not proprietary. It's fully open. CAlive is being built in a framework (like GCC) called RDC. RDC actually exposes nearly all of the abilities necessary to make a C-like language, and it is, therefore, going to also be used to create other languages: http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/books/rdc https://groups.google.com/forum/#!forum/rapid_development_compiler CAlive has its own definitions as well (these are actually a combination of RDC specs, as well as CAlive specs, but will be mapped slightly differently for each implementation, as RDC looks at things from a data size point of view, and CAlive looks at things from a language point of view): http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/exodus/tools/rdc/rdc_specs.txt https://groups.google.com/forum/#!forum/caliveprogramminglanguage And these are all works in progress. I am only one person who cannot seem to garner any help from any source or location no matter how hard I try. I keep coding, keep asking, keep reaching out, but it's like that big white cross on the door sends everybody packin'. It really is amazing just how powerful that cross is, Leigh! It really strikes fear in people's souls. Thank you, Rick C. Hodgin |
| Mr Flibble <flibble@i42.co.uk>: Jun 01 02:52AM +0100 On 01/06/2017 02:46, Rick C. Hodgin wrote: [proselytising snipped] Fuck. Off. /Flibble |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 31 07:09PM -0700 On 5/31/2017 5:52 PM, Mr Flibble wrote: > It is rare to want additional information about a simple button click > event other than the fact that the event has happened. You are > confusing mouse button click events with button widget "clicked" events. Fwiw, a while back I did a custom animated button that wanted to know where the user clicked as an origin point for an animation. If you right clicked it in "edit mode", a list of different button animations would pop up and hover. I guess the name "custom animated button" is rare by default in a sense. ;^) [...] |
| David Brown <david.brown@hesbynett.no>: Jun 01 09:27AM +0200 On 31/05/17 20:14, Mr Flibble wrote: > It is also possible to be notified of all events coming from > window/surface (with access to all meta information) and there is > provision for filtering those events. I am right in thinking that you would use this sort of inheritance to make an "xy_button" from a neogfx::button? And then you would use the event as: xy_button1.xy([](const point& pos){ // Do left-click stuff with pos.x and pos.y } xy_button1.xy_context([](const point& pos){ // Do right-click stuff with pos.x and pos.y } That is a different way of handling things that most gui toolkits I am familiar with. It is not necessarily a bad thing - it lets your normal widgets remain simple. This is in stark contrast to toolkits such as Delphi/C++ Builder, where widgets acquire a dozen new events and properties for every new version of the tool, and usually all you ever want is a "clicked" event. I'd imagine that using an IDE's auto-complete on an instance of one of your widgets is going to be a lot more efficient than doing so on a wxWidgets object. However, this also means that you can't easily make use of additional events on existing widgets. If you have a button in your design, and you later decide that you want to catch right-hand mouse clicks for it, you have to create your own specialised button class, and then change your design to use that type of button in the right places. This seems a significant complication and effort. I have not looked at the design or implementation of neoGFX, so I may be asking a silly question here. But would it be possible to arrange your widgets so that they have an interface with something like: public: eventGroup events; event<> & clicked; event<const point&> & rightClicked; The "events" member would be a struct listing all the different events possible for such widgets. ("eventGroup" would probably be a template here, for different sorts of widgets.) The normal event members would now be references pointing to the "real" event in the events collection. Then the user can attach handlers to normal events in the same simple fashion as they do now: button1.clicked([]...) and people using less common events can use button1.events.middleClicked([]...) Normal events would be references, so that everything will be consistent if the user writes: button1.events.clicked([]...) |
| David Brown <david.brown@hesbynett.no>: Jun 01 09:36AM +0200 On 01/06/17 04:09, Chris M. Thomasson wrote: > clicked it in "edit mode", a list of different button animations would > pop up and hover. I guess the name "custom animated button" is rare by > default in a sense. It certainly happens that you want right-click events on buttons. For most widgets, you are usually only interested in one or two events - but /sometimes/ you want an extra event. It is good that a gui toolkit is optimised to make it as simple as possible to deal with the common case (many toolkits are not) - but it is also important that it is not /too/ hard to deal with the rare cases. I had an application where the interface had a range of buttons, sliders, gauges, etc., for controlling and monitoring a range of hardware inputs and outputs. Right-clicking on these widgets gave easy access to configuring the choice of input or output for the widget in question. It made the system quite simple to configure or modify in use. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 01 04:40AM -0700 On Wednesday, May 31, 2017 at 9:52:19 PM UTC-4, Mr Flibble wrote: > On 01/06/2017 02:46, Rick C. Hodgin wrote: > [proselytising snipped] If you want to understand me, there's a video I recorded back in 2012 about this project I'm on and why I devote to it. It's a different reason than you might think. the philophy part begins about 37 minutes in: http://www.visual-freepro.org/videos/2012_12_08__01_vvmmc__and_vfrps_relationship_to_christianity.ogv It describes how things in our world are reversed, and what the true way is intended to be where people are our focus, not money or other things, and why. I hope you'll listen to it. Thank you, Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 01 05:41AM -0700 On Thursday, June 1, 2017 at 7:41:17 AM UTC-4, Rick C. Hodgin wrote: > 2012 about this project I'm on and why I devote to it. It's a > different reason than you might think. > the philophy part begins about 37 minutes in: The philosophy part begins about 37 minutes in: > It describes how things in our world are reversed, and what the > true way is intended to be where people are our focus, not money > or other things, and why. I hope you'll listen to it. If anyone knows how to completely turn off auto-correct on a Kindle Fire, please let me know. I have turned off all parts, but at times it randomly changes the last word that was typed in. Thank you, Rick C. Hodgin |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 01 02:10PM +0100 > On Wednesday, May 31, 2017 at 9:22:02 PM UTC-4, Mr Flibble wrote: <snip> >> library code is nearly always a mistake (as is the case here). > I use them to simplify syntax, so I can store store in an unsigned > integer, or void* the value of some more complex form. <snip> > It is a way to make code more clean without having complex casting, Students of C++ (and C) should be aware that Rick deliberately blurs the distinction between re-interpreting the representation of an object and converting the value stored in an object. A union is not an alternative to a cast, even when the result is the same in some cases on some implementations. (This is just short "warning" note -- the whole thing was hashed out more than once in comp.lang.c a while ago.) <snip> -- Ben. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 01 06:21AM -0700 On Thursday, June 1, 2017 at 9:11:13 AM UTC-4, Ben Bacarisse wrote: > A union is not an alternative to a cast, even when the result is the > same in some cases on some implementations. CAlive looks at data as data, and the data type manipulations are merely for protocol and convention, making sure things are coded properly. But if the developer is aware that it is correct, then an assignment through a union should always be valid. And, in CAlive it will be. :-) > (This is just short > "warning" note -- the whole thing was hashed out more than once in > comp.lang.c a while ago.) Yes. And if you look back on those threads in comp.lang.c, you'll also find a follow-up post at each point written by Ben outlining his same correction here. And, for the record, I recognize that C and C++ do not allow this type of casting through a union as a valid language feature, but on x86 and in the compilers I use it works ... so I use it. And, from what I understand of the underlying data mechanisms at work, it should always work on any similar CPU (with same-sized pointers for all types, and a "linear" address architecture). Thank you, Rick C. Hodgin |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 01 03:20PM +0100 >> A union is not an alternative to a cast, even when the result is the >> same in some cases on some implementations. > CAlive looks at data as data, In what sense does it do anything? <snip> > from what I understand of the underlying data mechanisms at work, > it should always work on any similar CPU (with same-sized pointers > for all types, and a "linear" address architecture). If anyone wants to know why this is, at best, confused, they should just re-read the old threads. Rick seems determined to repeat the same old stuff, but I don't have the energy to go over it all again. -- Ben. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 01 07:40AM -0700 On Thursday, June 1, 2017 at 10:20:46 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > CAlive looks at data as data, > In what sense does it do anything? I have designed algorithms for its core, but it can only parse source code into tokens right now, and perform expansion passes on #defines. I don't have the RDC logic developed sufficiently yet to actually compile anything. But, that is what's next in the process, and I have it mapped out offline in concept, just not in code save a few templates I've written for the various flow control types I allow. > If anyone wants to know why this is, at best, confused, they should just > re-read the old threads. Rick seems determined to repeat the same old > stuff, but I don't have the energy to go over it all again. The only reason I stick with something, Ben, is because it holds up to scrutiny and is not supplanted by new information which alters my fundamental understanding. It really is a root philosophical viewpoint I hold here, Ben, and not just a misunderstanding relative to C/C++'s use of a union. The underlying data exchange is merely a re-interpretation of bits. And in the case of a data address on a conventional architecture, that value will be the same whether it's expressed as a function pointer, a void pointer, or an unsigned integer of equivalent size. CAlive takes that reality and uses it, because it has value. It allows those things which really are re-interpretable data without casting to be used fundamentally in their alternate form. Thank you, Rick C. Hodgin |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 01 04:18PM +0100 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > It really is a root philosophical viewpoint I hold here, I know it is. Provided it remains your own philosophical viewpoint it will be largely harmless. <snip> -- Ben. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 01 08:32AM -0700 On Thursday, June 1, 2017 at 11:18:56 AM UTC-4, Ben Bacarisse wrote: > > It really is a root philosophical viewpoint I hold here, > I know it is. Provided it remains your own philosophical viewpoint it > will be largely harmless. You don't have to be hateful or mean, Ben. If you feel your position is on such solid ground that it is truly superior or more foundational than mine, then it should stand on its own merits. Perhaps there is something I'm not understanding here. I'm willing to listen. But consider also that you, in your far greater knowledge of C, C++, and programming languages in general, may also be lacking in some understanding, or may possibly be possessing a bias which is keeping you from seeing the reality I'm pointing to. I don't come from an "institutional" background. I didn't learn about these things at a university in conventional instruction. Everything I've learned about hardware and software design has come from my own research and understanding, and in thinking things through on my own. I don't have a led-by-a-prior-instruction initial thinking, so when I come up with something it is through an examination of the facts, on the evidence of those facts itself. And I have been wrong on many things, only later to realize why some things exist the way they do. I actually had the thought walking through my office at work yesterday that for the first time I can actually see why many of the things in C++ exist as they do. And I can't pin fault or blame on anyone for those things I do understand, because I see them now through a revised-over-time lens and perspective. But ... in the area of unions ... I am still back to where I initially found myself when I encountered them back in the 80s because at that point my knowledge of computer programming stemmed primarily from 8086 assembly language, and later 80386 assembly language. I looked at low-level data as data, and not higher constructs. So, when a cast would not yield a conversion, but merely asserts to the compiler that the type is being knowingly converted from type A to type B, but no underlying data change takes place (such as a round operation in casting a floating point to an int), then I see no issue with such a reinterpretation of literal bits through a union to be any sort of issue, because that's what actually is happening in the cast. No real data is changed, which is what actually happens when the same types are accessed through a union. ----- I honestly can't understand what you find at odds with that reality, except that it's not "legal" through the C/C++ standards. What is your concern over this use of unions? Thank you, Rick C. Hodgin |
| 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