- My post titled "About C and C++" - 1 Update
- Why all tutorials/books use non-unicode string? - 13 Updates
- About C and C++... - 2 Updates
- My post titled "Software life cycle" - 1 Update
- Software life cycle - 1 Update
- What is the best encoding (experiences...) for unicode? - 3 Updates
- About software quality and programming - 4 Updates
| Ramine <ramine@1.1>: Feb 24 05:17PM -0800 Hello, My post titled "About C and C++" was my last post here in this newsgroup. Thank you, Amine Moulay Ramdane. |
| Christopher Pisz <nospam@notanaddress.com>: Feb 23 06:03PM -0600 On 2/23/2015 2:38 PM, Chris Vine wrote: > You choose C++ for a program because it fits the problem domain > (primarily, efficiency). If the program happens to have a GUI > interface, it is of secondary importance. Exactly. > C++ is a significant impediment to a return on investment, it is > probably not a program where C++ is the correct solution to begin > with. Complex or simple, it doesn't matter. There are other technologies far more suited for GUI then using another framework in C++. > So you are writing a piece of consumer krapware which you chuck > out as fast as you can? Where does your krapware qualifier come from? If you are going to label anything made with .NET and XAML as krapware, then at least provide the factors that make it fall into such a category. Rapid development is not the only factor. Size, maintainability, extendability all compare better. But none the less, put 50 managers in a room and ask them to vote on what the number one thing is that is they are looking for. Development time is not usually the most important thing to me personally, but it certainly is, and a lot of the time wrongfully so, to almost every employer. |
| JiiPee <no@notvalid.com>: Feb 24 07:20AM On 24/02/2015 00:03, Christopher Pisz wrote: > factors that make it fall into such a category. > Rapid development is not the only factor. Size, maintainability, > extendability all compare better. But none the I think this is true. > Development time is not usually the most important thing to me > personally, but it certainly is, and a lot of the time wrongfully so, > to almost every employer. I asked once my manager, back in 2000, that is it better to make good quality code and use a lot of time for it or make the code fast so that its just working and we get the product quickly out. His response was more like "make it fast". Well, not sure if this small company was the most professional but thats what they pushed a lot: making things fast was priority all the time. I wanted to do things nicely and use my time, but that was not really what they wanted. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 24 12:12PM On Mon, 23 Feb 2015 18:03:46 -0600 > On 2/23/2015 2:38 PM, Chris Vine wrote: [snip] > > with. > Complex or simple, it doesn't matter. There are other technologies > far more suited for GUI then using another framework in C++. You misunderstand my point. If your program is written in C++ because that best suits what you are doing, then you choose a C++ framework for the GUI, if there is one. You don't write part of the program as native code in C++ and part on the .NET VM for the GUI (I don't even think you can do that can you?). The point I am making is that you don't decide what language to write a project in just by deciding what is the best language for the GUI, if there is a GUI, unless the program is very particularly and strongly GUI orientated. We both agree development time is a very important factor. You think in consequence that having to write a GUI in C++ is _the_ (or at least _a major_) deciding factor against using C++ in a large number of cases. I don't. Where .NET is used, it is for numerous other reasons as well. For example, for a language running on a VM where that is what you want, it is a nice piece of kit. > Where does your krapware qualifier come from? If you are going to > label anything made with .NET and XAML as krapware, then at least > provide the factors that make it fall into such a category. Straw man, given that I didn't "label anything made by .NET and XAML as krapware", as should be completely obvious from my following words in parenthesis. (Nor for that matter did I label what you were doing as krapware, if that is what your rearrangement of the text was intended to suggest. The "you" is a generic one. I have no idea what you are doing.) Chris |
| Christopher Pisz <nospam@notanaddress.com>: Feb 24 10:22AM -0600 On 2/24/2015 6:12 AM, Chris Vine wrote: > don't decide what language to write a project in just by deciding what > is the best language for the GUI, if there is a GUI, unless the program > is very particularly and strongly GUI orientated. Perhaps this is where your differing point of view is coming from. If you are under the impression that you have to write the entire suite in C# because you chose to do the GUI in C#, then I could see your distaste. However, that is not the case. Yes, a C# GUI can communicate to C++ and that is exactly what I am suggesting. This could be a local application or on the web. There is some downside though in a few scenarios. Often you have to duplicate some part of the domain on both sides. There are frameworks that can eliminate that through generated code. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 24 06:23PM On 24/02/2015 16:22, Christopher Pisz wrote: > application or on the web. There is some downside though in a few > scenarios. Often you have to duplicate some part of the domain on both > sides. There are frameworks that can eliminate that through generated code. The only sane way to interface C++ with C# is to use C++/CLI middle ware; I have done this and it is a fucking nightmare to maintain; not worth the effort just so you can use the krapware which is XAML (which is a nightmare to debug). C# is for lazy cunts who cannot survive without a garbage collector. Sausages. /Flibble |
| Christopher Pisz <nospam@notanaddress.com>: Feb 24 01:58PM -0600 On 2/24/2015 12:23 PM, Mr Flibble wrote: > C# is for lazy cunts who cannot survive without a garbage collector. > Sausages. > /Flibble As usual, you don't know what you are talking about and are just trolling. Soap, REST, COM, your own RPC, sockets, and a myriad of other options exist to communicate between _native_ C++ and C#. Debug XAML? That's like debugging HTML rather than the javascript it contains, it makes no sense. Maybe you mean debugging your bindings. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 24 08:04PM On 24/02/2015 19:58, Christopher Pisz wrote: > As usual, you don't know what you are talking about and are just > trolling. Soap, REST, COM, your own RPC, sockets, and a myriad of other > options exist to communicate between _native_ C++ and C#. What? Use sockets to communicate between different parts of the same process? You've fallen out of your tree mate. > Debug XAML? That's like debugging HTML rather than the javascript it > contains, it makes no sense. Maybe you mean debugging your bindings. Obviously I mean debugging the bindings you idiot and XAML can contain errors. /Flibble |
| Daniel <danielaparker@gmail.com>: Feb 24 12:13PM -0800 On Tuesday, February 24, 2015 at 1:23:53 PM UTC-5, Mr Flibble wrote: > C# is for lazy cunts who cannot survive without a garbage collector. The sausage is big, but its skin is even bigger. Daniel |
| Christopher Pisz <nospam@notanaddress.com>: Feb 24 02:21PM -0600 On 2/24/2015 2:04 PM, Mr Flibble wrote: > Obviously I mean debugging the bindings you idiot and XAML can contain > errors. > /Flibble You're lost. Or more likely not, you're just adding conditions to continue trolling. No one ever said anything about same process. Quite often in the real world the UI is not in the same process and if it is, there is nothing stopping anyone from separating it out. In fact, it is better separated out for reasons you can Google yourself. If you excelled at reading comprehension then you would have read the earlier bits about the possibility of web client, etc. I am sure you'll just continue on all day, so I'm gonna go ahead and flip the filter on now. I responded for the sake of the OP, not to argue for the next 10 hours with you yet again. It's a pointless waste of time. You contribute nothing. -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 24 08:29PM On 24/02/2015 20:21, Christopher Pisz wrote: >> /Flibble > You're lost. Or more likely not, you're just adding conditions to > continue trolling. No one ever said anything about same process. I was talking about communicating between the C++ model of an application and the GUI which renders that model in the same process; to do that with a C# GUI requires C++/CLI. If you are talking about ordinary IPC between processes then you are not really talking about interfacing between different languages. If your application is C++ and you want a GUI in the same process then you would be a nutter if you didn't use a C++ GUI framework such as Qt. > it is better separated out for reasons you can Google yourself. If you > excelled at reading comprehension then you would have read the earlier > bits about the possibility of web client, etc. Real world? Tell me something I don't know mate: my last three projects at work were designed with a GUI in a separate process; I wasn't talking about IPC between different processes and I believe neither was Chris Vine. > flip the filter on now. I responded for the sake of the OP, not to argue > for the next 10 hours with you yet again. It's a pointless waste of > time. You contribute nothing. You are projecting mate. Sausages. /Flibble |
| legalize+jeeves@mail.xmission.com (Richard): Feb 24 08:56PM [Please do not mail me a copy of your followup] no@notvalid.com spake the secret code >quality code and use a lot of time for it or make the code fast so that >its just working and we get the product quickly out. His response was >more like "make it fast". The choice as you've described it is a false one. It isn't a choice between fast and quality. It is a trade-off between scope, cost and schedule where "quality" usually falls into the cost category. See <https://en.wikipedia.org/wiki/Project_management_triangle> Basically, you can have any two of scope, cost and schedule: - (scope, cost) many features delivered later at high quality - (cost, schedule) few features delivered quickly at high quality - (scope, schedule) many features delivered quickly at low quality In reality, noone wants to deliver low quality software, but they are forced into doing it because they thought they could ignore the iron triangle and thought that they could deliver a large scope product in a short period of time. Often they think that simply having good engineers is enough to accomplish this, but that is hubris. I'm surprised how many managers and executives don't understand the iron triangle. It could be simply because noone from the technical team has ever bothered to explain it to them. In a worst case, you have people who have succumbed to hubris and think somehow the iron triangle doesn't apply to their company, project or team. Such organizations will constantly "fail" in their objectives because when you argue with reality, reality always wins no matter how good your argument. The best way to not be trapped by the iron triangle is to accept the reality of it and plan accordingly. Again, since noone intentionally sets out to deliver poor quality software, your choice is to balance scope and schedule. If you have a fixed scope, then allow the schedule to float. If you have a fixed schedule, then allow the scope to float. In both cases, your scope should be prioritized with the most important business value appearing first on the list of things to do. This means you work on all your "must haves" first with the "nice to haves" being worked on later. (See the Kano model of customer satisfaction <https://en.wikipedia.org/wiki/Kano_model>.) If you do this, then you'll be delivering the most important value to your business first and if you run out of time, the things that are dropped are hopefully in the "nice to have" category. Even when you operate with an assumption of a floating schedule, people get impatient and they won't wait forever for you to develop the software. Along the way you have to provide feedback to the stakeholders in your project. The best way is to give periodic demonstrations of the software showing the progress that's been made since the last demo. This is closing the feedback loop between the development team and the business team. -- "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> |
| Geoff <geoff@invalid.invalid>: Feb 24 01:05PM -0800 On Tue, 24 Feb 2015 20:56:45 +0000 (UTC), >software showing the progress that's been made since the last demo. >This is closing the feedback loop between the development team and the >business team. The Magic Triangle. Cheap, fast, correct. Pick any two. Great post. -2 points for spelling "no one" wrong. |
| JiiPee <no@notvalid.com>: Feb 24 10:14PM On 24/02/2015 20:56, Richard wrote: >> more like "make it fast". > The choice as you've described it is a false one. It isn't a choice > between fast and quality. But surely quality and time are correlated, right? At least in chess we know that the more time you give Master to analyze a position, the better moves they make (it can be proven by statistical figures... for example a human playing like this gets very good results against a computer, but a human playing faster game against a computer gets worse results). > dropped are hopefully in the "nice to have" category. Even when you > operate with an assumption of a floating schedule, people get > impatient and they won't wait forever for you to develop the software. surely a good strategy |
| Ramine <ramine@1.1>: Feb 24 04:59PM -0800 Hello, I have saw some programmers talking about C on the C's forums... But as you have seen me talking before on my post titled "Software life cycle" , you have noticed that i have talked about the criterions that is "Maintainability" and "modifiability", what i don't like in C is that if you want to group efficiently functions and some propoerties that are shared inside an object , you can not do that efficiently as can do Object Pascal or C++, if you are writing in C you have to use global variables, but that's not good for "maintenance" and "clarity" of the code, in C++ or Object pascal you will not use global variables but you will use an object that enhance the clarity and maintainability... this is why i don't like C, other than that since Java is garbage collected it enhance the "Reliability" and "Security" criterions, ADA also is good at Reliability and security, i think C and C++ score less on those criterions that are reliability and security than Java or ADA. Thank you, Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Feb 24 05:13PM -0800 Hello, Even if you can use structs to group functions and there shared variables in C, that's not as efficient as C++ or Object Pascal, in C++ or Object Pascal you can use public and private... properties and that's efficient and you can use also generics and lambda expressions to write less code and to easy maintenance... C is becoming an "old" thing that makes the things more complex and difficult for us programmers i think... Amine Moulay Ramdane. |
| Ramine <ramine@1.1>: Feb 24 04:09PM -0800 Hello, My post titled "Software life cycle" was my last post here in this newsgroup. Thank you, |
| Ramine <ramine@1.1>: Feb 24 04:08PM -0800 Hello.. As you have seen me talking here, i have talked in my previous post about "software quality and programming", what you have seen me saying is that we have to take into account many critera in software quality, such us: - Reliability - Efficiency - Security - Maintainability - Identifying critical programming errors - and portability - expressivness But I have forget to talk about the modifiability's criterion , because modifiability is important also, that means if you do modify a method or an object inside the software , this modification must have as a "consequence" to create a "localized" modification to the method or to the object to easy also maintenance and to improve "maintainability", so this is the criterion called modifiability that we must take into account and this is the goal that we must attain by using object oriented programming etc. Anyway, what's i want to say in this post, is that what you have seen me talking about is how to attain a good software quality by setting the goals that are to score high on those criterions above , but to score high on those criterions above is a necessary but not a sufficient condition, because in software lifecycle we must also use a methodology like agile methodology that is more optimal to be able to deliver a software with minimal "costs", "waste", and "time", thus enabling companies to be competitive and achieve gains. Thank you, Amine Moulay Ramdane,. |
| Juha Nieminen <nospam@thanks.invalid>: Feb 24 08:39AM > days to read for a person regardless if it is UTF-8 or UTF-16. If it > is meant for a computer to read and I need extreme performance then > I don't see the reason why to choose Japanese (or text I/O in general). You are only thinking about it in terms of a human reading the text. There *are* other possible situations, you know. For example, you may have a word game with a dictionary, and you might need to implement, for example, a puzzle solver algorithm which, for instance, resolves from a set of given characters all the possible words that can be formed using those characters, as fast as possible. UTF-8 would be horrible in terms of speed for this, while UTF-16 would be quite optimal. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 24 02:58AM -0600 Juha Nieminen <nospam@thanks.invalid> wrote in news:mchdbq$24pk$1 >> days to read for a person regardless if it is UTF-8 or UTF-16. If it >> is meant for a computer to read and I need extreme performance then >> I don't see the reason why to choose Japanese (or text I/O in general). > words that can be formed using those characters, as fast as possible. > UTF-8 would be horrible in terms of speed for this, while UTF-16 > would be quite optimal. I do not see any big difference between UTF-8 and UTF-16 here, both are variable-length formats. Maybe you assumed that the task is limited to Japanese and one can use UCS-2 instead of UTF-16? UCS-2 would probably be faster than UTF-8 indeed, but not sure how much because most Japanese words are quite short. It might well be that dictionary search dominates the word construction and there is actually not much difference. Cheers Paavo |
| "Öö Tiib" <ootiib@hot.ee>: Feb 24 10:01AM -0800 On Tuesday, 24 February 2015 10:39:37 UTC+2, Juha Nieminen wrote: > > I don't see the reason why to choose Japanese (or text I/O in general). > You are only thinking about it in terms of a human reading the text. > There *are* other possible situations, you know. Certainly there are tons of situations that I have not measured. > need to implement, for example, a puzzle solver algorithm which, for > instance, resolves from a set of given characters all the possible > words that can be formed using those characters, as fast as possible. In situations like that the performance bottle-necks are more likely in design of dictionary and algorithms ran on it. In those things I have seen improvements made that rose average performance 4 to 200 times. > UTF-8 would be horrible in terms of speed for this, while UTF-16 > would be quite optimal. Yes, I have yet to see differences between UTF-16 and UTF-8 that can be somehow profiled "horrible". Your own extreme case all-Japanese is only 1.5 times difference of storage. Things run typically sufficiently fast so I can rarely convince shareholders of maintenance that supposedly improves performance by less than 2 times. |
| Robert Wessel <robertwessel2@yahoo.com>: Feb 24 02:45AM -0600 >> so a killfile would probably do what is required for those who are >> prepared to remain on it. Chris >he might keep changing his email, so killfile not working I don't have many people in my killfile, most people are just a keystroke to ignore, but he's one of the lucky ones. But at least he has only occasionally changed his email address, looks like only two in the last year or so. |
| Stuart Redmann <dertopper@web.de>: Feb 24 03:44PM Chris Vine wrote: I say this because I used to follow > another programming newsgroup which he pretty well single-handedly > destroyed. I'm intrigued. Do you mind telling us, which group it happened to be? Thank you, Stuart |
| jt@toerring.de (Jens Thoms Toerring): Feb 24 04:46PM > > another programming newsgroup which he pretty well single-handedly > > destroyed. > I'm intrigued. Do you mind telling us, which group it happened to be? Have a look at e.g. comp.programming. It was no high-traffic group but a good place for discussions of topics which didn't fit into any other category. Until this guy started to post insane amounts of messages, bringing the S/N down to nearly zero. Another of his victims is comp.programming.threads. Best regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| Geoff <geoff@invalid.invalid>: Feb 24 09:43AM -0800 On Tue, 24 Feb 2015 15:44:04 +0000 (UTC), Stuart Redmann >> another programming newsgroup which he pretty well single-handedly >> destroyed. >I'm intrigued. Do you mind telling us, which group it happened to be? I don't know what group Chris Vine might be talking about but I've got him killfiled globally and he's fond of comp.programming. Sampling the headers of comp.programming for the last 30 days: Posts by Ramine: 67 Posts by others on other topics: 9 (4 by fir) Replies to Ramine: 8 Posts by Ramine usually consist of explanations of some topic of interest to him, typically "inventing" some technique that already exists but he feels he has improved upon, followed by followups to his own posts consisting of corrections, re-writes and errata to his code or fixing incomplete or erroneous implementations. What's particularly annoying about his projects is that he publishes an announcement about some version of a project, only to be followed an hour later with the announcement of an update, followed the next day by another update to the project. All perfectly pointless announcements since anyone interested in his projects would have followed the link in the first announcement and be looking _there_ for updates. |
| 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