- memcpy - 24 Updates
- Strange structure initialization problem. - 1 Update
| "Öö Tiib" <ootiib@hot.ee>: Feb 11 05:22PM -0800 On Wednesday, 11 February 2015 21:42:48 UTC+2, Scott Lurndal wrote: > >> switch to being a FORTRAN programmer and punch my code into cards. > >Modern Fortran is well supported on Solaris :) > Although card readers never were supported on Solaris :-) You people mean punch-cards? These were funny. Are smart-card readers supported? |
| "Öö Tiib" <ootiib@hot.ee>: Feb 11 05:32PM -0800 On Wednesday, 11 February 2015 23:46:47 UTC+2, Vir Campestris wrote: > > habits. > I think Android is a pretty important market too. The trouble is there > are a variety of CPUs, so you really need to stick to Java. Overall C++ is fine on Android. Basically the "variety" means ARMv7 and x86. If GUI framework is needed ... then Qt works on it. |
| Luca Risolia <luca.risolia@linux-projects.org>: Feb 12 09:57AM +0100 On 11/02/2015 22:46, Vir Campestris wrote: > On 11/02/2015 08:58, David Brown wrote: And as you should have learned >> habits. > I think Android is a pretty important market too. The trouble is there > are a variety of CPUs, so you really need to stick to Java. It's a well known fact that C++ is more portable than Java. |
| David Brown <david.brown@hesbynett.no>: Feb 12 11:09AM +0100 On 11/02/15 17:48, Christopher Pisz wrote: >> simply good programming practice rather than continuing DOS/Windows bad >> habits. > Then what does "reconsider your OS" mean? Assume that Mr. Flibble's comments are either jokes or exaggerations, except when he is discussing sausages. > going to continue to use a 14 year old OS for how long? Even after > hearing "Sorry we can't help you. Your OS is unsupported" in response to > almost every support call they make to anyone? I never said that I expect MS to support XP any longer. (I cannot say I have ever had much use for MS support for any software, but that's another matter.) I simply said that you are wrong to think that any significant (or even /measurable/) proportion of XP users will upgrade their OS - the figure will be closer to 1% than 99%. And will many will /replace/ their entire computer with a newer one running a newer OS, many still seem to be happy to continue with XP. "If it ain't broken, don't fix it" works for many computer users - and XP does a perfectly good job for a great many people. > I believe that number to be much lower Believe what you want - my figures come from a very quick google search on the topic, which rates higher than a completely invented and unrealistic figure. Of course, there are different ways to measure the share of XP - is it the percentage of computers visiting major websites, or the percentage of computers in daily use, or the percentage of new computers? Do you count virtual machines? > and I believe it is 1) Companies > penny pinching who will find themselves left with little choice. Few things cause more wasted time and money for companies than being forced to replace existing working systems and software with new, different systems and software. This is why companies often spend significant money and effort in order to keep older systems and avoid changes. Thus many companies paid extra to keep XP until Win7 was well established and unavoidable (most managed to skip Vista entirely), and they are again paying extra in order to keep Win7 and avoid Win8. > use who only surfs the internet in IE 6 and does little else, whom will > also upgrade after his web pages stop loading without error in the near > future. No, he will not upgrade - again, /no one/ upgrades their Windows OS. Joe may eventually buy a new computer, or perhaps a pad of some sort - but he will not upgrade his OS. > The number of technologies that are not available on XP is a problem. > I believe you can only run .NET framework 4 and lower and DX9 and lower > on XP. People use XP on older machines, not new ones. They don't run new, big and demanding programs on those machines - because the hardware is not powerful enough. There will be occasional problems because some half-wit Windows developer has decided that even though his program is small and simple, it will insist on a pile of "latest and greatest" dotnet libraries. The XP user has lived without that program for years, and will probably continue to do so for years. And the XP user will run their demanding 3D games on a Playstation or X-Box. |
| Melzzzzz <mel@zzzzz.com>: Feb 12 01:15PM +0100 On Thu, 12 Feb 2015 09:57:16 +0100 > > I think Android is a pretty important market too. The trouble is > > there are a variety of CPUs, so you really need to stick to Java. > It's a well known fact that C++ is more portable than Java. How so? |
| Cholo Lennon <chololennon@hotmail.com>: Feb 12 10:32AM -0300 On 02/12/2015 05:57 AM, Luca Risolia wrote: >> I think Android is a pretty important market too. The trouble is there >> are a variety of CPUs, so you really need to stick to Java. > It's a well known fact that C++ is more portable than Java. Can you elaborate a little more your idea? I've been programming in C/C++ since late 80s and in Java since late 90s. Currently I develop multi platform telecom applications in C++ and Java that run on Windows/Linux (32/64) and Solaris (intel/sparc). IMHO the C++ portability is a nightmare. C++ is even not portable across C++ compilers! Several services of our portable base infrastructure (written in C++) are being re-written in Java to avoid maintenance issues: add new core features in several platforms or modify code and recompile the entire base is very, very time-consuming :-( Regards -- Cholo Lennon Bs.As. ARG |
| Luca Risolia <luca.risolia@linux-projects.org>: Feb 12 03:02PM +0100 On 12/02/2015 14:32, Cholo Lennon wrote: > Java that run on Windows/Linux (32/64) and Solaris (intel/sparc). IMHO > the C++ portability is a nightmare. C++ is even not portable across C++ > compilers! Hard to believe. Most of the time that's because of you writing non portable code or - more rarely nowadays - because of compilers not being fully compliant, not because of the language not being portable. Don't forget that C++ is designed around the concept of abstract machine, which actually includes *a lot of* concrete platforms, more than the number of platforms on which Java can be supported. |
| Luca Risolia <luca.risolia@linux-projects.org>: Feb 12 03:25PM +0100 On 12/02/2015 13:15, Melzzzzz wrote: >>> there are a variety of CPUs, so you really need to stick to Java. >> It's a well known fact that C++ is more portable than Java. > How so? One big example for all? Sometime ago dropbox decided to use C++ to share the code of their core components between Android and IOS. The reason and the advantages are obvious, as only C++ is supported on *both* the platforms, while neither Objective-C nor Java are. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 12 06:27AM -0800 On Thursday, 12 February 2015 15:32:51 UTC+2, Cholo Lennon wrote: > Java that run on Windows/Linux (32/64) and Solaris (intel/sparc). IMHO > the C++ portability is a nightmare. C++ is even not portable across C++ > compilers! Sure, if your coders use some weird, compiler-specific or platform-specific constructs. The listed things run portable code from scratch both C++ and Java. However "telecom"? That sounds like all that mobile crap. Add OS-X and all the iOS hand-helds plus Android to picture and it becomes slightly interesting with C++ but quite a challenge with Java. > in C++) are being re-written in Java to avoid maintenance issues: add > new core features in several platforms or modify code and recompile the > entire base is very, very time-consuming :-( Where it is written that you must build everything on your laptop? Use build farm if compilation for all supported platforms is too time consuming. If it runs only on desktops then Java is actually OK. There are only about 2 x performance difference in average (with good specialists on both sides) and that is liveable. |
| David Brown <david.brown@hesbynett.no>: Feb 12 03:44PM +0100 On 12/02/15 15:25, Luca Risolia wrote: > share the code of their core components between Android and IOS. The > reason and the advantages are obvious, as only C++ is supported on > *both* the platforms, while neither Objective-C nor Java are. One thing to note here is that Dropbox used C++ for the non-UI parts - I think they used "native" languages (Java on Android, Objective C on iOS) for the UI parts. As long as you stick to C++ standards, modern compilers, avoid compiler-specific extensions (unless you can be sure of the compiler - clang and gcc share most extensions), and avoid platform or target specific assumptions (such as the size of "long", endianness, etc.), then writing portable C++ is not hard. /You/ have control of the compilers used (or at least the minimal requirements for them). With Java, different implementations or versions of the runtimes can make a difference that you cannot easily control. (The same applies with C#/dotnot/Mono.) If you need cross-platform UI's or integration with the OS, then it is best to use a cross-platform toolkit such as Qt or wxWidgits to separate the tasks. |
| Cholo Lennon <chololennon@hotmail.com>: Feb 12 11:46AM -0300 On 02/12/2015 11:27 AM, Öö Tiib wrote: >> compilers! > Sure, if your coders use some weird, compiler-specific or platform-specific > constructs. OMG, why are supposing that? What kind of software you write? If you need to write software for different platforms you need to write specific construct! (I said in my original post that we have a base agnostic library, but the maintenance is not easy, because we support different platforms and compilers...) > The listed things run portable code from scratch both C++ > and Java. However "telecom"? That sounds like all that mobile crap. Mobile crap? We code all kind of services for telecom carriers mostly in C++, we don't code mobile apps! (Our applications implement signaling gateways, sms routers, IVRs, call/sms tapping, SIM authentication, black lists, USSD applications, etc, etc). -- Cholo Lennon Bs.As. ARG |
| Cholo Lennon <chololennon@hotmail.com>: Feb 12 11:49AM -0300 On 02/12/2015 11:02 AM, Luca Risolia wrote: >> compilers! > Hard to believe. Most of the time that's because of you writing non > portable code I told you, we have a base library that is portable across different platforms, so I write portable code, but is not easy to maintain that library and it's not easy to write and maintain portable code (just look boost code) > Don't forget that C++ is designed around the concept of abstract machine, > which actually includes *a lot of* concrete platforms, more than the > number of platforms on which Java can be supported. I don't know you but I live in a real world where implementation matters not the theory around a programming language. A real world where compilers aren't fully compliant and where platforms have differences that you need to sort in a transparent way for other programmers. Last but not least: when you have millions of lines of code and several applications in production running in different carriers across several countries with different OSs (and versions) is not easy to migrate a compiler. Regards -- Cholo Lennon Bs.As. ARG |
| scott@slp53.sl.home (Scott Lurndal): Feb 12 03:00PM >> Although card readers never were supported on Solaris :-) >You people mean punch-cards? These were funny. Are smart-card >readers supported? Punched cards. From which the 80 columns on a terminal screen were derived. From which modern patch programs were derived. The reason that COBOL and ForTran have sequence number fields in the source format (relaxed in modern versions). |
| drew@furrfu.invalid (Drew Lawson): Feb 12 03:39PM In article <mbgk8g$23o$1@dont-email.me> >Human speech patterns. >If I argue against a premise and you argue against that, then one would >naturally think you are for the premise.... You seem confused as to what this sub-thread is discussing. I don't give a fuck what OS you use. You asserted that no one would walk away from a Windows-sized market. Clearly Microsoft had no problem walking away from a large chunk of that. >developers whom had needs of technology that doesn't run on it, would >also. Unless you assume MS would magically make .NET 4.5 and DX11+ work >on it, which would be a feat. Gods save me from any system that needs .NET. >Instead, the government wastes trillions in tax dollars, because they >don't want to follow the 10 year rule. I've worked DOD, seen it first >hand. The waste was atrocious and criminal. Again, I was not addressing what *should* be (on which we would probably disagree), simply responding to your flawed assertion that no one would walk away from such a revenue stream. And this "10 year rule" must be something from the Windows world. Most of my career has been spent on systems that are over 15 years old. -- Drew Lawson | What you own is your own kingdom | What you do is your own glory | What you love is your own power | What you live is your own story |
| woodbrian77@gmail.com: Feb 12 07:51AM -0800 On Thursday, February 12, 2015 at 9:39:33 AM UTC-6, Drew Lawson wrote: > >If I argue against a premise and you argue against that, then one would > >naturally think you are for the premise.... > You seem confused as to what this sub-thread is discussing. [snip] Please don't swear here. Brian Ebenezer Enterprises http://webEbenezer.net |
| Luca Risolia <luca.risolia@linux-projects.org>: Feb 12 05:20PM +0100 On 12/02/2015 15:49, Cholo Lennon wrote: > not the theory around a programming language. A real world where > compilers aren't fully compliant and where platforms have differences > that you need to sort in a transparent way for other programmers. This is an argument that does not hold. Can you give some examples of such "transparent ways"? |
| Christopher Pisz <nospam@notanaddress.com>: Feb 12 11:46AM -0600 On 2/12/2015 9:39 AM, Drew Lawson wrote: >> unless these posters just >> like to argue pointlessly for lack of anything better to do, which is my >> conclusion. Ok, please let's all stop any discussion we had going on and concentrate on Drew's distaste for Microsoft dropping support for XP. Sorry, Drew, I cannot defend Microsoft for you, beyond telling you that it is a 14 year old version of software that they deemed necessary to end of life. Call them and tell them how upset you are I suppose. |
| Ian Collins <ian-news@hotmail.com>: Feb 13 08:21AM +1300 Cholo Lennon wrote: > in C++) are being re-written in Java to avoid maintenance issues: add > new core features in several platforms or modify code and recompile the > entire base is very, very time-consuming :-( Are you still using 80s compilers? Most of the C++ applications I write compile with Solaris Studio (Solaris/Illumos targets) and gcc (Linux Intel/ARM). Some are also targeted at windows (VS or gcc). I've been developing C++ applications for Solaris, Linux and Windows on Solaris since the 90s. I've never encountered a "portability nightmare". Mind you, I have always run continuous builds on all intended platforms during development. -- Ian Collins |
| Christopher Pisz <nospam@notanaddress.com>: Feb 12 01:49PM -0600 On 2/12/2015 1:21 PM, Ian Collins wrote: > for Solaris, Linux and Windows on Solaris since the 90s. I've never > encountered a "portability nightmare". Mind you, I have always run > continuous builds on all intended platforms during development. I've never seen a truly portable application, entirely in C++, in my life. I think it a fantasy, but I live in a Windows bubble. It's not about the 'language' being portable, it's about there being no portable framework that comes with the language for gui, networking, database connections, etc. In response to this people always say, well go get the xyz open source project, but those aren't truly portable either, they always have a bunch of #if preprocessor directives to do OS specific things and load OS specific libraries. The only truly portable application I could see being done entirely in C++ would be something that loaded data from file, manipulated it, and saved it to file, from the command line. |
| Ian Collins <ian-news@hotmail.com>: Feb 13 08:59AM +1300 Christopher Pisz wrote: > It's not about the 'language' being portable, it's about there being no > portable framework that comes with the language for gui, networking, > database connections, etc. Nothing I write these days has a native GUI, if one is required it will be web based. Networking is pretty much universal, modulo a few minor winsock foibles. For database interfacing I've used the native libraries provided for the database. The first non-trivial windows application I wrote was developed on Solaris/SPARC, mainly because that was or main development platform. It was a network based video distribution application (all rather new in the mid 90s!). The biggest portability problem was the legendary awfulness of VC6... -- Ian Collins |
| Christopher Pisz <nospam@notanaddress.com>: Feb 12 02:26PM -0600 On 2/12/2015 1:59 PM, Ian Collins wrote: >> database connections, etc. > Nothing I write these days has a native GUI, if one is required it will > be web based. But you have to get information from the web to your application. Something somewhere is communicating. > Networking is pretty much universal, modulo a few minor > winsock foibles. Well, even the fact that you'd have to link with Winsock or ...I dunno what others use...posix sockets?...boost?.. requires a bunch of compiler options, make files, msbuild, ant, or something. > was a network based video distribution application (all rather new in > the mid 90s!). The biggest portability problem was the legendary > awfulness of VC6... Oh, VC6 will always have a special place in my heart. So, much fun figuring out issues written with that P.O.S.! |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 12 02:36PM -0600 Christopher Pisz <nospam@notanaddress.com> wrote in news:mbj298$te0$1@dont- email.me: > Well, even the fact that you'd have to link with Winsock or ...I dunno > what others use...posix sockets?...boost?.. requires a bunch of compiler > options, make files, msbuild, ant, or something. Boost.asio is pretty good. Same with other portability issues, more often than not Boost has already covered them and isolated the uglyness under the carpet. So, with or without Boost, C++ is portable in a large extent to many platforms. Java programs are portable for one platform only, but the platform itself is reasonably portable. Go figure. p. |
| Cholo Lennon <chololennon@hotmail.com>: Feb 12 05:52PM -0300 On 02/12/2015 04:21 PM, Ian Collins wrote: >> new core features in several platforms or modify code and recompile the >> entire base is very, very time-consuming :-( > Are you still using 80s compilers? No... my guidelines are: VC++ 2003/2005/2012, gcc 3.4.1/4.1.2/4.6. My code has to compile well with all of them (Luckily VC++ 2003 is almost dead in our production base). I love C++ but I can tell you, is not as easy as lots of people love to say. -- Cholo Lennon Bs.As. ARG |
| Cholo Lennon <chololennon@hotmail.com>: Feb 12 05:58PM -0300 On 02/12/2015 04:49 PM, Christopher Pisz wrote: >> continuous builds on all intended platforms during development. > I've never seen a truly portable application, entirely in C++, in my > life. I think it a fantasy, but I live in a Windows bubble. I completely agree with you (and, in my case, I develop for several platforms) -- Cholo Lennon Bs.As. ARG |
| DSF <notavalid@address.here>: Feb 12 03:11PM -0500 On Tue, 10 Feb 2015 10:11:41 +0100, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote: {big snip} >Maybe you set some string class instance to blank, retrieved its address >as C compatible char* and then used this as strcpy target. Bad idea! >I'm just guessing, of course. THANK YOU!!!! Two parts of your paragraph were trigger phrases that lead me right to the problem. "blank" and "strcpy target". Back in October, Alf P. Steinbach showed me how to avoid having to create a string array with new with code that expects a pointer to a string it can use, such as your strcpy above. Instead of: FString output; size_t outputsize; outputsize = SPrintf(NULL, "%s: %d\n", someotherstring, somenumber); char tempstr = new[outputsize+1] SPrintf(tempstr, "%s: %d\n", someotherstring, somenumber); output = tempstr; delete[] tempstr; By using: size_t outputsize; outputsize = SPrintf(NULL, "%s: %d\n", someotherstring, somenumber); FString output(outputsize+1); // estab buffer size of output SPrintf(&output[0], "%s: %d\n", someotherstring, somenumber); Note SPrintf is not a typo. I wrote my own printf code to handle normal and wide characters. Thought I'd increase safety by having SPrintf return the number of characters (not bytes) if the target is NULL. (I'm assuming 8-bit characters in the above example.) The Actual Memory Problem: I have been converting code in various functions that creates a large C string at the start of the function, adds data, and finally outputs the string at the end to use FString instead. I had this: LPTSTR output; output = new TCHAR[8192]; ... SPrintf(output, (LPCTSTR)hlstring, hlid, hlg.hlnumber, hlsz); ...etc. When I changed output to a FString object, I did this: FString output; ... SPrintf(&output[0], (LPCTSTR)hlstring, hlid, hlg.hlnumber, hlsz); ...etc. See the error? I forgot to give FString an initial buffer value. And to cut down on overhead of default initializing FString members of other classes, "FString output;" sets the string pointer member to point to a static const unsigned int literally called "blank". It became: const FStringSt hlstring(TEXT("Hard Link ID: %s. Hard Links in \ group: %4d. Hard link size: %s.\n")); FString output; ... size_t opwidth; opwidth = SPrintf(NULL, (LPCTSTR)hlstring, hlid, hlg.hlnumber, hlsz); output.IncreaseBufferLength(++opwidth); SPrintf(&output[0], (LPCTSTR)hlstring, hlid, hlg.hlnumber, hlsz); ...etc. >many problems. >I did not take care of wchar_t in my post. Everything which applies to >char applies to wchar_t as well. I'll do you one better. I have a string template named FStringSt (A & W) [I used to love their root beer! :o) ] to encapsulate with static char arrays. >Marcel DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| 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