All Blog Comments

Jeff Preshing - How C Resolves a Function Call

Jeff Preshing — Sun, 18 Apr 2021 20:45:19 +0000

You're not doing anything wrong. It's just not a complete program, since the definition of galaxy::blast isn't given.

Maksadbek - How C Resolves a Function Call

Maksadbek — Sat, 17 Apr 2021 08:35:46 +0000

The first example code can't be linked Clang 12: https://godbolt.org/z/evP4sq8EP Am I doing anything wrong ?

Mario - How C Resolves a Function Call

Mario — Thu, 1 Apr 2021 06:35:50 +0000

Thank you for the article, it's very clear with beautiful drawings.

dbjdbj - How C Resolves a Function Call

dbjdbj — Fri, 19 Mar 2021 09:55:44 +0000

Was ADL invented so that iostreams user-defined streaming operators are possible?

ilian - How C Resolves a Function Call

ilian — Tue, 16 Mar 2021 21:47:58 +0000

Great article! Kudos for including E.Honda! Also would be great if you add some fn() call conventions also.

Jeff Preshing - How C Resolves a Function Call

Jeff Preshing — Tue, 16 Mar 2021 12:35:53 +0000

Thanks! The diagrams were made in Inkscape.

cplusplus.es - How C Resolves a Function Call

cplusplus.es — Tue, 16 Mar 2021 10:08:45 +0000

Great article and very good explanation. Thanks for sharing with the community!

Ihar - How C Resolves a Function Call

Ihar — Tue, 16 Mar 2021 04:12:25 +0000

Great Article. What soft/tool/approach did you used for creating such good diagrams/drawings ?

Garcha Sprgchma - I/O in Plywood

Garcha Sprgchma — Wed, 15 Jul 2020 04:27:55 +0000

I am looking more on the API design of IO library, it is very possible that the usage area of plywood may not require such close(). I came to the case with explicit close-as-terminate when tried to do client side of SMTP. It was implemented as open()+stream: open() get different parameters, establishes (or reuses) connection and returns an output stream. This stream is used to push email to the server, it should have explicit fallible close-as-terminate method to complete the 'DATA' submission command and get '250 OK' or error response from the server. { .. output_stream os=smtp.open_submission(sender, recipients, extra_params); os.write(sizeof(email_bytes), email_bytes); os.writeEnd(); //fallible close() } It can't be placed into destructor because destructor should not throw an exception.

Jeff Preshing - I/O in Plywood

Jeff Preshing — Sun, 12 Jul 2020 19:10:07 +0000

Right now the underlying pipe is closed in the In/OutStream destructor. But I'm open to adding a close() member function (or equivalent) if it exposes useful new functionality. (Everything in Plywood has been implemented on an as-needed basis so far.) I'd like to understand the problem you're describing a little better. Can you give an example of a bug that you want to be able to avoid?

Jeff Preshing - I/O in Plywood

Jeff Preshing — Sun, 12 Jul 2020 19:03:13 +0000

Hmm, I'll admit that when I replied, I was thinking about readers (InStream), even though your original question first mentioned StringWriter. I think you're right about StringWriters. When the application writes text to a StringWriter, it's providing all the source string(s), and so the I/O system *could* convert directly from the source string to the temporary output buffer. At least for newline conversion (let's say). This would change the API for StringWriter to some extent, and we would have to reserve a few bits from InStream::status to indicate what kind of newline conversion is performed by the StringWriter, but I think it would work. So that might not be a bad suggestion. I'm still not sure it would be easy/worthwhile to eliminate one of the buffers in the StringReader case though.

Garcha Sprgchma - I/O in Plywood

Garcha Sprgchma — Sun, 12 Jul 2020 03:27:27 +0000

