- "Experimenting with a Proposed Standard Drawing Library for the C++ language" - 2 Updates
- memcpy - 4 Updates
- Counter-example to Rice's Theorem ? - 4 Updates
- pre- and post-conditions - 5 Updates
- preprocessor when included - 1 Update
| Lynn McGuire <lmc@winsim.com>: Feb 07 01:22PM -0600 On 2/4/2015 6:32 AM, peter koch wrote: > But there is also fltk and QT. And then there are all the nonportable libraries lying around. > I use WxWidgets because it is the best choice for me (I will not use QT because of licensing issues and fltk was simply to lowlevel (and visually ugly) for me). But I must say that the programming interface is very far from what I would expect a good C++ library to have. This is a deliberate choice from the Wxwidgets developers and probably related to history and a need to support ancient compilers. But it is also a very good reason to dismiss it as a candidate for standardisation. > /Peter What platforms have you used WxWidgets on? We are on Windows only right now. We use MFC for our main window and we wrote our own UITK for our dialogs. We have several hundred dialogs with extensively hand built controls and mannerisms. Thanks, Lynn |
| peter koch <peter.koch.larsen@gmail.com>: Feb 07 01:54PM -0800 Den lørdag den 7. februar 2015 kl. 20.23.23 UTC+1 skrev Lynn McGuire: > On 2/4/2015 6:32 AM, peter koch wrote: > > Den tirsdag den 3. februar 2015 kl. 23.06.24 UTC+1 skrev Lynn McGuire: [snip] > > I use WxWidgets because it is the best choice for me (I will not use QT because of licensing issues and fltk was simply to lowlevel (and visually ugly) for me). But I must say that the programming interface is very far from what I would expect a good C++ library to have. This is a deliberate choice from the Wxwidgets developers and probably related to history and a need to support ancient compilers. But it is also a very good reason to dismiss it as a candidate for standardisation. > > /Peter > What platforms have you used WxWidgets on? So far only Windows. But I expect to port to Linux soon. > We are on Windows only right now. We use MFC for our main window and we > wrote our own UITK for our dialogs. We have several hundred dialogs > with extensively hand built controls and mannerisms. Okay? I do not know why you gave me that information. /Peter |
| jt@toerring.de (Jens Thoms Toerring): Feb 07 12:48AM > what happens when two people work together where one uses it and one > does not, or similarly when you write your interface with it and my code > does not use it, but needs to call your interface or vica versa. That's opening a new can of worms;-) I guess thaet we can somehow agree that the use of of types from <cstdint> sometimes can be war- ranted, can't we? The other question seems to be what to do with cow-orkers creating a mess. Kiling them would be the obvious so- lution, but there can be certain drawbacks. Educating them is quite a task one isn't going to be paid for. I definitely have no silver-bullet solution for that problem:-( > There has to be a boundary somewhere. I already asked Ian, but I'll ask > again. What are you going to do at that boundary? What is someone else > going to do? I don't know what you mean by "boundaries", so I don't feel like I can make any reasonable comments. From what others have been replying in this point, it's about interfacing with external code you have to work with. And if this is what it's about then, as others have already said, use what- ever that library (or maybe even OS) wants to receive and returns and, if necessary sanitize the results of calls be- fore assigning them to the types you want to use. On other point: from applicatins you normally doesn't "talk" to the OS itself, you do calls through some library (in the most common case the standard C library, but, when having to interact with a device, with a library "wrapped" around the device driver. So wehn you write a device driver you usually also write some library for all but the hard-core hackers to use the driver. When writing such a library you've to consider what people will usually pass it to. If the daya that are going to the kernel must be unsigned 16-bit integers you have two alternatives: a) Accept any kind of int and check if it's between 0 and 65535 and flag some error (before calling anyting in the kernel). when the value received is not in that range. And point out in the accompanying documentation that that argument *must* be in that range. b) Make the argument explicitely an ''uint16_t. There are god argiments for both approaches. With a) people get an error indicationg if they haven't read the documen- tation (although only at run-time, so it might be an innocent user of the program using the library that gets a crash or some weird behaviour of the program!). With b) the developer should get at a compiler warning when using an unsuitable type- unless (s)he was so stupid enough to disable relevant compiler warnings. My preference is on b) in the hope that most developers aren't stupid (and issues only found by the final users have a ten- dency to be very hard to find and reproduce...). > It isn't hard for the developer, it's hard for his dependencies. But this is just the same problem - also your deoendencies have been written by developers of your dependencies. > I mean really, all we have to do is change 32 bit pointers to 64 bit > pointers, check places where we are doing bitwise operations, and carry > on. That's been my experience. To be honest I've never worried about the size of a pointer ever. But that may be an effect of never havin been much in- volvd with DOS/Windows programming. I've read about 'NEAR' and 'FAR' pointers, of course, but always considered mayself lucky not having to get involved in that morass;-) The point about bitwie operations I simply don't understand. What do you see as the problem there? > You're right. I've been in my Windows bubble. The employers and their > customers are the factor there. Fair point. But there are also a few projects I would have prefered to run away screemin screeming;-) > different keyboard shortcuts to get the same thing done I can with a > mouse click. But I can accept that is their strange world and it must be > there for a good reason. Well, for me it's as hard to understand how poeple can work with these graphics-only tools;-) I raise your "125 keyboard shortcuts" the simple task of setting a PATH environment variable under Windows: the last time I counted it took 13 mouse-clicks to finally arrive at the relevant window. And that had an input field that let you see about 40 letters, but contained ät least half a kB of text. And, when I finally had managed to add what I needed, it took 7 more mouse clicks to close all those windows I had been opening to just get there (and, of course, I made a typo and had to repeat the whole procedure). Give me a command line and I'll happily type PATH=$PATH:/path/to/what/I/need/to/add anytime and I won't complain;-) But then tools are tools. Some people like one kind of tool, others prefer a different one. As long as I don't try to force you to use the ones I'm comfortable with I have no reason to get mad when you prefer a different one. A bit of friendly banter bout it is quite ok, since it can make the both sides curious about what's happening on the other side of fence. > > types" approach you're throwing out the baby with the bath. > Then we can agree. Don't use typedefed types without reason and I won't > delete them until I get your reason from you. Complete ACK. Nothing should be left in a program of any- thing for which there's no good reason. When, after a day of work, the LOC is down by 1000 that definitly was a quite productive day for me (as long as everything still works;-) Best regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| Robert Wessel <robertwessel2@yahoo.com>: Feb 07 12:37AM -0600 On Fri, 06 Feb 2015 15:05:56 -0600, Christopher Pisz >Rethink your OS seems to be a common answer, but a totally unreasonable >one. Who in their right mind would tell $5,000,000 worth of customers, >"sorry guys, we don't do your OS anymore." I dunno - MS recently told half a billion Windows XP users that "we don't do your OS anymore". Surely those are worth at *least* a penny each. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 07 08:53AM -0800 On Thursday, 5 February 2015 21:41:55 UTC+2, Christopher Pisz wrote: > If every single developer working on your project uses the same types. > No problem! If you have a coding standard, then that is the case. No > problem! It is the case with me, yes. I always aim to have coding standard to reduce such pointless non-constructive discussions about style that lead to nowhere. When a member of team introduces a non-compliance defect then that "cosmetic" issue is assigned to him. When the coding standard changes then all non-compliance issues with old wording are closed as "obsolete" and all non-compliance with new wording introduce new "cosmetic" issues assigned to no-one. It all can be automated in big part. Guys who can't automate such boring stuff are just weenies not software developers. > My problem is, as always, mixing one thing with another and breaking > software as a result. There are no such problems with coding standard. For example team is used to coding standard where variables representing texts may be only of type 'std::string' or 'pfm::string_view' (implemented like http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3921.html') that must contain UTF-8 encoded texts. They can still accept to take under maintenance some code base that uses all of 'char*', 'wchar_t*', '_bstr_t', 'QString', 'CString', 'std::string', 'std::wstring' and various 'typedef's of those types for storing and passing texts. It just means a nice pile of issues in code base. Pile of issues is common situation with useful software ... thousand here or there. |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Feb 07 11:30AM -0700 On Fri, 06 Feb 2015 22:01:07 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Select 'System Interfaces' from the left-hand upper frame. >Then select "system Interfaces" from the left-hand lower frame. >Select interface for which you are interested in the signature. It looks like at least one pair of functions, a64l and l64a, could have used some fixed-size types: === #include <stdlib.h> long a64l(const char *s); char *l64a(long value); These functions maintain numbers stored in radix-64 ASCII characters. This is a notation by which 32-bit integers can be represented by up to six characters; each character represents a digit in radix-64 notation. If the type long contains more than 32 bits, only the low-order 32 bits shall be used for these operations. === Louis |
| "X.Y. Newberry" <newberryxy@gmail.com>: Feb 06 06:04PM -0800 Peter Olcott wrote: > whether or not it can correctly decide the halting property for every > element of > Program x Inputs. I think it may be possible to detect if a program calls itself as a subroutine and partition the space into positively halting, positively not halting, and self-referential. This was proposed by Herc on this board and it may be the right idea. The self-referential subset is undecidable. -- X.Y. Newberry If Jack says 'What I am saying at this very moment is not true', we can successfully and truly assert that he did not utter a truth: 'What Jack said is not true'. But it is hardly conceivable that Jack's utterance is true by virtue of its success in attributing non-truth to itself. Haim Gaifman |
| Peter Olcott <OCR4Screen>: Feb 06 08:12PM -0600 On 2/6/2015 8:04 PM, X.Y. Newberry wrote: > not halting, and self-referential. This was proposed by Herc on this > board and it may be the right idea. The self-referential subset is > undecidable. It seems that Kaz pointed out that It is not as simple as that. He asked about equivalent programs. It then occurred to me that if we simply assign 123 to a dummy variable at the beginning of the program we could have an equivalent program that is not the same program. I am not going to bother with categorically examining every possible case where ERROR might be returned other than the single common factor that: (halts(p,i) != (phd_2(p,i) _returns_FALSE)) <and> (halts(p,i) != (phd_2(p,i)_returns_TRUE)) |
| Christian Gollwitzer <auriocus@gmx.de>: Feb 07 11:03AM +0100 Am 06.02.15 um 22:20 schrieb Peter Olcott: > report a value corresponding to halts(p,i) or report that it is not > possible for it to report a value corresponding to halts(p,i) for > every (p,i) in Programs x Inputs. I think this is easy to prove, unless I misunderstood that sentence. You could just run the given program for, say, 1000 instructions. If it halts during that time, return TRUE. If not, return ERROR. Christian |
| Peter Olcott <OCR4Screen>: Feb 07 11:57AM -0600 On 2/7/2015 4:03 AM, Christian Gollwitzer wrote: > could just run the given program for, say, 1000 instructions. If it > halts during that time, return TRUE. If not, return ERROR. > Christian Thanks to Ben's most excellent help I may *finally* have a clear way of saying *exactly* what I mean. There exists a TM, m, such that for every (p, i) in Sigma* x Sigma* m(p, i) halts with m(p, i) in {TRUE, FALSE, ERROR} <and> (halts(p, i) == m(p, i) <xor> (halts(p, i) != (m(p, i) = FALSE) <and> halts(p, i) != (m(p, i) = TRUE))) |
| Ruben Safir <mrbrklyn@panix.com>: Feb 07 12:57AM > already. > Once you figure the basic conditions that allow this, figuring out a > particular case will be much simpler. are you talking about an integer overflow? shouldn't that trigger an error? |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 06 09:13PM -0600 Ruben Safir <mrbrklyn@panix.com> wrote in > are you talking about an integer overflow? > shouldn't that trigger an error? With unsigned types there is no error, the wrap-around behavior is just defined as the correct behavior. With signed types integer overflow is an error and leads to UB. Unfortunately most of the times this UB means you silently get the same wrap-around beahvior, but at least in principle it could be detected and reported properly. |
| David Brown <david.brown@hesbynett.no>: Feb 07 02:00PM +0100 On 07/02/15 04:13, Paavo Helde wrote: > Unfortunately most of the times this UB means you silently get the same > wrap-around beahvior, but at least in principle it could be detected and > reported properly. And if the compiler can predict that integer overflow will always occur, then it can use this guaranteed UB to optimise the code. For example, given the following code: int16_t a = 0x7fff; int16_t b = a + 2; if (b == 1) foo(); the compiler can choose whether to do foo() or not. Conversely, since the compiler knows that the user doesn't care about UB, it can treat code as though the UB cannot happen. So you might think that you can detect signed overflow with code like this: int checkedOverflow(int a, b) { bool sa = (a < 0); bool sb = (b < 0); int c = a + b; bool sc = (c < 0); if (sa && sb && !sc) { printf("Added two negatives and got a positive!\n"); } if (!sa && !sb && sc) { printf("Added two positives and got a negative!\n"); } return c; } Since the compiler knows that signed overflow is UB, and you don't care about UB, it can remove the checks and printfs. |
| "Osmium" <r124c4u102@comcast.net>: Feb 07 07:50AM -0600 "Ruben Safir" >> particular case will be much simpler. > are you talking about an integer overflow? > shouldn't that trigger an error? Yes it should, in a perfect world. But most programming languages simply let the programmer blunder on. |
| Christian Gollwitzer <auriocus@gmx.de>: Feb 07 03:30PM +0100 Am 07.02.15 um 14:00 schrieb David Brown: >> reported properly. > And if the compiler can predict that integer overflow will always occur, > then it can use this guaranteed UB to optimise the code. This is really one of the most stupid problems with C and C++. Almost all modern CPUs generate integer overflow flags in hardware (and the carry flag for unsigned wrap around). Also saturated arithmetics is available on some machines. Why is there no clean way to access this from the compiled language? It's not even slower to insert checks around the operation in question, it is also less clear than the equivalent in assembly code (jump on overflow flag). Sure there is, e.g., https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html but still a simple clean standard way is lacking. Christian |
| red floyd <no.spam.here@its.invalid>: Feb 06 06:54PM -0800 > //etc > } > 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment