Alexey Zakhlestins blog » c++

C, headers

indeyets — Tue, 08 Jul 2008 07:52:22 +0000

The concept of headers in C was necessary at its time, but these days it just makes compilation of complex program in complex environment several times more complex. Whenever you have several package-roots (I have /usr, /usr/local, /sw, /opt/local, /opt/some_pkg1, /opt/some_pkg2 at the same time), which have different versions of the same libraries, you need to separately check resolution order of libraries and header-files.

Sometimes it feels completely counter-intuitive and you just end up manually hiding some files.

Common end-user solution is just sticking to the package-root provided by distribution (usually “/usr”), but that is not an option for developer, who needs to test different combinations of bleeding-edge apps.

How do you manage this stuff?

Example. I need to build php6 (installation prefix /opt/php6) with:

iconv from /sw (whle there is other iconv in /usr)
libxml from /usr (while there is other libxml in /sw)
icu from /sw/local (while there are pieces of other icu’s in /sw and /usr)

In reality, there are more libs involved, and complexity arises, when these different libs are needed by the same components of php. I start thinking, that I should create some special package-root and just symlink every needed library in it. And just give it as the only package-root to php. Seems like a complex task, while considering all dependencies.

In my ideal world, there would be no name-resolution at all, compiler would just require exact position of library (which would be represented by the single file)

Spread constants

indeyets — Wed, 07 May 2008 09:42:36 +0000

Playing with Spread Toolkit. Absolutely love their constant-names

UNRELIABLE_MESS
RELIABLE_MESS
FIFO_MESS
CAUSAL_MESS
AGREED_MESS
SAFE_MESS
REGULAR_MESS

p.s. freshly released php binding is here

@ ohloh.net

indeyets — Thu, 26 Jul 2007 13:46:33 +0000

By the way, I registered an account at ohloh.net project. You can see all opensource-projects I was involved . . . → Read More: @ ohloh.net

Unicode vs. Programming Languages

indeyets — Thu, 26 Jul 2007 13:40:14 +0000

I really-really want to see a programming language, which allows using proper unicode symbols for operators.

I mean:

Ã— instead of *
â†’ instead of ->
â† instead if <-
â‰ instrad of !=
â‰¤ and â‰¥ instead of <= and >=

This list can be continued more and moreâ€¦

I perfectly understand the roots of current situation and I don’t ask to use ONLY unicode-symbols, but I ask language-manufacturers to allow this.

OSNews: Apple Developing a New LLVM C Front-End

indeyets — Fri, 13 Jul 2007 08:41:11 +0000

Somehow, I missed this news earlier, but, I guess, it is very important. Because it means, that:

MacOS would be able to use non-gcc by default (there are some comments, here, describing why it is a good thing)
MacOS would become really-really cross-platform

BeOS + SmallTalk

indeyets — Sun, 03 Jun 2007 19:34:55 +0000

Some internal feeling makes me believe, that Smalltalk would be an ideal language for Haiku-OS/OpenBeOS (which looks more and more alive, again).

BeOS was always about C++, opposing UNIX’es, MacOS’es and Windows’es choice of C (well, formally, windows had C++ api, but, still, it was very C-ish in it’s essence). Years passed, MacOS switched to Objective-C, Windows switched to C#. Both of these languages are higher-level OOP languages which have some kind of memory-management. C++, while it has some advantages, still is not as easy and dynamic as these languages are.

Unfortunately, both Objective-C and C# are developed by Apple and Microsoft (correspondingly) behind the closed-doors.

So, what is the alternative? I see two of them:

D
Smalltalk

D is good, as it makes a step from C++ to real life, but is still low-levelish, by design. memory management will solve some headaches, but programming in it won’t be as fun as it can be. I like to see D as a language for writing libraries.

Smalltalk, on the other hand, is a high-level dynamic language which is just what is needed. Once you “taste” the fruit of dynamic languages you wouldn’t want to code high-level tasks in static-languages anymore (static is extremely good in low-level, though). To give you a brief idea on what all this is about, there is a nice article by a game developer who switched from C++ to Smalltalk: Learning to Talk: Introduction to Talking.

fink: BOOST_FOREACH

indeyets — Fri, 20 Apr 2007 12:29:13 +0000

One more addition to Fink from me: BOOST_FOREACH. This is one of my favorite extensions of C++. It lets one to iterate over virtually anything that can be iterated, while still being extremely effecient.

Here is a very nice introduction to Boost.Foreach.

(If you don’t knowâ€¦) Fink is a project that brings the full world of Unix Open Source software to Mac OS X.