- About C++... - 3 Updates
- Defect Report: I/O streams lack support for binary number formatting - 8 Updates
- cmsg cancel <ngdi9p$epm$3@dont-email.me> - 6 Updates
- About my C++ synchronization library - 1 Update
- C++ synchronization objects library is here... - 4 Updates
- Utah C++ Programmers May, 2016: Concurrency and Parallelism with <thread> - 1 Update
- St. Paul, Minnesota - 1 Update
- Secure functions - 1 Update
| Ramine <ramine@1.1>: May 04 05:49PM -0700 Hello.... Now i will speak about C++ programming language. I have just learned C++ in 2 days and it after that it took me one more day to implement my C++ synchronization objects library, and it was easy for me to implement because i was already programmer and i have tested it thoroughly and i think it is working great, and now i think that C++ is a good language too, but as you have noticed i am an Object Pascal programmer who specializes in parallel programming and you will find all my projects here: https://sites.google.com/site/aminer68/ And you can download my C++ synchronization objects library from: https://sites.google.com/site/aminer68/c-synchronization-objects-library Thank you, Amine Moulay Ramdane. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 04 10:57PM +0100 On Wed, 4 May 2016 17:49:29 -0700 > https://sites.google.com/site/aminer68/ > And you can download my C++ synchronization objects library from: > https://sites.google.com/site/aminer68/c-synchronization-objects-library Please stop posting these repetitive posts. One post would have been enough. Instead you post 6 times in 1 hour 15 minutes, all most drivel. I realise your mental condition is difficult for you to cope with, but please don't make it a difficulty for us as well. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 04 06:03PM -0400 On 5/4/2016 5:57 PM, Chris Vine wrote: > enough. Instead you post 6 times in 1 hour 15 minutes, all most drivel. > I realise your mental condition is difficult for you to cope with, but > please don't make it a difficulty for us as well. Have you ever looked at his code? Typical of spammer code - I wouldn't let it near any project I worked on, in any language. But then if the libraries were any good, he wouldn't have to spam usenet. So that in itself should tell you something. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| stefan.heinzmann@gmail.com: May 04 06:00AM -0700 C++14 introduced binary literals to the core language. However, the I/O streams library has no support for formatting integers as binary numbers, in the same way as they can be formatted as hex or oct numbers. This is inconsistent. The resolution would include adding one new formatting flag to class std::ios_base in the basefield group. It could be named 'bin', unless there's a problem with this that I can't see. Furthermore, there would be the need for a corresponding stream manipulator. Unfortunately, I don't oversee where else in the standard there would have to be changes because of this. This would be a question for people with intimate knowledge of the stream library, I guess. Taking the current draft N4582, the formatting flags are defined in 27.5.3, and the manipulators are defined in 27.5.1, but there will certainly have to be changes in a number of other places. Cheers Stefan Heinzmann |
| Robert Wessel <robertwessel2@yahoo.com>: May 04 08:22AM -0500 On Wed, 4 May 2016 06:00:47 -0700 (PDT), stefan.heinzmann@gmail.com wrote: >Furthermore, there would be the need for a corresponding stream manipulator. >Unfortunately, I don't oversee where else in the standard there would have to be changes because of this. This would be a question for people with intimate knowledge of the stream library, I guess. >Taking the current draft N4582, the formatting flags are defined in 27.5.3, and the manipulators are defined in 27.5.1, but there will certainly have to be changes in a number of other places. Eh. There's really very little need to do binary formatted text I/O. Binary literals server a number of programming related purposes, but are not usually something you actually want to input or output. Sure, we can find an occassional use case here and there, but not something I really think needs any serious effort. There are also places where adding binary to text I/O would add some incompatibilities. What, for example, should strtol() or scanf() do with something that looked like a binary literal in the input? If you interpret it as such, you may well be changing existing behavior. Probably best to leave it alone. |
| stefan.heinzmann@gmail.com: May 04 06:51AM -0700 > Eh. There's really very little need to do binary formatted text I/O. > Binary literals server a number of programming related purposes, but > are not usually something you actually want to input or output. I'd say there's no less need than for octal output. If there was a good reason to support binary for literals, why doesn't the same reason apply for I/O? I frequently write low-level code which works directly with hardware, and binary would quite frequently be the best format for displaying the value of a register, for example. Or imagine writing a debugger. But even if you were right, wouldn't consistency alone be a good motivation already? > with something that looked like a binary literal in the input? If you > interpret it as such, you may well be changing existing behavior. > Probably best to leave it alone. Yes, there's a risk of changing the behavior in some corner cases. I haven't spent any time to find out what those cases are and whether they would have to be considered serious. That's open for debate. Anyway, strtol() and scanf() are C functions, not C++. I would opt for changing their behavior only once C starts supporting binary literals. That would be for the C standards group to consider. Cheers Stefan |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 04 06:18PM +0200 > I/O streams library has no support for formatting integers as binary > numbers, in the same way as they can be formatted as hex or oct > numbers. This is inconsistent. You can always just use std::bitset for that purpose; it converts to a string of 0 and 1 characters. Anyway, the correct place to post a defect report used to be comp.std.c++, but now it's a google group somewhere. The last defect report I posted, which was a real issue (lack of wide stream support for user defined conversion to wchar const*), received no reply and hasn't yet been fixed. As I recall I then contacted the person doing the screening work, whom I knew from Usenet earlier, and got the impression that something would be done. But it hasn't. I concluded then that the defect report process had stopped working in general, and later, when I saw some of the stuff in C++14, I concluded that even the committee had stopped working as a serious standardization body. Still if you want to try it you can find the group(s) over at isocpp.org. Cheers & hth., - Alf |
| stefan.heinzmann@gmail.com: May 04 10:39AM -0700 > You can always just use std::bitset for that purpose; it converts to a > string of 0 and 1 characters. Yes, I knew that. Still, thanks for the reminder, for it is not well known. To give credit to the library, there is a way of doing this, even when it is a bit obscure and not consistent with the other formatting options. > saw some of the stuff in C++14, I concluded that even the committee had > stopped working as a serious standardization body. > Still if you want to try it you can find the group(s) over at isocpp.org. Thanks for this guidance. I had lost contact with the C++ standardisation scene for some years, and I noticed that there wasn't much happening in comp.std.c++. I shall try my luck at isocpp.org. Cheers Stefan |
| Robert Wessel <robertwessel2@yahoo.com>: May 04 04:25PM -0500 On Wed, 4 May 2016 06:51:38 -0700 (PDT), stefan.heinzmann@gmail.com wrote: >> Binary literals server a number of programming related purposes, but >> are not usually something you actually want to input or output. >I'd say there's no less need than for octal output. If there was a good reason to support binary for literals, why doesn't the same reason apply for I/O? I frequently write low-level code which works directly with hardware, and binary would quite frequently be the best format for displaying the value of a register, for example. Or imagine writing a debugger. Adding octal (and hex) to some of the default input functions was a mistake. Having them as options would have made sense, and would probably have provided a path to adding binary text I/O as well. But we are where we are. And yes, there are small use cases for binary text I/O. >But even if you were right, wouldn't consistency alone be a good motivation already? Consistency is a good thing. Right up to the point where it gets in the way of a good, useful, and easy to implement feature (like binary literals), because it's difficult to figure out how to support it in places we really don't care about anyway. >> interpret it as such, you may well be changing existing behavior. >> Probably best to leave it alone. >Yes, there's a risk of changing the behavior in some corner cases. I haven't spent any time to find out what those cases are and whether they would have to be considered serious. That's open for debate. And the committee has always been far more reluctant to introduce changes that can cause even minor breakage. Even more so if it introduces silent *runtime* breakage. So my guess is that requiring the change to strtol or scanf would have made binary literals impossible to get through the committee. But if you can define a set of changes (possible even excluding the legacy C functions), that don't break anything (and the normal cin/cout stuff may be there), you may have a shot. And I certainly wouldn't object, I just would continue to mostly not care. >Anyway, strtol() and scanf() are C functions, not C++. I would opt for changing their behavior only once C starts supporting binary literals. That would be for the C standards group to consider. They're included in the C++ standard by reference. |
| Robert Wessel <robertwessel2@yahoo.com>: May 04 04:28PM -0500 On Wed, 04 May 2016 16:25:24 -0500, Robert Wessel >don't break anything (and the normal cin/cout stuff may be there), you >may have a shot. And I certainly wouldn't object, I just would >continue to mostly not care. Except to the extent that any time spent on pointless stuff like that takes them away from considering stuff I actually would like. |
| legalize+jeeves@mail.xmission.com (Richard): May 04 10:01PM [Please do not mail me a copy of your followup] Robert Wessel <robertwessel2@yahoo.com> spake the secret code >Except to the extent that any time spent on pointless stuff like that >takes them away from considering stuff I actually would like. Particularly since this is something that you can solve on your own with a user library and doesn't require a change in the standard in order to get on with your life and solving your problem. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| bleachbot <bleachbot@httrack.com>: May 04 09:28PM +0200 |
| bleachbot <bleachbot@httrack.com>: May 04 09:30PM +0200 |
| bleachbot <bleachbot@httrack.com>: May 04 10:07PM +0200 |
| bleachbot <bleachbot@httrack.com>: May 04 10:14PM +0200 |
| bleachbot <bleachbot@httrack.com>: May 04 10:46PM +0200 |
| bleachbot <bleachbot@httrack.com>: May 04 11:48PM +0200 |
| Ramine <ramine@1.1>: May 04 04:49PM -0700 Hello...... My SemaMonitor of C++ synchronization objects library is easy to use, it combines the combines all characteristics of a semaphore and an eventcount and also a windows Manual-reset event and also a windows Auto-reset event, here is its C++ interface: class SemaMonitor{ public: SemaMonitor(bool state, long2 InitialCount1=0,long2 MaximumCount1=INFINITE); ~SemaMonitor(); void wait(unsigned long mstime=INFINITE); void signal(); void signal_all(); void signal(long2 nbr); void setSignal(); void resetSignal(); long1 WaitersBlocked(); }; So when you set the first parameter that is state of the constructor to true. it will add the characteristic of a Semaphore to the to the Eventcount, so the signal will not be lost if the threads are not waiting for the SemaMonitor objects, but when you set the first parameter of the construtor to false, it will not behave like a Semaphore because if the threads are not waiting for the SemaCondvar or SemaMonitor the signal will be lost.. the parameters InitialCount1 and MaximumCount1 is the semaphore InitialCount and MaximumCount. The wait() method is for the threads to waiT on the SemaMonitor object for the signal to be signaled. and the signal() method will signal one time awaiting thread on the SemaMonitor object. the signal_all() method will signal all the waiting threads on the SemaMonitor object. the signal(long2 nbr) method will signal nbr number of waiting threads the setSignal() and resetSignal() methods behave like the windows Event object's methods that are setEvent() and resetEvent(). and WaitersBlocked() will return the number of waiting threads on the SemaMonitor object. As you have noticed my SemaMonitor is a powerful synchronization object. You can download this library from: https://sites.google.com/site/aminer68/c-synchronization-objects-library Thank you, Amine Moulay Ramdane. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: May 04 03:30PM -0700 Hello....... C++ synchronization objects library is here... Author: Amine Moulay Ramdane Email: aminer@videotron.ca Description: This library contains three synchronization objects, first one is my scalable SeqlockX that is a variant of Seqlock that eliminates the weakness of Seqlock that is livelock, and second is my scalable MLock that is a scalable lock , and third is my SemaMonitor that combines all characteristics of a semaphore and an eventcount and also a windows Manual-reset event and also a windows Auto-reset event. Please read the readme files inside the zip file to know more about them.. Language: GNU C++ and Visual C++ Operating Systems: Windows, Linux, Unix... You can download this library from: https://sites.google.com/site/aminer68/c-synchronization-objects-library Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: May 04 03:32PM -0700 Hello, You can download the source of my sycnhronization objects here: https://sites.google.com/site/aminer68/ Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: May 04 04:08PM -0700 Hello, If you take a look at the zip file , you will notice that it contains the DLLs Object pascal source codes, to compile those DLLs source codes you will have to download my SemaCondvar Object pascal source code and my SeqlockX Object pascal source code and my scalable MLock Object pascal source code from here: https://sites.google.com/site/aminer68/ Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: May 04 04:15PM -0700 Hello, I have compiled and included the 32 bit and 64 bit windows Dynamic Link Link libraries inside the zip file, if you want to compile the dynmic link libraries for Unix and Linux and OSX on (x86) , please download the source code of my SemaCondvar and my scalable SeqlockX and my scalable MLock and compile them yourself. Thank you, Amine Moulay Ramdane. |
| legalize+jeeves@mail.xmission.com (Richard): May 04 05:53PM [Please do not mail me a copy of your followup] This month, Greg Hodgson will give us a presentation on concurrency and parallelism in C++ using the standard <thread> header. Thanks for volunteering, Greg! Dinner will be provided, so please RSVP for a proper head count on food. Dinner provided by ConsultNet. Thanks, ConsultNet! <http://www.meetup.com/Utah-Cpp-Programmers/events/230498165/> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| woodbrian77@gmail.com: May 04 10:31AM -0700 On Wednesday, April 13, 2016 at 4:46:38 PM UTC-5, Öö Tiib wrote: > > in his own rented house and welcomed all who came to see him." Acts 28:30 > Does that puzzle mean that the C++ meeting in St. Paul, Minnesota > that you organize will last two whole years? No. Long term I'll probably move to a more conservative state. > that they would like to see participating. Such invitations typically > include times, dates and agendas. Sometimes they also phone personally > or contact over Skype and ask for opinion or advice and the like. Maybe I'll do some of that in the future. For now I just "cast my bread upon the waters." Brian Ebenezer Enterprises - Making programming fun again. http://webEbenezer.net |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 04 10:12AM -0700 I had an idea that perhaps C and C++ could both benefit from: the addition of an ability to create secure functions. int functionName(int a) secure { // Normal code starts here } unsecure { // If an unknown function attempts to call, falls through here // If after a test, to actually enter the function simply // call it from here, as the compiler will know this call and // establish the token validation for you. return(functionName(a)); } By adding this feature, and the ability to tag this "unsecure { }" block to the tail of the body, the compiler could assign a random value that is placed in a register (or passed as an extra invisible parameter), which can be scrutinized upon entry to make sure it's coming from a known location. It would be known because the compiler would inject the requisite code to meet the conditions of the test it also injects. As such, only known-at-compile-time calls to the function would be guaranteed to come from a source that contains the token, making secure access into the function something that can be known. Simple function entry test: ; void functionName(void) : secure cmp rax,_this_functions_secure_token_number jnz branch_to_unsecure_entry ; Normal code starts here With this test, and by placing the code in an execute-only block, it would prevent external callers from being able to call unaware. It would require intimate knowledge of the executable on disk, for example, as these tokens could be completely randomized during installation, or when by the OS at the very instant the application is launched and loaded from disk. It would also provide some known information about whether or not params passed by reference are, in fact, NOT NULL (because the compiler will not assign NULL values to pass in, and then only if the unsecure block is entered would any passed parameters need to be tested for NULL, for example. Or, in the alternative, the caller could be flatly rejected and some kind of error or warning given for the unexpected intrusive access). This security would incur a minimal performance hit, and provide the ability to know that the code in the project is the only and actual code being used to call the function. It would be a way to prevent unwanted, or unexpected access to something that shouldn't have it. Best regards, 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