- Support for a device (with DLL's) which is controlled by winforms(c++) - 6 Updates
- No, C is not a simple language - 4 Updates
- Text editor project in C - 3 Updates
- C++ may sometimes be *too* simple (to use) - 6 Updates
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 28 10:28AM -0700 You posted in comp.lang.c. You want comp.lang c++ -- probably. Google Groups has a rather horrid bug that quietly drops the "++" from the newsgroup name. I've cross-posted this to comp.lang.c++ and redirected follows there. If you reply to this message (and not to any others in this thread), you should be able to continue the discussion in the correct newsgroup. (I see you're using a lot of C library functions, which is valid, but perhaps not a good idea if you want to program in C++.) This syntax: MyForm^ NewUI = gcnew MyForm(); suggests that you're using some non-standard dialect. Someone in comp.lang.c++ who recognizes it might suggest a better place to post. Previous message follows (I normally wouldn't top-post, but I made an exception in this case): -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Cetin Aslantepe <cetin.aslantepe1988@gmail.com>: Apr 28 02:49PM -0700 Dear Keith, Thank you for posting in the right group . |
| Cetin Aslantepe <cetin.aslantepe1988@gmail.com>: Apr 28 03:09PM -0700 Dear Supporter, I have been trying to control a stepper motor via GUI(WinForms) with my little programming knowledge. With the example programs of device, I get commands (movements) performed. All functions are already stored under a DLL. I was told that only by applying threads two main programs (device and winforms) is possible. Are threads necessary? If yes, how should I design the program with threads best? Are there other solutions? First of all, I would like to use the GUI (WinForms) to make the first simple movements. How should I proceed? First of all, I want my GUI to communicate with the stepper motor? How would I do that? I would be very happy about a feedback. Thanks in advance. I appreciate your help. With best regards Cetin Aslantepe |
| Real Troll <real.troll@trolls.com>: Apr 28 11:10PM +0100 On 28/04/2021 18:28, Keith Thompson wrote: > Google Groups has a rather horrid bug that quietly drops the "++" from > the newsgroup name. If you post directly on to C++ link, does it work? <https://groups.google.com/g/comp.lang.c++> I would have thought that if people can find this link on google portal then it should work. Google Groups are a mess and you can't find direct links to the posting site any more. |
| Cetin Aslantepe <cetin.aslantepe1988@gmail.com>: Apr 28 03:18PM -0700 Dear Real Troll, I'm in the right group now "comp.lang.c++" The message has been posted in the right group. This is also discussed in the c group. About any help I would be grateful. best regads cetin |
| Real Troll <real.troll@trolls.com>: Apr 28 11:29PM +0100 On 28/04/2021 23:18, Cetin Aslantepe wrote: > About any help I would be grateful. Sure. I would like to help but it is beyond my pay grade. Sorry about this. I can create DLLs and all that in C and C++ but to bind the functions in the GUI environment is not something I do in C or C++. I am mainly a C# programmer where GUI is much better IMO. Also, there are many Videos about C# on YouTube dealing with Visual Aspect of the programs. |
| Christian Gollwitzer <auriocus@gmx.de>: Apr 28 08:03AM +0200 Am 26.04.21 um 21:07 schrieb wij: > Then, "my problem" is the concept of multi-paradigm and C++ standard practiced > by usual programmers contradict each other if C++ standard library dictates its > usage only a bit more. [...] I think, you simply do not like C++ and like C more - and that is OK, it is your opinion. De gustibus non est disputandum. Most people in this group simply have another opinion. Christian |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 28 12:02AM -0700 On 4/17/2021 10:12 AM, Manfred wrote: > As second, I agree with Jacob that a text editor is a simple tool, but > it is not easy to make expecially for a beginner. > [snip] Wrt using GC as the everlasting crutch: https://youtu.be/ao-Sahfy7Hg |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 28 12:32AM -0700 On 4/23/2021 4:10 AM, wij wrote: >> Technically sound, I am convinced now... >> ... that you have nothing to say > Let it burn. I like to play fire, safely. ;^) The dragon in the clip I posted is pretty damn pissed off! ;^) |
| wij <wyniijj@gmail.com>: Apr 28 11:04AM -0700 On Wednesday, 28 April 2021 at 15:33:05 UTC+8, Chris M. Thomasson wrote: > > Let it burn. I like to play fire, safely. > ;^) > The dragon in the clip I posted is pretty damn pissed off! ;^) Yop, that's what the director want audience to see. This song (lyrics, at least) is from Book of Songs (very old) https://www.youtube.com/watch?v=9QVTcv6geHQ "Book of Songs"==Classic_of Poetry==Lyrics https://en.wikipedia.org/wiki/Classic_of_Poetry |
| David Brown <david.brown@hesbynett.no>: Apr 28 09:01AM +0200 On 27/04/2021 18:31, jacobnavia wrote: > https://www.tiobe.com/tiobe-index/ > SOME companies must be using it, don't you think so? > C++ comes 4th. The TIOBE index is well-known for being no more than a vague indication of the popularity of a language - it is certainly not the ranking some people would believe. But let us assume that C is significantly more used than C++ - it is not an unreasonable assumption, regardless of TIOBE. The question asked was "what companies want to reduce C++ by using more C?" It was not "what companies use C?". In my experience, companies and developers sometimes move from C to C++. They rarely move back. But if you know differently, tell us. |
| Manfred <noname@add.invalid>: Apr 28 02:54PM +0200 On 4/28/2021 9:01 AM, David Brown wrote: > C?" It was not "what companies use C?". > In my experience, companies and developers sometimes move from C to C++. > They rarely move back. But if you know differently, tell us. Agreed that the TIOBE index should be taken with a grain of salt (possibly even with a few pounds of it) However, the /trend/ shows that C is raising as of recent, unlike C++ - while in the long run C++ shows a more significant decrease, vs C being pretty much stable. If this were a /usage/ index it would tell something about your point - the fact still is that TIOBE is a popularity index, it measures how much people /talk/ about some programming language, which is hardly coupled with any actual professional usage, IMHO (I'm no expert in marketing/social research). |
| "Öö Tiib" <ootiib@hot.ee>: Apr 28 09:57AM -0700 > > wants to migrate/translate/switch from C++ product/code base to any of those > > now and why as I know outright totally none cases. > Who? Who can say that specifically except themselves? I specifically asked for quote or cite of concrete "themselves" as technology companies say such kind of things (like their trend in choice of technology stacks) about themselves quite often. If it is something noteworthy like moving to C or Fortran then I expect similar amount of noise like people do who about themselves (and their kids) being vegetarians. It is because everybody want talk about themselves and to find and to cooperate with others who share their attitude. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 27 06:14PM -0700 On Tuesday, 27 April 2021 at 17:57:17 UTC+3, Paavo Helde wrote: > makes e.g. a million of such comparisons, then with large substrings it > would slow down from 0.004 s to 0.04 s. I bet many people won't be > overly concerned about this. The focus has long gone away from considering each time we solve some problem if the result is most efficient. On most cases it matters if it works correctly for all input and if it is easy to understand what is going on. Efficiency matters only for about 5% of code base. For example if we need to sort very small array of fixed size then on 95% of cases it is not worth to dig out some code that implements one of such mathematically proven optimal from Donald Knuth's "The Art of Computer Programming" volume 3 (written in sixties) but to use std::sort. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 27 07:57PM -0700 On 4/27/2021 5:07 AM, Juha Nieminen wrote: > complicated to write or use, or would require several lines of code, > or something. > ... In modern C++ the original comparison is better done through a `std::string_view` if (std::string_view(str1).substr(n, 5) == str2) This is also an in-place comparison with zero actual run-time overhead, even though conceptually it looks like a creation of an extra [lightweight] temporary. Tri-state comparisons like `std::string::compare` have their own important role (which is why we now have built-in tri-state comparisons through `<=>`), but the version you are proposing doesn't exactly look too elegant when invoked for the purpose of a plain equality comparison. Might be one of the reasons people would consciously avoid it in favor of the original `.substr` version, despite the considerable extra run-time cost. Before the `std::string_view` era I would also opt to use `std::string::compare` in this context for the same reasons you mentioned. But, again, some people might stick to an expensive `.substr` version in non-critical code just for its stylistic elegance. -- Best regards, Andrey Tarasevich |
| wij <wyniijj@gmail.com>: Apr 27 09:15PM -0700 On Tuesday, 27 April 2021 at 20:07:40 UTC+8, Juha Nieminen wrote: > For example, I am currently dealing with C++ code that does a lot of > things like: > if(str1.substr(n, 5) == str2) With my library, it would be: if(str1.cseg(n,5)==str2.cseg()) With QString, there may be more examples. In not few cases, using some kind of XX::vect<char> is efficient. > std::string is an awesome tool that makes one's life a thousand times > easier, but any competent C++ programmer should learn how to use it > *efficiently*, not just lazily. Know your tools. Use them efficiently. There are lot examples using C-string is more efficient and convenient than wrapped in std::string, sort of OO twisted. The basic tool is still C. Yes, Know your tools. Use them efficiently. |
| Juha Nieminen <nospam@thanks.invalid>: Apr 28 05:21AM > problem if the result is most efficient. On most cases it matters > if it works correctly for all input and if it is easy to understand what is > going on. Efficiency matters only for about 5% of code base. I don't see a problem in choosing the more efficient solution, especially if both solutions are approximately of the same complexity. The problem with thinking like "this is just like a millisecond slower, it doesn't really matter" is that when an entire huge program is full of such compromises, they stack up, and may add up to a significant slowdown. Multiply that millisecond by a thousand instances of doing the same thing, and suddenly your program takes a second to do something that it could be doing in a hundreth of a second. It will start feeling sluggish instead of responding immediately. It may be slow to react to things. If the program is being constantly run, doing that same thing over and over, suddenly it might take a minute to do something that it could be doing in one second. Then you wonder why programs seem to be getting slower and slower, even though hardware is getting faster and faster. It's exactly because of this kind of attitude by programmers. It's precisely because of the "efficiency only matters only for about 5% of code base". Because of the "it's just like a millisecond slower, it doesn't matter." |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 28 11:13AM +0300 28.04.2021 07:15 wij kirjutas: > There are lot examples using C-string is more efficient and convenient > than wrapped in std::string, sort of OO twisted. > The basic tool is still C. Yes, Know your tools. Use them efficiently. There are lot of examples when they are equally efficient and equally (in-)convenient, like here with strcmp() and std::string::compare(). And there are lot of examples where using C strings is less efficient (constantly recalculating the string length as it is not stored anywhere) and/or less convenient. So indeed, know your tools and use them efficiently. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 28 09:09AM -0700 On Wednesday, 28 April 2021 at 08:21:47 UTC+3, Juha Nieminen wrote: > > going on. Efficiency matters only for about 5% of code base. > I don't see a problem in choosing the more efficient solution, especially > if both solutions are approximately of the same complexity. I don't see any problem either way as both seemed as error prone and used same magic number 5 ... I only thought wtf is that 5. > Multiply that millisecond by a thousand instances of doing the same thing, > and suddenly your program takes a second to do something that it could > be doing in a hundreth of a second. Nope. Paavo said that the difference was 4 nanoseconds. Multiplying 4 nanoseconds with thousand results with 4 microseconds. You need to multiply with 250 000 to first reach that millisecond. There are only rare entity types in programs whose counts ever reach such numbers and even with those you won only that millisecond. > program is being constantly run, doing that same thing over and over, > suddenly it might take a minute to do something that it could be doing > in one second. Have you ever used profiler on some large product? It is not running all its code base over and over ever. Most code is ran next to never and so must be left exactly as inefficient as it was written. Changing it can just cause more defects in rarely verified places and so waste time into doing something meaningless and money into funding something counterproductive. Meanwhile lot (perhaps majority) of programs can be made orders of magnitude faster overall by concentrating the effort of choosing optimal algorithms to those few places where it matters because these places are ran over and over. > this kind of attitude by programmers. It's precisely because of the > "efficiency only matters only for about 5% of code base". Because of the > "it's just like a millisecond slower, it doesn't matter." Nonsense, I don't wonder, I have decades of evidence that the attitude is correct, and considering optimal when focus should be to robustness and correctness is worthless and counterproductive. The projects do not lag behind, get nowhere or fail exactly because of not tinkering over things that will never matter. And so there will be time to profile it and to optimize. |
| 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