It is interesting how you are going to design IO stream ending/termination. See - this ubiquitous IO stream concept modelling the _infinite_ data steam. Termination is usually bound with the releasing resource: that is close(), dispose() etc methods. But i think it is not correct - releasing is a no-fail operation and for termination you need to transfer "there are no more data" knowledge to the other side - and like any other transfer/write() it may fail. Socket's graceful termination, "you should check result of close() when working with file" etc - for me they are all band-aid to fix this misdesign. So yes i would like to see how this can be done in plywood

Ivan Bobev - I/O in Plywood

Ivan Bobev — Thu, 9 Jul 2020 21:12:33 +0000

> To flip the question back around, how would you expect to eliminate one of the buffers? It seems to me that the amount of the intermediate memory needed for some types of converters/filters is significantly lower than a whole buffer. For example for removing '\r' character only the current byte is needed and for converting to UTF-8 up to 4 bytes are needed, but it is possible that I totally misunderstood something.

Jeff Preshing - I/O in Plywood

Jeff Preshing — Thu, 9 Jul 2020 19:39:54 +0000

That's a good question. One possible answer is that it's simple this way. Another possible answer is that the converted data has to go somewhere, and Plywood's approach is to manage the destination buffer so that the caller doesn't have to. And while I didn't mention it in this post, there are functions to help you interpret the data in its "final form": For example, if you expect to read a binary message that's N bytes long, you can call InStream::tryMakeBytesAvailable(N) -- this will make sure that there are always N bytes available to read contiguously in memory starting at curByte, assuming EOF is not encountered. To flip the question back around, how would you expect to eliminate one of the buffers? For example, what kind of data would you be reading? If you're reading a line of text, you don't know how long the line will be until after you've read it, so in general, there's no way to know what size of String to allocate ahead of time.

Ivan Bobev - I/O in Plywood

Ivan Bobev — Thu, 9 Jul 2020 12:42:43 +0000

I cannot understand why in the case of StringWritter adapter a separate buffer is needed for the adapter and the actual stream? Isn't it possible to do the conversions on the fly and to use only one buffer? The same question arises for the StringReader case?

Kaja3 - xkcd Password Generator

Kaja3 — Wed, 12 Sep 2018 22:41:03 +0000

You do know they crack passwords based off entering a series of symbols in an order, until they use them up, and then add another character to the sequence. That would take hackers a few weeks, but nonetheless not very long, to crack it. In this case, quantity would surpass quality. And hacked passwords you cannot normally replicate are even better, as password cracking software won't take into consideration those passwords.

Kaja3 - xkcd Password Generator

Kaja3 — Wed, 12 Sep 2018 22:33:31 +0000

If your password has at least 4 nice, long words, and all the words are relevant to each other, and are based off something you like (ex. timetravellingwashingmachines for Mario and Rabbids: Kingdom Battle fans), you will have no problem memorizing them, and they will score high on this website https://howsecureismypassword.net/ . https://howsecureismypassword.net/ is an online password test that allows you to see how long it takes for hacking software to crack your passcode. (the example i gave was measured to take 3 sextillion years to crack, but i memorized it almost instantly)

Eddie Edwards - Implementing a Recursive Mutex

Eddie Edwards — Wed, 22 Aug 2018 14:28:25 +0000

This is a nice idea and it works, but it means the golden path is the recursively-taken case. The golden path should be the uncontended-nonrecursively-taken case. Comparing ctx to owner and taking a branch when they're not equal is a waste of time for this case.

Jeff Preshing - Memory Ordering at Compile Time

Jeff Preshing — Sat, 18 Aug 2018 17:37:20 +0000

Yes, if you make it a configuration option in your own project! Linux has its own configuration option for this: CONFIG_SMP. It's checked throughout the Linux source code to know whether it's compiling a kernel that will run on single processor system or multiple processor system.

Poxma - Memory Ordering at Compile Time

Poxma — Sat, 18 Aug 2018 05:21:38 +0000

"The Linux kernel exposes several CPU fence instructions through preprocessor macros such as smb_rmb, and those macros are reduced to simple compiler barriers when compiling for a single-processor system". When "compiling", is it possible for the compiler to known that the program will run in "a single-processor system" ?