where is a copy of atlstr.h ??
in [Visual C]
|
From: Robert Macy on 29 Dec 2005 15:50 Stephen Howe wrote: > > It is NOT unreasonable to expect some kind of response to a search at > > MS website for atlstr.h > > > > At least something like, "Glad you asked, but that only comes in > > purchased software, and you'll really like it." > > That is not reasonable. There are 1000's of files that comes with Visual > Studio or Visual C++, should every file be listed as to which product(s) it > is available under? Just because you formulate a question, does not mean it > is reasonable question, nor should MS spend time wrinting documents to > answer it. Why not? It's their product. They're trying to sell it. And google certainly finds things quickly. > And since I know what > > #include <stdio.h> > > does, I don't care where it is located. Futhermore, for some C and C++ > compilers, there is no reason, at all, for stdio.h to be a file. I remember > with one previous version of Visual Studio, MFC and ATL headers were in > separate directories. Now they are not. First thing I did was a full search of the C: drive for the locations. For other "hiding" headers several lines were added to the compile batch file Set INCLUDE=C:\lots of places;%INCLUDE% ....but have to have the file to use the file > Yes but a quick file find should have established that none of the other MFC > or ATL header files are present on your computer. Your next thought should > have been "Does MFC or ATL come with any of the Microsoft products I have > installed?", a quick Google and you would know the answer. Actually, there are some 75 atl*.h files on the WinXP system, so I thought this "key" one was there also. > And it is not just headers but the associated libriares they pair with (and > possible DLLs). > Without those you are stuffed. A header is useless in isolation. > And a header is useless if you don't have the correct matching libraries. > You will run into "undefined symbols" on linking. Good point, and probably likely. Again, being specific when I searched would help. > Not rhetorical. You wanted to use the C++ compiler => you should have read > the FAQ on it. > A few paragraphs ago you were grumbling about missing documentation, now you > saying you don't need to read documentation that is available by Microsoft > on the product you are trying to use. Seems inconsistent to me. The FAQ on > any new product (and the README.TXT/README.HTM) are the first thing to read > just in case there are last minute "gotchas" I need to know about. So 3 days > to find out what you needed to know seems excessive. I read, but then there's read. If what is written makes no/little sense, reading more only exacerbates the problem. In C++ Toolkit the README.txt does indeed say that MFC and ATL libraries are not included. Ok. ...That's why, when I thought I found them somewhere else I thoiught they were complete, since the description said "everything you need to run..." I just thought I had missed picking them up somewhere. > Before you go, answer me 2 questions > > 1) If your position on missing header locations is so reasonable, how is it > I can find no one else using Google Groups that has ever raised this as a > question before? And I have looked. Multiple choice: a) People afraid to run a gauntlet of ridicule? b) Robert's brain is not configured like a Programmer's brain. c) Not a clue d) All of these > 2) And if the missing header locations is so reasonable, how is it I find > not one auxilary web site that rushes to cover Microsofts "glaring omission" > over the location of atlstr.h? Feel free to point them all out (or even > one). I can't find any, but then again we've already established I can't find anything. :) - Robert -
From: Alex Blekhman on 29 Dec 2005 17:31 Robert Macy wrote: > ...uh, at risk of killing the frog, I don't get it. Item 42 of Visual C++ 2005 Express FAQ says following: ------- Q.: Does Visual C++ 2005 Express Edition include MFC and ATL? A.: No, MFC and ATL are not included with Visual C++ 2005 Express. MFC and ATL will be included in all other Visual Studio 2005 Editions. ------- atlstr.h header is part of ATL library, therefore it is not included with Visual C++ 2005 Express.
From: Robert Macy on 29 Dec 2005 17:59 Right, Visual C++ 2005 Express does NOT contain the MFC and ATL. I understand your point even though I wasn't doing anything with the Visual C++ 2005. In the README.txt files of Visual C++ Toolkit [which I'm using] it says the same thing. But, again, I had downloaded much more than that, including something with Active Template Library that said "Everything needed to run..." and I did have some 75 atl*.h files, including atlbase.h, so I "assumed" I should have a copy and had simply missed it somewhere. Still the culmination is that I don't need ATL, nor MFC, which is good. - Robert -
From: John Carson on 30 Dec 2005 02:32 "Robert Macy" <macy(a)california.com> wrote in message news:1135878990.199159.150320(a)g44g2000cwa.googlegroups.com > John, > > Thank you for your excellent, well thought out, and extremely > informative reply. You are welcome. > It is copied and stored with my C++ Documentation files for further > reference. I greatly appreciate the time your response took. Yes, > Windows "landscape" is very unfamiliar. > > It's just that everything at once is a bit daunting. New to C++, new > to real-time programming, new to Windows platform. So it is difficult > to even understand the information. > > My goal is to accomplish the present task and to do it within a > "generalized" framework [not relying too much on any special > idiosyncracies]. Don't want to accidentally build in any bad habits > using libraries that may someday be deprecated. I would be fairly confident that ATL and MFC will be around as long as Win32 programming. There are a lot of people who would predict that .Net programming will be around even longer. Libraries offer great advantages, though it is always good to be able to "roll your own" if and when the need arises. > For example, I first thought that the free line command compiler was > slightly crippled, causing the code to run a bit slow. This seemed > reasonable. There in, should lie the "magic". I would expect to pay > in the range of $3K to $15K for "real" tools. Ok, at least I can test > run and kick the tires so to speak. I then posted a bench mark > section of code for others [with whiz bang systems] to try to see how > much improvement I should expect. I found that the "naive" code I had > written was 6 times faster than *anybody's* else's code using > "standard" approaches, relying on built in libraries, etc. > > The implication is: What you get when you pay for software is NOT > performance, but ease of coding. Crutches, methods, but, sadly, not > performance. That is currently the case. If you go back to VC++ 6, however, the compiler for VC++ Professional produced faster code than the compiler for VC++ Standard. When VC++ 9 arrives at some point in the future, who knows. > Ok, I can live with that, too. > > What happened to me was that not understanding much of anything about > this stuff, I quickly embraced any writing, any samples, that made > sense, or seemed to relate to what I was doing. In other words, I > oriented toward literate explanations. Yes, there are sample programs > contained in platform SDK, but they are absolutely incomprehensible to > me. > > I will stay away from distractions, like ATL, MFC, and .NET, since I > have no intrinsic desire to pursue programming in any form, be it MFC, > ATL, or .NET. I really need to simply accomplish this task. > > It is still very surprising that at least some response in a search > for atlstr.h at the MS website did not uncover the simple statement > "Thank you for looking, but atlstr.h comes with our purchased > software, some form of Visual Studio." I think that would require more intelligence than I have ever seen from a web site (a search for ATL might reasonably turn up such a statement, but not a search for a specific header). Mind you, Microsoft's search facility has been notoriously bad. They have been working on their search engine, trying to make it as good as Google, but I don't know if these changes have been integrated into the site yet. > John, would you contact me off group, so I can tell you more detail of > this project and make certain that I do have all the tools necessary > and am not headed down a blind alley? I think it is better to post questions to the group. I would guess that its collective knowledge exceeds my own by at least a factor of 100. Moroever, other readers of the group can benefit from any answers you receive. If you simply state your situation and seek guidance (and avoid getting into recriminations), then I think you will generally find that people are very helpful. -- John Carson
From: Robert Macy on 30 Dec 2005 12:01
Putting my question in as general terms as possible. The Hardware is a "standard" PC containing a commercially available soundcard. In which the OS must be Win XP. The soundcard has ASIO drivers built in and using C++ and the Steinberg SDK for ASIO it is possible to exercise the soundcard directly. It seemed reasonable that C++ can be used, along with "standard" Windows interfaces to make this hardware system into a viable instrumentation prototype for demonstrating various activities. I envisioned that 3 threads are necessary: 1) ASIO interface and data manipulation 2) Display 3) Control Question: Are the tools that I have, and the libraries available to me in those tools, sufficient to accomplish my end goals? Where should I be looking for great samples of similar programs? - Robert - |