- Text editor project in C - 10 Updates
- ptcl speed test - 2 Updates
- No, C is not a simple language - 1 Update
| Bart <bc@freeuk.com>: Apr 24 01:20AM +0100 On 23/04/2021 22:13, Chris M. Thomasson wrote: > I know exactly what you are talking about. However, please clean up > after yourself? Pretty please? UNIX is not the only system out there. > This is a bad habit to get into. Clean up, gosh darn it. Which OSes don't free the resources of an application that's just terminated? What happens if the app crashes before it manages to free them? What about resources such as screen window handles, bitmaps, dynamic libraries,.... ? How about the memory that that the process itself takes up for its own code, or its stack; how is an application supposed to free that? Isn't this exacly what an OS is supposed to do? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 23 05:43PM -0700 On 4/23/2021 5:20 PM, Bart wrote: >> This is a bad habit to get into. Clean up, gosh darn it. > Which OSes don't free the resources of an application that's just > terminated? I cannot remember if named win3d mutex/semaphore/event/ect are automatically cleaned up... I think there could be an issue with SYSV shared memory. Iirc, some device drivers. I need to do more research. However, cleaning up after yourself is a good habit to get into. Afaict, the OS cleans up to help prevent badly written code from bringing the system down? A nit pick, but I can also think of leaking disk space wrt a program creating a temporary file with a random name or something, then forgetting to delete it. The OS is not going to automatically delete the file. Forgetting to unlock a robust mutex can be interesting, think of locking it as acquiring a resource, and unlocking as releasing it. It can cause a robust mutex to go into an abandoned state. Try to avoid that as much as possible. WAIT_ABANDONED or EOWNERDEAD should be minimized. > How about the memory that that the process itself takes up for its own > code, or its stack; how is an application supposed to free that? > Isn't this exacly what an OS is supposed to do? Depends on the system your are using. Well, its better to clean up after yourself. |
| wij <wyniijj@gmail.com>: Apr 23 09:43PM -0700 > > warnings under gcc in 2021 > "1700 lines", and "terse, tight, efficient, and largely uncommented" is > all the context you really needed to establish. I like the style you did. But too formal in "Conversation". When looking back, many of my replies are somewhat indirect. But I would like to keep this way for a moment. Almost all UTM programs (executables) can be analyzed or viewed as a decision graph (note that physical objects and more abstract things are similar). What the so called high level language does are actually about decision and grouping of those left non-decision parts. The desired, net result is to reduce or hide those 'unusual low level' decision makings and non-decision parts from programmers (or theorists). The real implements of these two parts depend on problem domain. As to the issue that C++ codes are simpler and easier. In basics I agree, but probably not much different from other popular high level languages in application, except the method. Approaching the more general problem from the real world of software engineer market, while people saying C++ is the choice for high performance language, such as gaming, banking, AI, VR,..., I saw the need for C++ engineer shrinks very fast these years. Most companies are trying to reduce cost by shrinking existing C++ codes to minimal. Fortran, Cobol are still active and high paid for 'high performance' need. To be more on topic, to say C++ is better over C, support from hardware is a must. |
| Ian Collins <ian-news@hotmail.com>: Apr 24 05:05PM +1200 On 24/04/2021 16:43, wij wrote: > banking, AI, VR,..., I saw the need for C++ engineer shrinks very fast these years. > Most companies are trying to reduce cost by shrinking existing C++ codes to minimal. > Fortran, Cobol are still active and high paid for 'high performance' need. We have the opposite problem, our ever expanding core product is C++ with no viable alternatives. With our borders basically shut, we are also finding it hard to get staff... > To be more on topic, to say C++ is better over C, support from hardware is a must. They are pretty much equal except at the extreme low end, that is targets not supported by gcc. -- Ian. |
| wij <wyniijj@gmail.com>: Apr 24 12:50AM -0700 On Saturday, 24 April 2021 at 13:06:00 UTC+8, Ian Collins wrote: > We have the opposite problem, our ever expanding core product is C++ > with no viable alternatives. With our borders basically shut, we are > also finding it hard to get staff... Make me think of QT,..., How it survive is interesting. I understand why most of companies in my country abandon C++, because investment on hardware is cheaper and efficient than on software. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Apr 24 08:50AM -0700 > Make me think of QT,..., How it survive is interesting. > I understand why most of companies in my country abandon C++, because investment > on hardware is cheaper and efficient than on software. In my field, capital markets, in the places I worked, C and C++ were dominant in the mid to early nineties, in all of IT data processing, middleware and messaging vendors, internal trading systems, and vendor trading systems. That started to change in the late nineties with the advent of Java. It happened first in IT, where Java quickly replaced C and C++ for internal data processing. Then the middleware and messaging vendors such as IBM and TIBCO dropped their legacy C products and replaced them with new products written in Java. This happened simultaneously with the requirement to support XML and related technologies, networking, multi-threading and Unicode, all of which were well supported in Java, and less so in C++. Then vendor derivative trading systems written in Java such as Calypso began to replace the older systems written in C++ such as Infinity. C++ survived in quant groups and vetting groups into the 2000's, but began to feel competition from C# into the late 2000's. Then, new vendors risk systems that involved many millions of portfolio valuations appeared in C#, replacing a previous generation written in C and C++. There were of course a lot of reasons for that, as I'm sure everybody knows. Some of it had to do with working with data, third party C++ library API's were abysmal for working with XML and other data forms, still are, and that won't change until C++ has meta programming, which likely won't be until 2026. It was vastly easier for vendors to distribute user extendable software in Java or C# than in C++. C++ lacked and still does basic types such as big decimal and date. Java and C# were more productive to work in than C++. Massively parallel execution could substitute to some extent for fast execution in a single process. There were many reasons. There were some gains for C++ in the last decade, particularly in high frequency trading, where performance is paramount. But it became niche. Daniel |
| scott@slp53.sl.home (Scott Lurndal): Apr 24 04:33PM >The problems I had with non-paged memory was back when I was creating >server software back in WinNT 4.0. Every IOCP operation that's inflight >would use non-paged memory. So, using too much would foobar the system. Cutler "borrowed" most of the NT I/O and Memory subsystems from VMS (the VAX operating system). Which had the same issues with the non-paged pool. |
| wij <wyniijj@gmail.com>: Apr 24 10:41AM -0700 > There were some gains for C++ in the last decade, particularly in high frequency > trading, where performance is paramount. But it became niche. > Daniel Why bother (from the view point of a company)? Just wait for another couple years, every thing will automatically be faster and cheaper, while programmer is a very unpredictable factor, and might demand more pay. I used to think neural network is a dead end, but after BP algorithm is found every changes and changed fast. I just hope the same thing happen to C++. |
| wij <wyniijj@gmail.com>: Apr 24 10:55AM -0700 On Friday, 23 April 2021 at 00:58:41 UTC+8, jacobnavia wrote: > } > linp = lp; > } I just looked into the code deeper, quite tricky and old fassion. No good for beginners, except several recurrsive method. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 24 02:21PM -0700 >> Attached is the source code for the 10th edition of Unix of the "ed" >> text editor, published by Brian Kernighan for his CS classes at >> Princeton in 2001. [1596 lines deleted] > I just looked into the code deeper, quite tricky and old fassion. > No good for beginners, except several recurrsive method. Again, *please* don't quote the entire article when you post a followup. Just quote enough so that readers can understand the context. Nobody reading your followup wants to read that entire block of text -- so don't include it in your post. -- 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 */ |
| asha.resendez@f10.n1.z35222.fidonet.org (asha resendez): Apr 24 03:31AM +1200 I completely agree with this, nothing is real on social media and on the internet. And IrCOm totally against this online dating thing because there are thousands of filters available that you can change your features the way you want. Men also post their filtered pictures and when you meet someone in person, yourCOll be really astonished that, Is it the person that I saw on the internet? So, I donrCOt trust the internet and such things because a lot of my friends got scammed this way. To read more regarding this, visit this site [url=https://www.speedput.com/]ptcl speed test[/url] |
| asha.resendez@f10.n1.z35223.fidonet.org (asha resendez): Apr 24 03:32AM +1200 href="https://www.speedput.com/">ptcl speed test</a> |
| Kaz Kylheku <563-365-8930@kylheku.com>: Apr 24 03:51AM ["Followup-To:" header set to comp.lang.c.] > I used to cringe when I would see code that would allocate nodes all > over the place, and never free them. Sometimes they would allocate nodes > in loops! They would say, ahhh, that's for the GC. WOW! Allocating a node in the loop such that it is unreachable is actually a pretty easy situation for GC. (while true (cons x y)) The cons cell is allocated and immediately becomes unreachable. Being unreachable it means that when GC is triggered, it does not have to traverse it. Traversing the graph of reachable objects is a big expense. It will have to sweep these cons cells to reclaim them. But that would have to be done by explicit memory management also! Sweeping can be a big expense in a naive mark-and-sweep allocator. A generational garbage collector, though, makes the sweep cheaper. A generational garbage collector will allocate these new cells into a "nursery" of baby objects. When a certain limit is reached, a generational GC pass is triggered. The GC walks the object graph, but it avoids traversing across "mature" objects; it looks at areas like the machine registers and stack, looking only for baby objects. It will not find any of these baby objects because only the loop is creating them, and it loses track of each one. Then comes the generational sweep phase. Unlike in a full GC pass, the garbage collector only has to sweep through the nursery. The nursery is chock full of these cons cells made in the body of the loop. None of them were marked reachable, so they are deallocated. This sweep pass does not have to look at any mature objects at all. Basically, GC can be designed and tuned to deal with the pressure of a fast allocation of temporary objects that soon become garbage. Such cases arise in practical applications. For instance, macro expansion in Lisp. Or string processing. Or calculations with numbers that have to be boxed on the heap, like bignums and sometimes floating-point values. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal |
| 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