HN Explorer

13 comments

[ 2.5 ms ] story [ 22.3 ms ] thread
improgrammer007
I would rather focus on solving the main problem than reinvent the wheel. Just use C++ if perf is critical which gives you all these things for free. In this day and age the reasons for using C as your main language should be almost zero.
o11c
Hm, this implementation seems allergic to passing types by value, which eliminates half of the allocations. It also makes the mistake of being mutable-first, and provides some fundamentally-inefficient operations.

The main mistake that this makes in common with most string implementations make is to only provide a single type, rather than a series of mostly-compatible types that can be used generically in common contexts, but which differ in ways that sometimes matter. Ownership, lifetime, representation, etc.

zahlman
> It also makes the mistake of being mutable-first

Is mutability not part of the point of having a string buffer? Wouldn't the corresponding immutable type just be a string?

[deleted]
(comment deleted)
gblargg
It's odd how it has error reporting in some areas (alloc, split can return NULL if allocation fails), but not others (append, prepend have a void return type but might require allocation internally).
burnt-resistor
It can be refactored into creating a buffer primitive of void* buf, size_t capacity, size_t refcount. Then, the string can implement using CoW logic on a buffer and size_t length. Read-only references to substrings become cheap and copying is done whenever there's a modification or realloc can't grow the underlying buffer.
p0w3n3d
By the way, I have no power here, but you people are ubiquitous, at least one of you is in C committee.

Hereby I propose an addition to C:

  namespace something { }
Which is preprocessing to something_ before every function

  class someclass { }
Which is preprocessing all the functions inside to

  someclass_fn1(someclass\* asfirstparameter, ...)
And of course the final syntax sugar

  cl\* c;
  c->fn1(a,b)
I mean this would make C much easier, as we already code object oriented in it, but the amount of preprocessing, unreadability that needs to be done in headers is simply brain exhausting
masfoobar
????

Unfortunately, you will need to cover more ground with this proposal than what you have presented. It sounds simple but what you are suggesting is very complicated. Of course, to the OOP minds out there, they think their suggestion is a be-all-to-end-all, when in reality there are many ways to solve a problem.

I understand what you are trying to do. I am not suggesting it is wrong but C is not an OOP language. I dont see why we should PRETEND that it has OOP-class features when its all you advocating is smoke and mirrors.

Sure, C can do "OOP" but I must remind all that these techniques have been in C for years, before the OOP name was popularised and evolved into the form it is now. You are just forcing C programmers to program in such a way OOPLOVERS like when it is not required - and that is the modern OOP than has been forced on everything since the early-to-mid 90's.

You are just HIDING whats really going on

This proposal you are suggesting -- I am going to call this Typescript-C.

The problem is that this namespace/class overlay makes much ASSUMPTIONS what the programmer wants. Lets dig into this further. Here is how (I believe) you see it implemented :-

  // In my TypeScript-C.
  namespace Foo {

    class Bar {

      int baz;

      void init() {
        this->baz = 10;
      }

      void free() {
        // whatever
      }

      int process(int withval) {
        return withval + this->baz;
      }
    }
  }

  // calling example :-
  Foo.Bar sample;
  sample->init();
  printf("%d\n", sample->process(100));
  sample->free();
This would translate to :-

  // Translated C...
  typedef struct Foo_Bar {
    int baz;
  }

  void Foo_Bar_init(Foo_Bar *self) {
    self->baz = 10;
  }

  void Foo_Bar_free(Foo_Bar *self) {
    // whatever
  }

  int Foo_bar_process(Foo_Bar \*self, int withval) {
    return withval + self->baz;
  }

  // calling example :-
  Foo_Bar sample;
  Foo_Bar_init(&sample);
  printf("%d\n", Foo_Bar_process(&sample, 100));
  Foo_Bar_free();
My argument is, for starters, how is writing all this namespace and class wrapper actually better than the final code? Anyone that starts using C with namespaces and classes are going to assume we have inheritence, overrides, etc. Why?

If anyone is THAT bad they cannot write proper C code, then I suggest they move to C++, Java, C#, Dlang.. or whatever.

Its just adding extra fluff -- and C guys like to SEE what is going on. (Thats why it takes ages to truly grasp C++ internals)

p0w3n3d
I'm thinking golang style OOP - basically structs with syntactic sugar of dot-calling. Nothing more. We wouldn't want full blown vtable C++ style inheritance with polymorphism, operator overloading etc. because this would create another C++ (D++ maybe? ;)

However while we're looking at any library, GTK for example, those structs are made like that. But you're right - this only looks simple, as there are many pitfalls we could hit when implementing it.

kazinator
There is a way for this not to terminate:

  while (new_capacity < required) {
    new_capacity *= 2;
  }
1. All variables are unsigned (due to being size_t). So we don't worry about overflow UB.

2. new_capacity * 2 always produces an even number, whether truncating or not.

3. Supppose required is SIZE_MAX, the highest value of size_t; note that this is an odd number.

4. Therefore new_capacity * 2 is always < required; loop does not terminate.

teo_zero
What I don't like is that some functions take as arguments a mix of StringBuffer's and regular C strings. This is confusing. For example why this:

  void StringBuffer_replace(StringBuffer *buf,
    const char *original,
    const char *update,
    size_t from);
instead of this:

  void StringBuffer_replace(StringBuffer *buf,
    const StringBuffer *original,
    const StringBuffer *update,
    size_t from);