|
Nick Hodapp (MSFT) wrote:
We rewrote the STL documentation (and revamped the implementation of the library itself) for Visual C++ .NET 2002 specifically to address the "bloody awful"-ness of the 6.0 docs.
I am aware of the legal hassles you guys had with your STL implimentation and from the brief chance I've had to use the new one, you've done a great job in fixing it up. I've never had a need to read the new docs though, I've used it only on a legacy app, I mainly code C# at home and we still use VC6 at work.
Nick Hodapp (MSFT) wrote:
Is it still that terrible?
I presume not, based on how good the actual STL implimentation seems to be.
Now if Microsoft would only pull it together and fix partial template specialisation ( and would Koenig namespace lookup be too much to ask for ? ). Do you have any idea when the pts is happening ?
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Partial Template Specialization and a slew of other ANSI/ISO C++ conformance features are in the works. Stay tuned.
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
AFAIR the VC7.1 compiler update was promised for this summer  I also talked to people who already use a pre-release version and told me they are quite happy with it (it compiles Blitz++ and Loki!).
Can you give us any estimation when this cool thing is shipped to waiting masses?
It would be the real reason to switch to VStudio.Net... 
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
Like "in the works" would help us when we've been waiting since 1998?!
Sorry, but I couldn't resist it, not to mention you (Micros~1) deserv it - and more.
|
|
|
|
|
Nick - I've got a question about the STL documentation - not about the presentation (which seems OK - personally, it's just I haven't used it much compared to the VC6 docs), but a techie question that was raised in comp.lang.c++.moderated earlier today - the STL documentation for containers (vector, list etc) contains the following in the description for the end() method:
'If the container is empty, the result is undefined'
Is this actually true?! There's a requirement on containers in the C++ Standard that begin() == end() for empty containers - and that's what your implementation does... There's nothing on the Knowledge Base if it is an error in the docs...
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Ah hah, this _is_ confusing! The documentation for vector::end() reads:
Return Value
A pointer to the end of the vector object. If the vector is empty, the result is undefined.
This entire statement is misleading and I'll submit it as a bug. The iterator of a std::vector is no longer the same as a pointer. But an empty vector does satisfy begin() == end(). In our implementation, end() actually points to 0 internally when the vector is empty.
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
Hadn't even picked up on the pointer bit  - hadn't realised that your vector (and string, for that matter) iterators weren't pointers any more - still, I had made the correct assumption that the docs were wrong, not the code  (but not before tracing through the code in the debugger).
BTW - I presume the bug report indicts the documentation for all the container types - as I said before, the statement about the results of end() being undefined for an empty container is made in the documentation for each and every container type<edit>but not the basic_string class - but then that's not totally one of the container family</edit>.
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Well, you shouldn't be upset for bad feedbacks. We pay 1000s of dollars for your products each year and I think it is our right to complain about the things that we paid for. It is nothing personal. And also you get your rewards. You are the richest company. Don't be so agressive! If there is something that I do not like, i would surely complain about it.
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
Mustafa Demirhan wrote:
Don't be so agressive
 Nick was simply asking genuine questions in order to get feedback so he can tell his guys to make it better. Nick's job is to make sure we're happy with VC++, so the more feedback he can get the better.
I only wish he'd hang out in the forums *more* 
cheers,
Chris Maunder
|
|
|
|
|
Chris Maunder wrote:
Nick was simply asking genuine questions in order to get feedback
 Sorry Chris. I thought I misunderstood him. My native language is Turkish and sometimes this causes some confusions 
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
That's OK - I figured it was just one of those situations where not being able to see the face of the other person makes it easy to misinterpret.
One of the coolest aspects of CodeProject is watching the interaction between people of different cultures. We're all learning 
cheers,
Chris Maunder
|
|
|
|
|
Inline tells the compiler that you would like to place the actual code of a function "inline" with the code you are calling it from instead of making a jump to a farther away location in memory. It may allow faster execution, but it requires more memory because multiple copies of the same code are used.
Functions that do a simple calculation or simply return a variable are good choices for inline. However, it may or may not be used for your public functions. It is an optional directive and the compiler decides whether to use it or not.
|
|
|
|
|
Also, you cannot use inline functions for callbacks (for an obvious reason), nor you can't inline functions that take a variable number of parameters.
my 2 cents 
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
Actually you can use inline functions for callback. In this case the compiler (if he decided to inline the thing at all) automatically creates a not-inlined version of the function.
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
To add to what the others have said, inline functions are also useful when you've got a class that's a minimal wrapper around some data (doesn't really do much with it but hold it together; this happens a lot when OOPing Win32 APIs...) and you want to be all nice and proper about it, so you make all data members private or protected. Instead of going to all the bother of writing out a separate CPP file with the access functions, since they're not going to be doing any validation or conversion anyway, just add them all to the header file as inline functions.
(oh yeah, no matter if you use the inline keyword or not, in order for the compiler to actually expand it, the function does have to be in the header file, or at least some file included where it's used.)
---
Shog9
Actually I use to find learning in bars when drinking really useful.
It sort of makes a language liquid. - Colin Davies, Thinking in English?
|
|
|
|
|
IMHO you shouldn't even bother worrying about it. The compiler will inline functions as part of its normal optimization when it sees that they are very short and fast.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Is there a way to control the order in which global objects are constructed?
I have a global debug object in my main module and a few global objects in another module that are getting constructed before the debug object.
Todd Smith
|
|
|
|
|
Todd Smith wrote:
Is there a way to control the order in which global objects are constructed?
No. If you need some explicit order, declare object as static in accessor function returning a pointer or reference. This way, you have the guarantee of proper initialization.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
there's no reliable way for this...
one thing you can do is to make your debug object a Singleton
and then call it's CDebugClass::Instance() method to initialize the instance in a point in your code where you know it'll be initialized before other objects, such as CMyApp::InitInstance if using MFC.
class CDebugClass
{
...
static CDebugClass & Instance();
...
};
CDebugClass & CDebugClass::Instance()
{
static CDebugClass theInstance;
return theInstance;
}
-Wes
Sonork ID 100.14017 wtheronjones
|
|
|
|
|
The standard clearly points out that the initialisation order of global objects is not deterministic.
However if you don't need to be portable you could use the #pragma init_seg() compiler statement. This works fine and is enough in most cases.
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there  )
|
|
|
|
|
I have a text file (listfile.txt) with a list of filenames(no paths, just abc.bmp). This I got by doing dir/b in the dos command. Now I want to read these into some sort of array so I can put them in a database field as a sequence of records. SO my question is - what MFC functions do I have that will open my listfile.txt, read from it line by line , putting each line into an array element?
I was reading about fopen and fgets but I'd like CStrings if I can do it that way. I think the entries are null terminated plus carriage return and line feed (or maybe not linefeed ). I'm on win2K. Hope my question makes sense.
Thanks,
ns
|
|
|
|
|
|
That looks ideal. Many thanks,
ns
|
|
|
|
|
Please never, ever use fopen and fgets again. Read my articles on the iostream library instead.
If you must use MFC strings instead of standard ones, then the MFC reading stuff which Mike suggested is the way to go.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
[quote]Please never, ever use fopen and fgets again. Read my articles on the iostream library instead.
[/quote]
I agree about the use of CString with fgets(), -- but otherwise an old foggy like me will NEVER do without those functions.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
