| even andersen <even.oscar.andersen@gmail.com>: Apr 20 01:49PM -0700 søndag 12. mars 2023 kl. 13:42:06 UTC+1 skrev Frederick Virchanza Gotham: > I mentioned a few weeks ago on this newsgroup about how I'm combining two programs into one. ... > stdout = f; Not sure the above is legal. As far as I know this cannot be done in neither C nor C++, it can be done in posix (For reference, and since the question was asked, not really c++ though) (For instance https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html) You might want to work on the right hand side of the filedescriptor table, assuming: (FILE *) / iostream ---> <file descriptor> ---> (client side object) ---> | ---> (kernel side object) with this model you would look at: pipe(2) dup(2) dup2(2) (dup3(2)) close(2) read(2) write(2) flockfile(3) / funlockfile(3) fflush(3) fdopen(3) This way you would: Keep stdout as is Keep fileno(stdout) as is Redirect what fileno(stdout) refers to stdout -> | fileno(stdout) | (some object) | fd_1 | ^ | pipe_wr | >---V | pipe_rd | <---V stdout -> | fileno(stdout) | (rewired to refer to pipe_wr) | fd_1 | (refers to old stdout object) | pipe_wr | >---V | pipe_rd | <---V 1) Duplicate fileno(stdout) to keep it around (create a new fd to the client side object) (dup) 2) Create a pipe, with a read end and a write end (create two fds to a new client side object) (pipe) 3) Change fileno(stdout) to refer to the write end of the pipe above (dup2) 4) Read from the read end of the pipe, -> this is where you capture what is written to stdout, and fileno(stdout) 5) Process what you read, and write it to the filedescriptor you duplicated in 1) The problem with this approach is that the object layout/processing layout is not specified for C or C++. Another weak point is that std::cout etc does not necessarily write to stdout/fileno(stdout) (Not really c++ though) And if you want it standardized, try this pipeline (buffered layer) -> (file descriptor layer) -> (client side object) -> (kernel side object) .. or write a library |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 20 01:04PM -0700 > I don't know about you but I'm quite glad the language models still generate > rubbish code. They day they start generating efficient working code based on > a simple request we're all out of a job. If I were to teach it how to give a correct answer, that would just help it put us out of a job. Yikes! ;^o |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 20 01:08PM -0700 On 4/20/2023 1:04 PM, Chris M. Thomasson wrote: >> a simple request we're all out of a job. > If I were to teach it how to give a correct answer, that would just help > it put us out of a job. Yikes! ;^o So far, it seems to have a hard time creating multi-threaded synchronization algorithms. It gets the memory barriers off, amongst other things... Now, if I were to show it where it went wrong, that would be teaching it. Why would I want to help it put programmers out of a job? |
| Muttley@dastardlyhq.com: Apr 20 03:58PM On Thu, 20 Apr 2023 16:59:59 +0200 >> std::optionals entire use case is functions that return simple values where >> a success/failure boolean is required too. >Perhaps you got that idea from working with old C compilers and old C Nope. >std::optional<> is extremely convenient. It is mostly just a wrapper Its an ugly mess. value()/value_or(), exception handling required, seriously? Thanks, but I'll stick with a simple bool return value. |
| Muttley@dastardlyhq.com: Apr 20 04:10PM On Thu, 20 Apr 2023 18:01:46 +0200 >>> It seems that everything that overwhelms you is pointless technology. >> Unlike you I write code to do a job, not with an obfuscated fashion show. >This "obfuscation" saves work. Not when some poor sod has to decode the gibberish to figure out what it actually does (which in your case is usually very little, all show and no go). |
| Muttley@dastardlyhq.com: Apr 20 04:11PM On Thu, 20 Apr 2023 18:03:11 +0200 >> Its an ugly mess. value()/value_or(), exception handling required, seriously? >> Thanks, but I'll stick with a simple bool return value. >The type of error may be relevant to a user. Then throw a standard exception, don't have some frankenstein combination of std::optional return value then a potential exception when you try to process it. |
| David Brown <david.brown@hesbynett.no>: Apr 20 06:13PM +0200 > Nope. >> std::optional<> is extremely convenient. It is mostly just a wrapper > Its an ugly mess. value()/value_or(), exception handling required, seriously? No, I assume you are not being serious. I use it in my embedded systems, with exceptions disabled, and it is simple, convenient in the code, and efficient in the implementation. You only need exceptions if you like to program by crashing ahead blindly, and trying to clear up the mess when something goes wrong - such as by using the "value()" method without bothering to check for validity. That would, of course, defeat the whole point of using optionals. Typical usage for me is : extern std::optional<Item> get_next_item(); auto item = get_next_item(); if (item) handle(*item); or : if (auto item = get_next_item(); item) handle(item); Sometimes I will use value_or() : auto config_port = get_config("port number"); open_port(config_port.value_or(default_port_no)); It is much cleaner and simpler than faffing around with passing pointers and using bool returns, is often more efficient, and works better with static error checking (such as checking for initialised variables). |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 06:37PM +0200 >>> Thanks, but I'll stick with a simple bool return value. >> The type of error may be relevant to a user. > Then throw a standard exception, ... Thrown exceptions are extremely slow (> 10.000 cycles) and often the return value should be passed directly to the caller. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 06:38PM +0200 > Not when some poor sod has to decode the gibberish to figure out what it > actually does ... That's not a big deal if you know the language. |
| Paavo Helde <eesnimi@osa.pri.ee>: Apr 20 08:22PM +0300 > or > 2) Update reference array directly. > Which do you think is more efficient? Local C array of 1 billion elements would run out of stack space, regardless of whether it resides in the leaf function or in the calling function. Ergo, one would need to use a std::vector instead, which can be returned efficiently. Thus there is no reason to use a reference parameter. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment