From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8a402d78988bdf2b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-19 17:49:53 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!news2.telebyte.nl!npeer.de.kpn-eurorings.net!rz.uni-karlsruhe.de!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail From: "Ekkehard Morgenstern" Newsgroups: comp.lang.ada Subject: Re: [announcement] SYSAPI and SYSSVC for Windows Date: Sat, 20 Dec 2003 02:49:44 +0100 Organization: 1&1 Internet AG Message-ID: References: NNTP-Posting-Host: p508c1179.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: online.de 1071884993 6183 80.140.17.121 (20 Dec 2003 01:49:53 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Sat, 20 Dec 2003 01:49:53 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Xref: archiver1.google.com comp.lang.ada:3599 Date: 2003-12-20T02:49:44+01:00 List-Id: "Dmitry A. Kazakov" wrote: > No the problem is that time slicing functions in some different way. We have > heavily multitasking data acquisition and control applications running > under Windows. When customers expressed a cautious desire to "take a look > at", we discovered that things worked just fine under NT, performed worse > under 2k. Under XP we already needed to play with thread's priorities to > make it working... What kind of stuff are you doing? Why not use message queues and asynchronous I/O internally and stuff? Even Win 2000 can be amazingly fast (XP even more). It just depends on how you're approaching your projects. There are often various ways to do things, and it depends on which way you choose, how your program will perform. There's almost always a way to do it faster. > I do not count the stuff you mention as a part of OS. And instead of useless > job scheduling and fancy visual effects, they'd better make DLLs and > drivers being notified upon process termination or at least > ReleaseMutexAndWaitForSingleObject... Huh?? DLLs ARE notified upon process termination. The DLL has to have a DllMain() function that receives parameters like DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH and DLL_THREAD_ATTACH and DLL_THREAD_DETACH. However, you must not terminate the process forcefully. Under some conditions, the DLL cleanup is not done properly, but this is documented well in the Windows API documentation. A desire in a "ReleaseMutexAndWaitForSingleObject" function smells like bad multithreading design to me. What is it that you want to achieve with that? > > You can already run 64 bit applications on XP. > > Huh, I ran 64-bit applications on NT four years ago, before Compaq killed > DEC Alpha! That's true, I was referring to Intel platforms. ;) > > Also, wanting features from other languages in Ada might not be the right > > solution. Ada has its own concept. We'll see what the Ada20xx committee > > will decide upon. > > It is not about features of other languages. I know no language which > consistently implements ADT (and OO) In C++ you can use pure virtual classes to provide abstract data types. And in Java, you use interfaces. > You need not to advocate for Ada in c.l.a! (:-)) But the example is > unfortunate, both Ada and C++ do assignment wrong, IMO. How would you like assignment to be handled? > They are rather independent things. The problem of C++ is that I cannot tell > the compiler to derive "=" from copy constructor. That's true, in C++, operator=() is not inheritable. But that's because of the way object construction is handled. > > exceptions in C++, I have to create a real exception class, while in Ada I > > can simply declare it, which greatly speeds up implementation of code > > supporting exceptions. > > Right. But there are also numerous problems with exceptions in Ada. In > general they fall out of the type system. I do not think as many do, that > C++'s mapping exception->type is good. Ada's exception->object is OK to me. > But I wished to have exceptions a true enumeration type, to have ranges. > And thus extensible enumeration types, and of course a way to put > exceptions in the contract of a subprogram. Call me a heretic, but I think how Ada handles exceptions is cool! ;) I'm glad I don't have to specify exceptions in the function/procedure contract. Imagine how that would blow the spec declarations out of proportion! ;) (I hated that feature already in C++ and Java and I'm glad it doesn't exist in Ada) ;) For example, to show you why it's wrong: At my previous employer, there were lots of rather inexperienced programmers working on big Java projects. They would throw exceptions and not declare them properly, catch them properly and/or omit them from the method contract declarations. The result was that there were a lot of bugs related to exception handling. Ada really simplifies exceptions a lot. And in the worst case, the program simply exits. (better than awkward handling and unpredictable behaviour) So having exception contracts for subprograms don't really eliminate the problems (programmers) in front of the computer! ;) Enumerations for exceptions might also be a bad idea. Imagine if someone puts an exception in the middle of some range that wasn't intended to be there, and *poof*, your good concept goes overboard. > > In C++, there are no built-in types for concurrent > > data structures and tasks, which means you have to use a library, which is > > almost never portable. > > ... and definitely has race conditions problems. Depends really on how you program. In good multitasking programs, there are no race conditions! ;-P > But again, there are problems. We need tasks and protected objects be tagged > types, separate bodies for accept statements, protected actions on multiple > protected arguments, rendezvous with multiple tasks... (I have a large > list) I solved the accept-thing in my SYSSVC package by calling procedures in the accept handlers. :) Perhaps some of the things that you wanted will go into the new Ada standard. In the meantime, I guess we have to do without them. ;) And remember: There's always another way to do it! ;) Ada 95 provides me with programming conveniences I've never dreamt of before. It's like cotton candy to me! :) (of course, as a C++ programmer, in the beginning I've cursed at some of Ada's peculiarities, but now I like them! ;) ) Hah, you just need to "downgrade" your design a bit and make it simpler, not as fancy as you would with C++, and boom you get along well with Ada. :) You do not only save time by doing that, the program will also benefit from it with less bugs and smaller footprint. :)