Benoît Minisini ha scritto: >> Pipes should not return EOF when the pipe is not closed. But they should >> return EOF when the other side closes. >> >> > Why ? > Because this is the way *all* unix routines work, and the only logical one. > EOF() actually means "there is nothing to read anymore", which is the > important needed information. > Indeed: it means "nothing anymore", not "nothing at the moment". > If Eof() returns TRUE only when the pipe is closed: > > 1) How do you know that there is nothing to read anymore? > I know that there is nothing to read now, and in the future too, if eof() is true. If eof() is false, I know that some data could arrive, if not now, in the future. Try "cat", one of the simplest unix commands. It knows very well when there is data to read, when there is not, and when the pipe is closed.
> 2) What do you do for Sockets, for example? > The same as pipes. If there is data to read, I read it. If there is not, I don't. If eof() is true, I close my local socket because the other peer has closed. May be I am missing something -- using your ideas, how can you tell that a pipe (or a remote socket) is closed or not? > >> A compound control should intercept all events of its members, and raise >> its own ones. More in general, a class which uses other classes, or >> inherits from them, should completely own them and control the whole >> thing, even during creation and destruction. >> > That is what I mean with "solving the ValueBox problem". > Sorry to having invaded your field. I was speaking more in general, not only ValueBox and not only events. >> An OnIdle event would be handy, raised every time there are no other >> events pending. >> > Mmm. This will eat all the CPU... > I know. I can only add that on some other system, to prevent this CPU eating, the Idle event has a parameter "Done" that, when set to true, stops further idle events (until the idle condition happens again). It works like this: the event loop does not find any event, and so sets Done=true and enters the Idle loop. The Idle loop consists in raising continuosly an Idle event, until an event is present in the queue, or Done becomes true. The Idle event handler sets Done to false if it has more work to do. If there is no Idle event handler, just one event is raised. To be more precise, other systems do not even raise this single event, if there is no handler to it. >> The preprocessor could implement "#define" and use the definitions to do >> simple token substitution (and, of course, make test on them). >> Otherwise, you end in too many nested "#if". >> > What I can do is implementin "#Const xxxx =<expr>", with<expr> being only a > test expression. > > I don't have the time to embed an entire evaluator in the compiler. > I was not really thinking at evaluator/expressions... you surpassed me... - they are useful but one can live without. And one can live without "#define" for token substitution. You choose. It was only a suggestion. Anyway, your idea (#const ...) does already the job I was thinking of. I was thinking at situations where you want to include many things in the program only when the os is "linux" and word length is 64 bits, for example. In that case, you should write many times an expression like "#if os="linux" and architecture="ia64"" or something like that. Instead, you can define once for all a "#Const linux64=true" and test subsequently for "#ifdef linux64" and so on. To be sincere, I don't like the C preprocessor, it is too simple and too powerful at the same time... :-) Regards, Doriano ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user