In my previous post we’ve briefly looked at using ctypes module to call C APIs. In this post let’s dive into a completely different approach - writing a C extension using Python/C API. From the C extension you can then call whatever C/C++ code you want. This is a pretty popular approach to expose a 3rd party C library as python module. The downside is this module would only be loaded by CPython, which is usually not a big issue - unless you use other Python implementation like PyPy.
Recently I’ve been evaluating Python interop technologies for a project at work and I think it’ll made an interesting blog series.
I’ve recently wrote a NES Emulator NesChan. I had a lot of fun building this emulator and is planning to write a series of post documenting my experience and maybe help anyone who also want to write one. This is the first post.
I’ve been experimenting with coroutines recently and I found that information on C++ coroutines are very difficult to find. I’m planning to write a series of C++ coroutine blogs on how to use C++ coroutines, how they work, and how to write your own library that uses C++ coroutines. My last post Basic Concepts are probably a bit too high-level and is not really meant for people who are new to C++ coroutines. So I’m going to start over with a simple C++ coroutine tutorial instead.
It is sort of puzzling for me why C++ standard doesn’t have a implementation of reader/writer lock. So just like every other C++ developer, I’ve decided to roll my own.
I’ve been spending some time looking at how to wrap some of our existing C API that is based on completion callbacks, with C++ coroutines. I just got it working tonight and I thought I’d document what I’ve learned in this process and hopefully help other folks. My focus is the stackless coroutine / resumable functions proposed by Gor Nishanov et al and it is supported by Microsoft VC++ and Clang. I won’t be talking about boost::coroutine. I also won’t be talking about how to use coroutines - this is about how to write your own light-weight coroutine plumbing for library authors.
If you come from a C++ programming background, you are most likely already familiar with C++’s template code bloat problem. Each template instantiation gets its own copy of the code (of course, compiler/linker can optimize by throwing away unused methods). The reason being that C++ template are more like C macro on steriods. I know this is a great simplification, but at the end of the day, it is pretty much a code expansion feature with type safety. This grants C++ some powerful capabilities that C# developers don’t have - like template specialization, or calling arbitary methods on a template class, or a whole different programming paradigm that’s known as template meta-programming. On the other hand, .NET generics require you to define what operations can be perform on T using constraints (otherwise you are limited to a small set of operations such as casts, assignments, etc). However, this does give .NET a unique advantage - it can do a better job at code sharing.
I recently had some really interesting discussion with a .NET typesystem expert in the team, and during the conversation he had pointed out an interesting aspect of .NET value type boxing when using constraints. Intrigued by that discussion, I decided to take a further look.
If you’ve been following .NET Core development you’ve probably already heard about .NET Standard 2.0. We are bringing back a lot of APIs from desktop to .NET Core to make migrating existing apps easier. If you’d like to read more about what is netstandard, you can refer to this faq. In this post I’m going to show you how to dogfood (read: try out the bleeding edge new stuff) the latest .NET Core 2.0 which has the latest API changes in .NET Standard 2.0.