How to - SDI
in [MFC]
|
Prev: Recommendation needed for embedded scripting solution
Next: Error C2440 cannot convert from void
From: Hector Santos on 23 Jan 2010 02:44 Tom Serface wrote: > I used FORTRAN and COBOL for many years on mainframes. I thought both > were decent for what I was doing at the time and, mostly, it was > available. I don't do any work with those these days, but I have fond > memories of card decks, overheated data sections, and, eventually using > PL/1 when I no longer could decide whether to use COBOL or FORTRAN any > longer. > > BTW, I think it's fair to teach "opinion". They do it in all college > classes these days (even science). I think it's fair to present all of > the information, then give the students the benefit of your experience. > > Tom Agree, but changing history is different :) -- HLS
From: Tom Serface on 23 Jan 2010 02:59 I wish I knew how to change history. We would have never lost ClassWizard... Tom "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eEgVv$$mKHA.1548(a)TK2MSFTNGP04.phx.gbl... > Agree, but changing history is different :) >
From: Hector Santos on 23 Jan 2010 03:45 Don't we all. :) But I think you are talking about destiny :) How did you lose ClassWizard? Tom Serface wrote: > I wish I knew how to change history. We would have never lost > ClassWizard... > > Tom > > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:eEgVv$$mKHA.1548(a)TK2MSFTNGP04.phx.gbl... > >> Agree, but changing history is different :) >> > > -- HLS
From: Ian Harvey on 23 Jan 2010 05:01 On 23/01/2010 5:32 PM, Joseph M. Newcomer wrote: > I programmed in FORTRAN. It is a Really Bad Language, but when you need "global" > variables shared with subroutines, you have to put them in COMMON. I agree with your sentiments and statements for the language "at the time", or at least the language designated by your capitalisation. But capitalisation aside, the statement in the second part of your second sentence is incorrect as of almost two decades ago. Personally, as a fluent user of both C++ and Fortran, I don't find the modern dialect that bad. It has it's ugly bits but so does C++!
From: Joseph M. Newcomer on 23 Jan 2010 13:34
See below... On Sat, 23 Jan 2010 00:36:29 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Joseph M. Newcomer wrote: > >> Professor Mary Shaw, from CMU, has a famous aphorism: >> >> "It is possible to write a bad FORTRAN program in any language" > > >I actually like this one. Mary probably has to deal with many >Westinghouse engineers to get grants. :) If Mary dealt with old Mobil >Oil Engineers, she could of come up with: > > "APL programmers really CAN program the world in one line!" > >Its a JOKE JOEY! > >> those complicated "classes", they have ideas like "I want to change the functionality of >> this control, but I don't want to create a subclass", they write bad Petzold code in MFC > > >Pertzold! Arggggggh, sucker took my DOS TREE program submitted to PC > Magazine, got the $50.00, and he rewrote it in ASM for the next >month publication! I actually got my behind slapped by Westinghouse >chief council for doing this. > >> **** >> One of the reasons most of my clients won't use C#, WPF, etc. is that it > > > doesn't support MDI, and therefore does not support what they > > need to do. It was a design blunder to not continue this > > important paradigm into the modern world. > >+1 from the standpoint of not restricting the mind. > >> I always get suspicious when someone says "higher overhead". I have no > > > idea what this means. > >Then you shouldn't question it against people who do. You do have an >idea, you just wish to be argumentative about it. > >> Sometimes, it means "it executes a few thousand instructions > > > extra while processing a mouse click" as if that statement has > > any meaning whatsoever. Particularly if you are trying to > > compare MDI to SDI, where they essentially have the same > > performance. > >It could also mean > > - programming overhead, > - more entry points for failure, > - higher learning curve, > - pressure points in flexibility, > >etc, etc, etc. > >> WINAPI is a bad choice, for the reasons I outlined. > > > > "There is no such thing as a bad choice, just bad choosers!" > >> I see nothing that suggests it was ever a good choice. > > >hmmmm, millions of successful applications in the market place? > >> If you want to use __stdcall, either invent your own macro for your >> application suite, or use __stdcall directly, but don't use a Microsoft word that means >> "the standard linking into the kernel" because that means changes in that interface can >> render your code nonfunctional, because you have based your interface on something subject >> to change. > > >That what is wrong was your IMPLEMENTATION. A good design usually >have their own wrappers, like for use, we have > > WCAPI > >which provides a pascal based stack calling prologue and epilog >conventation > >> .DEF files have their uses, but sometimes they are clumsy. > > > "There is no such thing as a BAD choice, just bad choosers!" > >> They are not always the first and best choice for exporting symbols these days, > > >I am going to take a wild guess that you are stuck using an IDE these >days. > >> You are programming in Delphi? > > >I was once a turbo programmer, until delphi 3.0. But I sincerely hope >you didn't think that is related to the two basic CPU stack >pushing/popping conventions. > >> THat's the only thing I know that has a pascal based stack >> prolog/epilog. > > >No, stdcall is a pascal based stack calling convention!!! You can't >change the RULES of the game! > **** I don't see how you can make this statement. It is most definitely NOT "Pascal" based. In Pascal, arguments are required to be pushed left to right. __stdcall does not push arguments left to right. Therefore, it cannot be "Pascal" based, in the sense of the PASCAL keyword of Win16. It is complete drivel to say that __stdcall is "Pascal" based because Pascal does not use the same linkage as __stdcall. It is true that for backward compatibility, the obsolete macro "PASCAL" in the Windows SDK was redefined to "__stdcall", but it does NOT mean it is a "Pascal" linkage. In fact, there is no trace of Pascal in Win32. So I have no idea how you can use this word with a straight face and claim it is meaningful. __stdcall pushes arguments right to left, and the called function removes the parameters from the stack. That is all it means. "PASCAL", in Win16, means that it pushes arguments right to left and the called function removes the parameters. Please explain how these two are identical. Pascal is a calling convention that existed only in Win16, and was completely and utterly abandoned in Win32. __stdcall replaced it. The obsolete PASCAL keyword was renamed to generate __stdcall, but that is not the same as a "Pascal linkage". If you had written a subroutine in assembler, you would definitely know that they are not at all the same calling convention! joe >> **** >>> WINAPI because that is how WIN32 works and it is the method most >>> explicit traditional binding is done in the API world. For use, this >>> important because we have a 250 function WIN32 API/SDK for all the >>> major languages, including p-code languages: >> **** >> You are confusing abstraction and implementation. If you want the implementation of >> __stdcall, you can either use it explicitly, or create your own macro, but relying on >> someone else's definition does not seem a good choice. > > >No, people use the STANDARD definition! What other DEFINITION is >there? Yours? > >> The point is you need to understand what Microsoft owns and what > > > you own. You own the linkages to your library, so using a > > keyword that Microsoft owns seems inappropriate. > >I really really hope people take your advice with a grain of salt. >IMO, you create more CONFUSION than not, and it has very little >practical implication. It defies logic the comments I read here. To >you, you probably wonder why the WORLD got to this point when it was >DONE all wrong! Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |