Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cello – A library that brings higher level programming to C

libcello.org

Post reply on HN
Print view View original

121–130 of 158 posts

Re: Cello – A library that brings higher level programming to C

#121

Post by simias »

Safety1stClyde wrote: post #113

As a superstitious C programmer, typedefing (void star) feels like walking on the cracks in the pavement, crossing the path of a black cat, walking under a ladder, or squeezing a lemon under the full moon to me. These kinds of tricks seem very clever at first but there always comes a point when they start to break down. I'd be leery about using union in 2017, but typedefing (void star) is like putting on your underpa…

I'm not super familiar with Cello (and I'm not sure I get the point of it overall, are there that many platforms left that you can target from C but not C++?) but in its defense it does seem to implement fat pointers and runtime checks to have a degree of type safety. Not sure how thorough it is but it's not just decaying everything to void pointers behind the scenes.

It's a pretty clever hack though, like using setjmp for exception handling. I'm pretty sure I'd never want to use that in production anywhere but it was probably fun to implement.

Re: Cello – A library that brings higher level programming to C

#122

Post by maccard »

camus2 wrote: post #114
kbart wrote: post #102

How about performance? As I understand, it uses fat pointers fat pointers and GC, so performance drop is expected. There are not many reasons to use C nowadays beside performance.

> There are not many reasons to use C nowadays beside performance. portability? stable ABI? ... writing something in C make it easy for any other higher level language to link to it. That's why we're not done with C, at all ... it's basically the only serious language out there used to share code among every possible platform or language. Even C++ which is a bit safer in practice is harder to link. I just wished C wa…

> Even C++ which is a bit safer in practice is harder to link.

Not to go down the C++ evangelist route, but if you want to write libraries in C++ to use with other high level languages, you can wrap the headers in extern "C", and still write C++ as normal in your own code.

Re: Cello – A library that brings higher level programming to C

#123

Post by maccard »

milesrout wrote: post #109
Chromozon wrote: post #37

Earlier quoted context omitted.

This is a great example of how many of the things in C that don't compile in C++ are horrible programming practices, and it's really nice that C++ doesn't allow such garbage.

I don't see what is 'horrible programming practice' about int *x = malloc(sizeof(int));

because malloc doesn't return an int, it returns a void

Re: Cello – A library that brings higher level programming to C

#124

Post by maccard »

comex wrote: post #72
gruez wrote: post #56

Earlier quoted context omitted.

use precompiled headers?

Precompiled headers never worked well due to a variety of limitations. C++ modules, on the other hand, will be like precompiled headers done right. If they ever get standardized. They didn't make it into C++17, and the prototype implementations in Clang and MSVC are incompatible with each other, but I guess it'll happen someday…

> Precompiled headers never worked well due to a variety of limitations.

We use precompiled headers on a large project, we've never had any issue with them (MSVC and GCC)> Care to elaborate on the limitations?

Re: Cello – A library that brings higher level programming to C

#125

Post by shakna »

ckastner wrote: post #106
shakna wrote: post #82

Earlier quoted context omitted.

