Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Drazen Dotlic — Wed, 29 Dec 2004 16:05:00 GMT

>> (Yes, I could have simplified this code a little by using a built-in stack class, but as I have already noted in the context of smart pointers, I try to present these articles in "pure" C++ so people won't get into arguments about which class library is best.)

stack is a part of C++ Standard Library, it's not any particular vendor's one, thus it is "safe" to use in this context.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Raymond Chen — Wed, 29 Dec 2004 17:52:00 GMT

It may be the part of the standard library, but it's still a library. Some people may like std::string, others might prefer CString, still others may prefer their own string library. (If everybody agreed on std::string then why are there so many string libraries?)

Standard Library

John McCormick — Wed, 29 Dec 2004 18:36:00 GMT

Perhaps if more people treated the standard library as a standard, more people would accept it as such. In any case, I don't think too many people would lampoon you for using it.

I always find this sort of mix of c-like code and c++ code a bit jarring, but then I'm not really a windows programmer. Looking forward to tomorrow's installment!

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Raymond Chen — Wed, 29 Dec 2004 18:38:00 GMT

True, but if I chose a specific library (even the standard one), I would lose people who weren't familiar with (or actively disliked) that library. But everybody who programs Windows knows what TCHAR is.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Drazen Dotlic — Wed, 29 Dec 2004 22:47:00 GMT

>>If everybody agreed on std::string then why are there so many string libraries?

So many? Besides MFC, I am not familiar with any other in widespread use.
The only reason for these "other" libraries, including (parts of) MFC has been poor implementation (or buggy) of both C++ compiler and/or Standard Library. Things are a lot better now with VS.NET 2003 and will be even better with 2005. It's time to start treating Standard Library as a part of C++ language, not something we might not use because we don't like it or are not familiar with.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Eric TF Bat — Wed, 29 Dec 2004 22:57:00 GMT

Maybe it's because I've been reading a lot of LISP code lately, but I looked at this article and my first thought was "Why is Raymond posting randomly-indented assembler code on his blog?"

C++: Just Say AAAARRGHH OH GOD STOP AAAAARRRGGGHHH HELP PLEASE PLEASE PLEASE UUURKKK!

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Noob — Wed, 29 Dec 2004 23:04:00 GMT

What does fibers have to do with this?

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Larry Osterman — Wed, 29 Dec 2004 23:06:00 GMT

Drazen,
There are lots of reasons not to use std::string, and CString/CAtlString often provide an alternative to it.

Just because STL's a part of the C++ standard library doesn't mean that it is a worthy solution for everyone - the code size bloat you get from using STL is enough to preclude its use in many scenarios (like most of the Windows core). Also the fact that STL's localization support is mediochre (it has to be because it's platform neutral, and localization basically requires a platform specific infrastructure (how you specify your localizable resources depends on the platform)) precludes its use in many places.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Rick C — Wed, 29 Dec 2004 23:08:00 GMT

Noob, this is a multi-part lecture. I'm sure Rand will get to that. Part 1 is setting a stage.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

MYG — Thu, 30 Dec 2004 00:09:00 GMT

Noob,

Because state is easily held on the CPU stack. A fiber is a bit like a thread in that it has its own stack but the context switching is driven by the application rather than the scheduler.

So the idea here is to have a tasking module without the tasking overhead (or part of it, stack space is overhead): two "fibers", one a consumer, one a producer.

Think of fibers as setjmp()/longjmp() with separate stacks.

IIRC, there is a "fiber like" construct in later versions of VMS. I wonder if they are a Cutler decree or just a common good idea.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Michael Kaplan — Thu, 30 Dec 2004 00:15:00 GMT

Speaking as the owner of a technology (namely, linguistic collation) and a colleague to the owner of a technology (namely encoding / codepages) and a former owner of a technology (namely, locale based formatting) which is superior in almost every way to the correponding CRT analogue, I can tell you that there are indeed times that the CRT is not always the best solution. And there do exist many times that it is not the answer....

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Kent Boogaart — Thu, 30 Dec 2004 00:33:00 GMT

