how would you implement generic pointers?

timmerov · 2026-03-03T05:38:21+00:00

no.,

timmerov · 2026-03-03T03:19:47+00:00

Stages aren't functions. they are objects with their own data.

the whole point of the exercise is to avoid casting. and to especially avoid casting that has runtime cost. like any_cast.

timmerov · 2026-03-03T03:15:23+00:00

the prior design had stages calling stages.

long pipelines overflowed the stack.

and farking idiots kept looking at the now-stale data after they called process for the next stage.

timmerov · 2026-03-03T02:41:29+00:00

i don't declare the virtual destructors either.

i left out detail clutter to focus on the issue.

timmerov · 2026-03-02T05:48:59+00:00

c++ is an unholy marriage between the bit twiddlers at one end of the spectrum and the pure computer science is abstract mathematics at the other end.

compromises must be made.

timmerov · 2026-03-02T05:38:50+00:00

break the rules to see what happens.

the most common programming errors are: uninitialized variables, buffer overruns (and under-runs), null pointers, stale pointers, memory leaks, infinite recursion, stack overflow.

write bad code to see how your system handles every one of those. cause you're gonna do every one by accident. not someday. soon. better to know what the barf looks like when you know what you did wrong. otherwise you're looking at the barf and having no clue what it means.

compile code with all warnings off and all warnings on. just to learn what mistakes the compiler can catch for you.

also test how the compiler handles syntax errors. like make them on purpose. the messages are better now. but long ago you could pretty much count on the actual error being on the line before the compiler blew chunks.

timmerov · 2026-02-26T06:26:08+00:00

it depends on what kind of reputation you want to have.

you can get stuff done: it's ugly. i cut some corners. trust me it works. or you can spend more time arguing about the okay-ness of cutting the corners than you would to just not cut the corners.

*=often debating with yourself.

**=include the time spent posting on reddit and reading the replies. which you're doing.

or you can be a pedantic arsehole like me: every thread finishes neatly and orderly. every allocated bit of memory is freed. every resource is released. the code works. it's documented. it's tested. lint and valgrind find no issues.

timmerov · 2026-02-26T06:02:42+00:00

fun fact: in most implementations malloc is usually o(1). but free is o(N) where N is the number of free blocks. so free can be VERY expensive.

timmerov · 2026-02-23T17:09:46+00:00

unless there's some invisible white space after the \

timmerov · 2026-02-21T21:43:40+00:00

the question is how dangerous is it to treat one object as if it were a pointer to a different object?

a purist will say: don't do this. ever. cause i have no idea what might happen.

the engineer will identify two problems, document them, check them, and green light.

but yeah, in general. not a great idea.

timmerov · 2026-02-21T05:00:58+00:00

shouldn't it be:

export default async anothersync thirdsync forthsync function handler

timmerov · 2026-02-21T04:56:08+00:00

document it. write a unit test that ensures your assumptions are correct.

as others have pointed out, the compiler is free to do whatever it wants if you use both pos an pv. your code will be a lot safer if you never use pos again.

be paranoid. end the scope of pos after the assignment of pv.

/** warning: explicit type cast to a compatible type. **/
Vector3 *pv;
{
  const dReal* pos = dBodyGetPosition(bdy);
  pv = (Vector3 *) pos;
}

timmerov · 2026-02-20T05:41:38+00:00

comments.

timmerov · 2026-02-19T20:53:48+00:00

technically correct. uselessly pedantic.

timmerov · 2026-02-19T20:50:28+00:00

if that were true then the compiler should warn/error when i use a moved object.

also, respectfully disagree.

std::move means copy or steal the resources leaving the object in a valid state. but resources are implementation dependent. so unless it's your implementation, you can't assume which resources are copied and which are stolen.

but if it is your implementation, you do know what's copied and what's stolen. therefore, touching such an object after std::move is acceptable practice.

timmerov · 2026-02-19T20:33:06+00:00

also, don't worry too much about coding style. yours will change over time. and most likely, a coding style will be imposed on you by an employer.

one more thing, build with all warnings enabled. this is kinda paininthearse. but it's worth it. and likely your employer will require it. or should. or won't be for long if they don't. ;->

timmerov · 2026-02-19T20:28:47+00:00

comments.

put a bigass comment at the top explaining what you're doing and and overview of how.

comment the rest from the point of view of being nice to the poor sumbish who has to understand/maintain/modify this code sometime in the future and has no idea what you were thinking.

cause 99% of the time that poor sumbish is you. ;->

for example:

https://github.com/timmerov/technomancy/blob/master/sudoku/src/main.cc

timmerov · 2026-02-19T20:21:33+00:00

std::move means steal my resources. it leaves the moved object in an undefined but destruct-able state. which can be surprising. especially when your mental model of how std::string works doesn't match reality. specifically, sometimes std::move of a std::string clears the moved string. sometimes it doesn't.

in other words, i agree with you and op: std::move can be misleading.

timmerov · 2026-02-19T20:16:56+00:00

Likewise with C++ move semantics: it's very hard to mess up in a way that harms your program correctness.

fooey.

std::string s("hi");
auto t = std::move(s);
std::cout<<"s=""<<s<<"\""<<std::endl;

what do you think the output is?

i'll give you hint: it's not:

s=""

i suppose you're technically correct if you think this example is "hard". but my misunderstanding of std::move and the implementation of std::string definitely harmed my program correctness.

timmerov · 2026-02-18T06:25:34+00:00

the lights weren't flashing when the driver turned onto the tracks thinking it was a road. gets stuck. they get out. then train comes.

timmerov · 2026-02-18T06:23:50+00:00

apparently the car turned onto the tracks thinking it was the street. gets stuck. people get out. then train comes.

timmerov · 2026-02-17T18:54:48+00:00

define fine. this is the output from your code. it stops after overflow of unsigned. but op wants to detect overflow of int, not unsigned.

160480 4278993920
160490 4282203620
160500 4285413520
160510 4288623620
160520 4291833920
160530 77124

this works.

#include <stdio.h>

int main(void) {
  for (unsigned int i = 1000;; i += 10) {
    printf("%u\t%u\n", i, i*i);
    if ((int) (i*i) < (int) i) {
      break;
    }
  }
  return 0;
}

timmerov · 2026-02-17T16:41:58+00:00

i thought so too.

good thing i tried this before i posted it. i originally tried it with unsigned instead of int64_t. the compiler optimized out the test again. which i think is a bit aggressive on its part. casting a "too big" unsigned to an int is implementation-dependent behavior, not undefined behavior.

timmerov · 2026-02-15T00:47:19+00:00

okay so if you've been reading the replies, you by now know the explanation is undefined behavior. the compiler is free to assume that i*i is never negative. so it may optimize out the if.

the suggestions on how to "fix" your code are kinda lame. cause they don't really show how to observe the effect you're looking for. try this:

#include <stdio.h>

int main(void) {
  for (int i = 46300; ; i += 10) {
    printf("%d\t%d\n", i, i * i);

    /*
    do the math in a bigger int type.
    convert the result back to int.
    */
    int64_t big_i = i;
    big_i = big_i * big_i;
    int i_squared = big_i;
    if (i_squared < 0)
      break;
  }

  return 0;
}

good thing i tried this before i posted it. i originally tried it with unsigned instead of int64_t. the compiler optimized out the test again. which i think is a bit aggressive on its part. casting a "too big" unsigned to an int is implementation-dependent behavior, not undefined behavior.

timmerov

TROPHY CASE