I've used Cello for a few side projects, and it doesn't even really feel like C in the end. Just a few off the top of my head: * No need to specify type. Use var. * Simpler for loops * Inbuilt types for Hash Tables * File types, making file reading much easier * Function types, making it easier to pass functions around * Doctype access * Threads & Mutexes * Format strings * GC (with ability to turn C-types into Cello…

> * No need to specify type. Use var. I see types everywhere; they appear to just have been moved from the left-hand side to the right-hand side? eg: var i0 = $(Int, 5); var items = new(Array, Int, i0, i1, i2);

Mmm, kinda.

    var i0 = $(Int, 5);
    i0 = $(String, "Hello");
Perfectly valid.

Re: Cello – A library that brings higher level programming to C

#126

Post by ziotom78 »

maccard wrote: post #122
camus2 wrote: post #114

Earlier quoted context omitted.

> There are not many reasons to use C nowadays beside performance. portability? stable ABI? ... writing something in C make it easy for any other higher level language to link to it. That's why we're not done with C, at all ... it's basically the only serious language out there used to share code among every possible platform or language. Even C++ which is a bit safer in practice is harder to link. I just wished C wa…

> Even C++ which is a bit safer in practice is harder to link. Not to go down the C++ evangelist route, but if you want to write libraries in C++ to use with other high level languages, you can wrap the headers in extern "C", and still write C++ as normal in your own code.

…unless your library exposes classes/templates, which is probably what the majority of C++ libraries do (e.g., wxWidgets, Qt, Boost, etc.). In this case, creating C bindings is a real pain.

Re: Cello – A library that brings higher level programming to C

#127

Post by milesrout »

GlitchMr wrote: post #118
milesrout wrote: post #107

Earlier quoted context omitted.

'Strict aliasing' is a dangerous optimisation that OpenBSD's gcc-local disables for a reason.

Not really that dangerous, I think it's more of an issue of having code written before strict aliasing rule. Essentially, what strict aliasing rule requires is that user cannot go crazy casting pointers. Casting float pointer to int pointer is completely wrong. The exception is that it's completely safe to cast values to char pointer or void pointer (and back, but only to original type of a pointer). Objects of diffe…

Not really that dangerous, except for all the code for which it is dangerous?

Of course, you've got me, it only breaks existing code, and doesn't affect code that's written perfectly according to the rules of C and not peoples' intuitions about what pointers actually mean on a hardware level.

It's not even safe to do this:

    struct a {
        int x;
    };
    struct b {
        int x;
        int y;
    };

    struct b b;
    struct a *a = &b;
You have to write b like this:

    struct b {
        struct a inner;
        int y;
    };

Re: Cello – A library that brings higher level programming to C

#128

Post by milesrout »

maccard wrote: post #123
milesrout wrote: post #109

Earlier quoted context omitted.

I don't see what is 'horrible programming practice' about int *x = malloc(sizeof(int));

because malloc doesn't return an int , it returns a void

malloc returns a void pointer because it implicitly converts to an int pointer, as it should.

Re: Cello – A library that brings higher level programming to C

#129

Post by chriswarbo »

DSMan195276 wrote: post #81
spc476 wrote: post #77

Earlier quoted context omitted.

Yeah, that phrase "everything's an int" scares me (and I'm a C programmer---been programming in it since 1990). At one time I was playing around with Viola ( http://www.viola.org/ ) (quite possibly the first graphical web browser). The code is a mess precisely because it grasps the "everything's an int" and doesn't let go. Once you get it to compile (and out of the box it doesn't any more) it barely runs on a 32-bit…

As a C programmer, I would also agree. "Everything is an int" is not a good way to be thinking about things. There's a reason that `intptr_t` exists. Well written C shouldn't rely on any integers being specific sizes or the same size unless you're using the standard types for that purpose (Llke `uint8_t`, `uint32_t`, etc.). Even then, you probably don't need them in a lot of cases, and you should basically never be c…

To clarify, I should probably have said "integer" to avoid confusion with the C type called "int", or to be more accurate ℤ/w for a variety of widths w.

I didn't mean "C is nice because I can just write 'int' for all the types and it works", I meant "C is nice because it represents data in a very conceptually uniform way: either as integer, or 'pointers' which are themselves integers."

The current world population is an integer, my bank account number is an integer, but that doesn't make it's meaningful to add them together. Values can have the same representation without being the same type :)

> "Everything is an int" is not a good way to be thinking about things. There's a reason that `intptr_t` exists.

From http://en.cppreference.com/w/c/types/integer (top Google hit for `intptr_t`):

    intptr_t
    integer type capable of holding a pointer
They're integers :)

> Well written C shouldn't rely on any integers being specific sizes or the same size unless you're using the standard types for that purpose (Llke `uint8_t`, `uint32_t`, etc.).

I never said it should; but from that same cppreference site:

    int8_t, int16_t, int32_t, int64_t
    signed integer type with width of exactly 8, 16, 32 and 64 bits respectively
These are also integers :)

> you should basically never be casting integers into pointers

Again, I never said you should. I didn't say, or mean, anything about casts.

Re: Cello – A library that brings higher level programming to C

#130

Post by oblio »

jacquesm wrote: post #42
oblio wrote: post #40

Earlier quoted context omitted.

The Iron fans are doing a bit of harm but that Perl zealotism is one of the things that made it wildly popular in its day. And unlike Perl, Iron development is structured, not "organic" a la Larry Wall/Perl. I'm not an Iron zealot but I do believe that there rarely is such a thing as bad publicity :)

Seen much perl lately?

Yes, surely the downfall of Perl was caused by its zealous fans, not by the apparition of other programming languages that were either easier to use (PHP), more readable (Python) or had more attractive frameworks (Ruby) :)
Post reply on HN