Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - RetroX

Announcements / Re: New Interests
« on: April 01, 2010, 06:41:50 PM »
Java and C# are incredibly inefficient garbage collectors.  You should try Lisp; it's loads better at that.

Tips, Tutorials, Examples / Re: Which should I use?
« on: March 31, 2010, 07:36:19 PM »
size_t is not defined to be the size of a pointer. size_t is only defined to be the type returned by sizeof. C doesn't define intersections between pointers and integers
Sorry; what I meant is that on 32-bit systems, size_t is 32-bit (4 bytes), and pointers are also 32-bit (4 bytes).  It's 8 bytes for 64-bit systems.

Same size as a pointer.

Announcements / Re: Hello
« on: March 31, 2010, 07:33:07 PM »

this is amazing

Tips, Tutorials, Examples / Re: Which should I use?
« on: March 30, 2010, 09:12:08 PM »
Just a random thing to mention: add a space between the items in the array.

Also, although people don't seem to realize it, references/pointers use memory, too (4 or 8 bytes, depending on whether or not the system is 32-bit or 64-bit).  However, considering how an integer is already 32 bytes, and you're using a 2-dimensional array, using a pointer make more sense.  Any array can be assumed as a pointer, and vis versa.  Additonally, this is just me, personally, but unsigned integers should be used in unsigned cases.  size_t is the same size as a pointer, and an unsigned integer, and it's what you want to use for arrays and such.

This is ideal:
Code: [Select]
void print_array(int **array, int width, int height)
  for (size_t i=0;i<width;i++)
    for (size_t j=0;j<height;j++)
      std::cout << (i>0 && j>0 ? " " : "") << array[i][j];
    std::cout << std::endl;

ALLCAPS BOARD / joke is dead
« on: March 27, 2010, 10:34:01 PM »
you're not funny

Proposals / Idea for var
« on: March 27, 2010, 10:10:56 PM »
This is an idea that I had a while ago, and I'm assuming that it will be a lot faster than var:
types.hpp (has a lot of stuff that is not required for the above)

Unsigned char and char are treated as separate types to dictate which should be displayed as a character and which should be displayed as a number.

I use types.hpp for a lot, which is why it has loads of comments (mixed.hpp would have the same thing but I'm lazy right now).  I just made mixed.hpp in about ten minutes.

tl;dr for the code: it stores void *value and uint8_t type, the void pointer storing the value of the type, and the integer to decide which type that it is, as opposed to creating a separate value for double and string within a structure and returning whichever one depending on which is requested.

Off-Topic / Re: ACTA
« on: March 27, 2010, 08:20:59 PM »
Yeah, because all governments want to do is restrict freedom. Piracy is just an excuse.
but not the US because we are AMERICAN

Off-Topic / Re: Longcat
« on: March 27, 2010, 12:55:15 PM »
GNU says: "My cat is bigger than your cat"

Proposals / Re: execute_string via Google V8
« on: March 27, 2010, 08:56:27 AM »
Yes, but that isn't how GM does it.  If you're aiming for compatibility, you can't require pointers for execute_string.

Proposals / Re: execute_string via Google V8
« on: March 27, 2010, 08:42:35 AM »
int x,y=5;

How would this work, then

Also, as long as an execute_string is constant, the execute_string part should just be removed and compiled for speed.

Announcements / Re: Collisions
« on: March 27, 2010, 08:30:32 AM »
It's called parsing. You parse the fold into multiple calls. Get it? Because you parse it. Also inlining makes it nice. But you don't parse for that
Yes, I asked josh about it earlier and found that out.

Personally, I think that it would be easier to just make a function with cstdarg and take-in a number of arguments and then count the arguments and put it in with the parser.  That would also solve the problem of mean(). (of course, choose() could be parsed like min() and max(), I guess)

Announcements / Re: Summary
« on: March 26, 2010, 10:04:43 PM »
Car is significantly easier to type than engine...
I like car.  The car in car is fast and I love how wonderfully fast that car is.

Too bad that there are so many variations of car that it's difficult to decide the balance between which car is the best.

Announcements / Re: Summary
« on: March 26, 2010, 09:37:24 PM »
seriously guys? are we really gunna argue over this?
wer gunna

No, really, it's annoying.  You don't name your car "engine," yet calling GNU/Linux is essentially doing just that.  People don't seem to understand that aspect of it.  Not to mention that ChromeOS uses Linux, but it is not GNU/Linux.

Either way, I suppose that I'll drop it, because I'm obviously changing nobody's opinion.

Announcements / Re: Summary
« on: March 26, 2010, 08:45:44 PM »
Retro, it's not a requirement. You can choose either term, and no one's yet 'proved' you have to use one over the other.
People think that tomatoes are a vegetable but they're really a fruit.

Does the fact that most people say the first make it correct?

Off-Topic / Re: Cat
« on: March 26, 2010, 08:41:32 PM »
...the fact that it's insanely large, so, comments.

Also, cat is 44024 bytes large.