This is OT and for that I apologise . . .

Does anyone know where I can find information about the next standard version of C++? I remember hearing about this somewhere but have no idea what it is codenamed etcetera.

Nice article Raymond (as per usual).

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Tim Smith — Thu, 30 Dec 2004 06:00:00 GMT

std::auto_ptr is a perfect example of something that just because it is the standard doesn't mean it is good.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Andreas Häber — Thu, 30 Dec 2004 09:38:00 GMT

Kent:
You can find some links about the next C++ standard here: http://www.gotw.ca/iso/

And also check out Herb Sutter's blog at http://www.pluralsight.com/blogs/hsutter/default.aspx

Happy new year everyone :)

Using fibers to simplify enumerators, part 2: When life is easier for the caller

The Old New Thing — Thu, 30 Dec 2004 17:58:00 GMT

This time, we'll watch the enumerator lose.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Drazen Dotlic — Thu, 30 Dec 2004 17:38:00 GMT

>>Drazen,
>>There are lots of reasons not to use std::string, and CString/CAtlString often provide an alternative to it.

Larry,

you are right. But let's put things into context here - this is supposed to be an example of a certain technique. State management is only a necessary "evil" here, it is not a meat of the post. I am simply arguing that standard stack could have been used to simplify the code sample without jeopardizing the message of the post - even better, shorter code might have improved the readibility and help push the message through.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Raymond Chen — Thu, 30 Dec 2004 17:49:00 GMT

Perhaps true, but when I see std:: stuff I tend to get more confused rather than less.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Michael Grier [MSFT] — Thu, 30 Dec 2004 18:18:00 GMT

The std:: stuff assumes you are comfortable with exceptions. I personally believe that there are unsolvable quality problems associated with use of exceptions. Thus, even though the library seems very useful, I stay as far away from the STL libraries as possible.

C and C++ (pre-STL) were systems programming languages which provided you with a syntax for using the underlying machine. The libraries provided were really just tokens to portability.

With the introduction of STL, C++ is moving/has moved out of the systems programming space and is trying to seem like an application programming language like BASIC. I personally don't see the point. If I wanted to use BASIC, with all its plusses and minuses, I'd use BASIC.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

asdf — Thu, 30 Dec 2004 18:54:00 GMT

"an application programming language like BASIC"

I see Microsoft doesn't do any drug testing...

Raymond: You need to cast the ULONGLONGs to unsigned __int64 when you pass it in to printf and you need the format to be %I64u because %I64d is the signed version.

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Cooney — Mon, 03 Jan 2005 18:09:00 GMT

> I see Microsoft doesn't do any drug testing...

Perhaps they do, just not the way you were thinking ;)

re: Using fibers to simplify enumerators, part 1: When life is easier for the enumerator

Sig9 — Tue, 04 Jan 2005 18:58:00 GMT

is part of the software industry. if you do not learn to learn (ya ya ya) you will be out of a job as fast as you can say "hello world!"

Why does Win32 even have Fibers?

Larry Osterman's WebLog — Thu, 06 Jan 2005 02:58:00 GMT

Why does Win32 even have Fibers?

Larry Osterman's WebLog — Mon, 10 Jan 2005 22:03:00 GMT

CSci 101 Part I

public Blog — Wed, 19 Jan 2005 08:11:00 GMT

CSci 101 Part I

Partially Debuggable CoRoutines

Wizzy's World — Fri, 21 Jan 2005 02:32:00 GMT

A while back there was an article in MSDN magazine about wrapping up the unmaged fibers API to implement...

Coroutines

Joe White's Blog — Fri, 12 Jan 2007 06:19:53 GMT

Coroutines

Joe White's Blog — Fri, 12 Jan 2007 06:21:26 GMT

Labr??tens Web Log » Blog Archive » Mimic the C# yield instruction in VC++

Labr??tens Web Log » Blog Archive » Mimic the C# yield instruction in VC++ — Thu, 29 Nov 2007 03:25:15 GMT

PingBack from http://www.labraaten.com/wpblog/2007/11/29/mimic-the-c-yield-instruction-in-vc/