- memcpy - 11 Updates
- showing a ncurses window - 6 Updates
| Ian Collins <ian-news@hotmail.com>: Feb 06 08:18AM +1300 Christopher Pisz wrote: >>> standard native C++. >> So how do you interface with networking functions in your perfect, pure >> windows world? Care to address this question? >> How then is this different form someone assigning a type that does not >> match a naked type? > Because it is hidden. It matched at one time and not at another. Exactly. Many days of programmer time have been wasted porting code to different bit sized versions of the same platform because the original programmers made assumptions about the sizes of primitive types. -- Ian Collins |
| "Öö Tiib" <ootiib@hot.ee>: Feb 05 11:21AM -0800 On Thursday, 5 February 2015 19:40:04 UTC+2, Christopher Pisz wrote: > the target platform is known, and has been specified in the > requirements, and will never change, alongside programmers who will not, > should get hit by a bus. What is the point to write app that compiles only for windows 7? Ok, 4 years later it will perhaps still run with odd quirks in some sort of oldie crap compatibility pane of Windows 10. > Fibble clearly stated he will _always_ use typedefed primitives _everywhere_ So what? It may be even *required* by coding standard: http://www.codingstandard.com/rule/7-1-6-use-class-types-or-typedefs-to-abstract-scalar-quantities-and-standard-integer-types/ If the owners of code base have decided compliance with such then *nothing* to do. Your code will not pass review and will be reverted. If you rant how lot wiser you are then you will be fired as incompetent. |
| Christopher Pisz <nospam@notanaddress.com>: Feb 05 01:29PM -0600 On 2/5/2015 1:24 AM, Ian Collins wrote: > lucky enough to code in a bubble that doesn't interface with the real > world. Many of us don't and that most certainly does not make us > "C-style" programmers. Well you aren't most programmers. You are Ian Collins, guru #2 on the newsgroup, and one could have some faith that you know what you are doing. That isn't the case with the OP and code like what the OP wrote is what I get to fix all day. Where you look at it and say to yourself, "What in the hell?!" All rants aside, what are you going to do when you've used these fixed types and have to call code not in your control that returns types that aren't fixed? Or when perhaps third party code calls your code? The whole point is now negated, no? There is a boundry somewhere, what do you do at that boundry? You'd have to ensure the entire execution path, every developer, everywhere is using these same types, 100% contained, no? |
| Ian Collins <ian-news@hotmail.com>: Feb 06 08:38AM +1300 Christopher Pisz wrote: >> world. Many of us don't and that most certainly does not make us >> "C-style" programmers. > Well you aren't most programmers. I'd consider myself a typical non-windows programmer. Actually I'd go further: I'm a typical programmer who has to deal with the real world, both physical and networked. > aren't fixed? Or when perhaps third party code calls your code? > The whole point is now negated, no? There is a boundry somewhere, what > do you do at that boundry? The boundaries are the hardware and operating system libraries which use fixed width types extensively. > You'd have to ensure the entire execution path, every developer, > everywhere is using these same types, 100% contained, no? That's a question for the OS developers not their users such as me. -- Ian Collins |
| Christopher Pisz <nospam@notanaddress.com>: Feb 05 01:41PM -0600 On 2/5/2015 1:21 PM, Öö Tiib wrote: > What is the point to write app that compiles only for windows 7? > Ok, 4 years later it will perhaps still run with odd quirks > in some sort of oldie crap compatibility pane of Windows 10. You don't write an app for Windows 7. You write it for Windows version X going forward for a target of y number of years. The size of primitive types does not change on every single version of Windows. In fact, it only changes when the _architecture_ changes, in which case you now have a new target architecture and far far more to consider then the size of primitive types. We're still sorting out the move from x86 to x64 how many years later? In reality, it is usually the case where App X supports customers using XP through Windows 7. Software has a lifetime. It is supposed to be 10 years. Sadly, people are cheap, and they try to stretch it over 50, which causes these problems. You can't guarantee your code will work in 50 years no matter how many mantras you follow. > If the owners of code base have decided compliance with such then > *nothing* to do. Your code will not pass review and will be reverted. > If you rant how lot wiser you are then you will be fired as incompetent. People are regurgitating what I've already said. 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! My problem is, as always, mixing one thing with another and breaking software as a result. |
| Martijn Lievaart <m@rtij.nl.invlalid>: Feb 05 10:17PM +0100 On Wed, 04 Feb 2015 15:31:55 -0600, Christopher Pisz wrote: > one byte unsigned char. Unsupported > OS or compiler options."); > } You are aware that this will never throw, are you? A char (unsigned or not) has by definition a sizeof 1, and is by (very confusing) definition one byte. This has nothing to do with the number of bits in a (C) byte. If you want to check wether a (C) byte has 8 bits, check if CHAR_BIT==8. M4 |
| Martijn Lievaart <m@rtij.nl.invlalid>: Feb 05 11:50PM +0100 On Thu, 05 Feb 2015 13:41:42 -0600, Christopher Pisz wrote: > We're still sorting out the move from x86 to x64 how > many years later? Bingo! M4 |
| Martijn Lievaart <m@rtij.nl.invlalid>: Feb 05 11:59PM +0100 On Wed, 04 Feb 2015 19:01:11 -0600, Christopher Pisz wrote: > Windows made a define for BYTE. Some use it some don't. I'd rather never > see it and use unsigned char, because unsigned char is a byte and is > part of the language itself already. Similar to the stdint.h argument. Well, a BYTE is 8 bits on the Windows implementations I'm familiar with. An unsigned char can be anything, as long as it is 8 bits or more. I personally prefer uint8_t if I need 8 bits. M4 |
| Martijn Lievaart <m@rtij.nl.invlalid>: Feb 05 11:57PM +0100 On Thu, 05 Feb 2015 00:11:07 +0000, Jens Thoms Toerring wrote: > But I still am convinced that the types from stdint.h exist for a good > reason - it's just that you shouldn't use a knife as a srewdriver unless > there's no alternative. Exactly. It's a POS not because of the standard types, but because it's a POS. Could have done that with the Windows.h types too. Oh, wait, there are Windows.h types in there. M4 |
| Ian Collins <ian-news@hotmail.com>: Feb 06 12:05PM +1300 Christopher Pisz wrote: > We're still sorting out the move from x86 to x64 how > many years later? In some parts of the windows world, maybe. In the land of POSIX these problems were solved over a decade ago. Solved in large part due to the adoption of fixed width types to remove ambiguities from interfaces. -- Ian Collins |
| jt@toerring.de (Jens Thoms Toerring): Feb 05 11:14PM > only changes when the _architecture_ changes, in which case you now have > a new target architecture and far far more to consider then the size of > primitive types. You're really making a mountain out of an mole hill. In all my replies to you I've often used the word "architecture-agnostic" and similar and I meant it. It's really not too complicated to write code that works on a lot of architectures out of the box without any fiddling. One of my pet prjects is a Perl module, which needs some C code (could also be done in C++) for, you may have guessed it, determine the exact sizes of some variables that need to be passed to the OS and back. It has been become used in the Debian installer, so it needs to work on, at the last count, 14 different types of systems. And I haven't received a single complaint about that (there were some other issues but not related to the C part). Also, beside one idiotic mistake I made, all my Linux device drivers did work without a hitch when trying to compile and run them for x64 when they had been written and tested only on x86. And if I can do it so can you. But to achieve that I definitely needed to use types for which I knew exactly what sizes they had, not some "could be that or alsosomething else" types. > We're still sorting out the move from x86 to x64 how > many years later? I always had the suspicion that much of the trouble Microsoft had in porting to 64-bit systems (and a lot of related problems) actually were a result of an attitude similar to yours, i.e., labouring under a "will never change" assumption. The only port of Windows (of the back then rather fresh NT) before the recent ARM port (which also seems to be a dead end) I am aware of was for the Alpha processor around 1998 or so, and that ended rather abruptly. So, everything done on Windows for a long time was restricted to a single architecture. Contrast that to other systems like Linux or the different flavour of BSD, which every other month make it known that there's another supported archi- tecture. If that "bunch of hobbyists" can do it can it really be that hard? My take on that is that people never having been exposed to anything but Windows have a severe disadvantage because they never have seen anything of the world except their own town and believe that that's all there is. For them it's hard to under- stand how one could do anything that's architecture-independent and thus probably assume that it's rocket science. But it really isn't, it's mostly revolves around a few things to keep in mind. > years. Sadly, people are cheap, and they try to stretch it over 50, > which causes these problems. You can't guarantee your code will work in > 50 years no matter how many mantras you follow. Well, of course, I can't guarantee anything like that (and I for sure will be dead in 50 years;-) but a lot of the stuff I wrote 20 years ago still compiles and works quite fine (without more than a few minutes of maintainance - the worst problem is when a library you used back than has been gone the way of the dodo and needs replacing). > 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! I understand your point - having to deal with code that is littered with unnecessary types and casts and whatever is a PITA, but with your "avoid everything but the most basic types" approach you're throwing out the baby with the bath. How many types are ok? In normal live I tend to use the basic types, i.e. bool, char, the three or four types of ints plus size_t and float and double. Then, I sometimes need exact sized types and then a few additinal types from POSIX. And, of course, those forced on me by libraries I need. But that's it. But when I just look at the "Windows API Data Types" page https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx I see a lot more types (including a lot of exact sized types) than I know from <cstdint> - but, of course, with different names;-). I normally tend to see less different types in weeks of work. I guess when you're working on Windows you'll have to have all of them memorized and so shouldn't have much trouble with e.g 'int32_t' instead of 'INT32'... Perhaps you should make a point of avoiding those ugly Windows API types and instead get people to use just the fewer relevant and easier to grok ones from <cstdint>;-) Best regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| red floyd <no.spam@its.invalid>: Feb 05 11:32AM -0800 On 2/5/2015 11:11 AM, alexo wrote: > obscure as I wrongly thought, I can't get such a simple action as > showing a window on the console screen. > Could you please tel me what I missed in this example? [redacted] You asked in the wrong group? 1. Your code is pure C 2. curses/ncurses is not part of the C++ standard. 3. You should have asked somewhere in the comp.unix hierarcy. See FAQ 5.9 http://www.parashift.com/c++-faq-lite/which-newsgroup.html |
| Melzzzzz <mel@zzzzz.com>: Feb 05 08:44PM +0100 On Thu, 05 Feb 2015 11:32:40 -0800 > [redacted] > You asked in the wrong group? > 1. Your code is pure C [bmaxa@maxa-pc examples]$ g++ -Wall -c curses.cpp -o curses.o It compiles without warning as C++,,, |
| alexo <alessandro@inwind.it>: Feb 05 10:11PM +0100 Il 05/02/2015 20:32, red floyd ha scritto: > 2. curses/ncurses is not part of the C++ standard. > 3. You should have asked somewhere in the comp.unix hierarcy. > See FAQ 5.9 http://www.parashift.com/c++-faq-lite/which-newsgroup.html I know it is not part of the C++; And I know that my code is C code. I'll post it somewhere else, but I thought this was a good place to start from. Does anyone of you ever used this library? thank you |
| Melzzzzz <mel@zzzzz.com>: Feb 05 11:01PM +0100 On Thu, 05 Feb 2015 22:11:12 +0100 > I'll post it somewhere else, but I thought this was a good place to > start from. > Does anyone of you ever used this library? I used curses in 1992-93 on dumb terminals under AT&T Unix. Can't remember it ... |
| Ian Collins <ian-news@hotmail.com>: Feb 06 11:05AM +1300 alexo wrote: > I know it is not part of the C++; And I know that my code is C code. > I'll post it somewhere else, but I thought this was a good place to > start from. Try comp.unix.programmer > Does anyone of you ever used this library? Along time ago in a land far away. -- Ian Collins |
| Christopher Pisz <nospam@notanaddress.com>: Feb 05 04:14PM -0600 On 2/5/2015 1:44 PM, Melzzzzz wrote: >> 1. Your code is pure C > [bmaxa@maxa-pc examples]$ g++ -Wall -c curses.cpp -o curses.o > It compiles without warning as C++,,, When C++ compilers compile C, it does not make it C++. Sure as heck doesn't compile on my compiler. |
| 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