C, the language

psyclpc and libpsyc are in C, and a few other things in the software list.

psycpp also provides a little parser in C.

See also libpurple.

C++, the language

Dyskinesia and psycpp are in C++.

Some orphaned projects too, such as libPSYC and PsycM.

C#, the language

psyconaut is a .net application in C#

C# is an interpreted/stack machine/bytecode language, so it doesn't have all that much in common with C and C++. It just has a name that has us talk about it on this page.

See also: Mobile.

Where does it make sense to employ C/C++

There are plenty of situations where using C/C++ can be dangerous. It is certainly more difficult to develop safe applications in those languages than any virtual machine type of language. Also, PSYC applications are frequently confronted with situations they have never encountered before, because all sorts of people may send them all sorts of packets. That's why it is a good idea to have a backend that simply generates a runtime error and goes on doing its job when something unexpected happens, rather than crashing away.

But some scenarios like solutions in these more efficient languages. One such thing is serving a core service in the operating system. Recently I was pleasantly surprised to find out that my average Linux distribution has generally all non-stop running applications in native ELF binaries. Only administrative jobs are done with shell scripts, python and perl.

libpsyc should be a foundation piece of code that allows us to implement a little event notification daemon on top to do system monitoring, watchdogging, syslog and dbus gatewaying into PSYC implemented in a native language that makes it viable for unix distributions to provide it as a basic service daemon, or simply to enable existing daemons to produce PSYC notifications as we did with procmail.

Gotchas in modern C programming

Some things in C have changed since the days we used zero terminated strings. Security and a few other reasons make it necessary to provide lengths with strings at all times. This not only changes all the library functions available to work with, it also shows us the inconsistency in C APIs on this issue. It would probably have been the best choice if the world had chosen to use a String struct. Instead the largely dominant style in C APIs today is to provide the length as the next parameter in a function call, after the string itself. That's one thing we found out. When passing constant strings to most functions however it's practical to have a macro that will evaluate string length at compile time. As usual in C, it is not obvious:

strlen("whatever") == sizeof("whatever")-1

because sizeof includes the terminating zero, so if you want to pass "whatever" to a function like write() and avoid the runtime function strlen, you can do it like this:

#define CS2ARG(string) (string), sizeof(string)-1
write(STDERR, CS2ARG("whatever"));

Some tools like printf however still require the length beforehand, so you always have to be cautious as you code.