Recent Posts

Pages: [1] 2 3 ... 10
1
General Discussion / Re: State of progress?
« Last post by bas on July 15, 2018, 09:24:39 PM »
C2 is definitely not going as fast as I would like, but it's definitely not dead either. Work and family life does
take a big toll on available time. Luckily it's already quite usable, so people (me included) can play around
with it to get a feel and evaluate it for parts that could be improved.

Parts where C2 still needs developers:
- LLVM IR  generation
- inline assembly support
- some tooling (syntax highlighting, style formatting)
2
General Discussion / State of progress?
« Last post by lerno on July 14, 2018, 11:36:22 PM »
Is C2 really alive or is it put in suspended animation?
3
Ideas / Re: What about initialization in conditions?
« Last post by lerno on June 28, 2018, 07:19:37 PM »
Yes, but your current code does not match the C++ behaviour.
4
General Discussion / Re: Struct "inheritance"
« Last post by lerno on June 28, 2018, 07:18:29 PM »
I disagree, but it was just a suggestion.
5
Ideas / Re: What about initialization in conditions?
« Last post by bas on June 27, 2018, 09:01:32 AM »
Currently in C++ it's possible to do (using pointer now)

Code: [Select]
while (Ptr* p = getPointer()) {
  ..
}

This compiles to the exact same thing. So each iteration, p is assigned a value from a call to getPointer().
So this call could have an internal iterator state and return NULL once it's done. These type of constructions
are also used in clang itself because they lower the scope of p.

6
General Discussion / Re: Struct "inheritance"
« Last post by bas on June 27, 2018, 08:57:23 AM »
struct 'inheritance' in already possible in C by just having the other struct as (first) member.
Also, you can already have object-oriented like features by adding function pointers in a
struct (also in C). Those two cover you example already..
7
General Discussion / Re: Complex numbers
« Last post by lerno on June 25, 2018, 11:59:39 AM »
I don't know if there is a simple solution, but consider the difference between overloading and normal function calling:

Code: [Select]
// Operator overloading
result1 = matrix1 + (matrix2 - matrix3) / factor;

// Straight functions
result2 = matrix_add(matrix1, matrix_division(matrix_sub(matrix2, matrix3), factor);

Personally I dislike function overloading, but this is a special case.

Alternatively, allow free postfix function calls:

Code: [Select]
result2 = matrix1 matrix_add ((matrix2 matrix_sub matrix3) matrix_division factor);

There is one other solution though, in three steps:
  • Add built-in types "matrix", "complex", "vector", "quaternion"
  • Create default implementations of each as "matrix_add", "matrix_mult", "complex_add" etc
  • Support monkey patching functions – basically allow overwriting the default implementations with a new function replacement within a module.
8
General Discussion / Re: Struct "inheritance"
« Last post by lerno on June 25, 2018, 11:37:45 AM »
No, not only, it also allows the programmer to use MyDataExtended with every function that takes a MyData. However, there obviously is a difference, for example – let's say that we have some function foo(MyData *) that wants to take ownership of MyData... Then we obviously have some issues with using MyDataExtended, unless the ordering is such that MyData comes first.

The advantage is that it's possible to do something like inheritance without the inheritance. E.g.:

Code: [Select]
type Node struct {
   Vector2 position;
   RenderFunction *renderFunction;
}

func void Node.addChild(Node *this, Node *childNode) {
   ...
}
   
func void Node.render(Node *this, RenderState *state) {
   state->push();
   ... // update render state
   for (... all child nodes behind in z order...) {
       node->render(state);
   }
   this->renderFunction(this, state);
   for (... all child nodes after in z order...) {
       node->render(state);
   }
   state->pop();
}

type SpriteNode struct {
   Node baseNode @(inline)
   Texture *texture;
}

func void SpriteNode.init(SpriteNode *this) {
   this.renderFunction = SpriteRenderFunction;
}

//
...
Node *scene;
SpriteNode *sprite;
...
scene->addChild(sprite);
scene->render(state);

9
General Discussion / Re: Why the module restriction on struct functions?
« Last post by lerno on June 25, 2018, 11:20:51 AM »
Not allowing duplicate names is a natural restriction. Allowing function overrides (basically a form of monkey patching) is interesting but not required.
10
General Discussion / Re: Complex numbers
« Last post by bas on June 25, 2018, 09:00:29 AM »
Since C2 is a descendant of C and has no symbol-mangling, function overloading (multiple functions with same name bit with different arguments)
is not supported. I recently looked at Zig (ziglang.org) a bit and they allow putting functions on many constructs, like types, enums etc. This could
also be implemented in C2..

Code: [Select]
type Color enum u8 { Red, Green, Blue }

func bool Color.isRed(const Color* color) {
  return *color == Red
}
Pages: [1] 2 3 ... 10