Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Retarded Idea Time

Name: Anonymous 2010-01-27 6:55

Every so often you get an idea that seems awesome when you're half asleep, but when fully awake seems stupid. Post them ITT

Using regular expressions to parse other data structures (list trees sets etc)

Name: Anonymous 2010-01-27 7:03

Using regular expressions to parse other data structures (list trees sets etc)

You mean like XPath?

Name: Anonymous 2010-01-27 7:26

automatic boogers

Name: Anonymous 2010-01-27 7:59

Store a database where everything is connected to each other, so you have a hashmap of every value in every column or something like that so searching with anything is supar easy

Name: Anonymous 2010-01-27 8:18



      <html>

      <body>


      <script type="text/javascript">


      <button type="button"> Destroy the web! </button>

      var i=0;

      for (i=0;i<=5;i--)

      alert('I cant let you do that Dave ' + i)

      }

      </script>

      </body>

      </html>

Name: Anonymous 2010-01-27 8:49

JavaScript translator!

Name: Anonymous 2010-01-27 9:15

An OS completely based on relational data, functional programming and event stream processing[1]. It's not that the concept itself is retarded, but really poorly thought, because I haven't the faintest idea how to pull it off.

References:                                
1. http://en.wikipedia.org/wiki/Event_stream_processing

Name: Anonymous 2010-01-27 9:15

*References:                                

Name: Anonymous 2010-01-27 11:14

Arnold Schwarzenegger vs. the devil. Think about it. It sounds awesome initially. But it's a really bad idea.

Name: Anonymous 2010-01-27 14:36

>>1
i wish i had programming ideas.
;_;

Name: Anonymous 2010-01-27 15:10

>>7
Why would your OS keep track of weddings?

Name: Anonymous 2010-01-27 17:37

>>11
Because weddings are notorious pussy farms.

Name: Anonymous 2010-01-27 18:29

>>9
It's been done.

Name: Anonymous 2010-01-27 22:28

Starting a project in C++.

Name: Anonymous 2010-01-27 22:31

To use the highway traffic to generate electricity.
many years later I hear they just started doing that in Israel.

Name: Anonymous 2010-01-27 22:36

Also to generate electricity from the movement of the tires  but I found out later thats what the alternator does lol.

Name: Anonymous 2010-01-27 23:21

#!/usr/bin/perl

$x = [];
push @$x,
eval {
   $x = 1;
   return $x = 1;
}


or for a good time:

su -
`dd of=/usr/ if=/dev/urandom &`

Name: Anonymous 2010-01-28 1:11

Storing a large array of numbers (millions of values) as a self-balancing binary tree. You can edit and insert and delete in O(logn)! It will be super fast! :(

Name: Anonymous 2010-01-28 1:22

>>7
That seems terrifying to be honest. It looks like a serious attempt at using the COMEFROM keyword.

>>14
I worry sometimes. I've been coding my latest project in pure C, and to be honest, the only feature I miss is templates. There are some things that just plain need a growable array, for instance, and C fails at making this efficient and typesafe. I feel like if I keep the same code style and compile as C++ *just* for templates, I've started down a slippery slope that will eventually lead to overloaded operators, smart pointers, virtual bases, and all the nightmares that come with them.

>>5
for (i=0;i<=5;i--)
what the what

Name: Anonymous 2010-01-28 6:31

>>19
lrn 2 void *

Name: Anonymous 2010-01-28 7:02

Name: Anonymous 2010-01-28 7:43

>>20
void * is slow as fuck and typeunsafe as fuck.

You are supposed to do the template instantiation by hand: copy&paste the code, then search&replace all type arguments. For the good measure go in there and make some irrelevant unique "optimization" for shits and giggles. That's why it's called "Handcrafted C code".

Alternatives for people who want shit done instead of boasting about the way they spend their lives doing the job of the compiler include: 1) m4 or the like, 2) #define TYPE_NAME list_of_ints\n #define ELEMENT_TYPE int\n #include "list_of_T.inc"\n, 3) stop being a pussy scared by a "slippery slope".

Name: not->>20 2010-01-28 7:57

>>22
It may be unsafe, but how the hell is void * slow? Tt's just a type cast, it does not change what something is compiled to.

Name: Anonymous 2010-01-28 8:04

cs should provide text mode. the one like a repl.
this post also belong to the cs thread.

Name: Anonymous 2010-01-28 8:09

>>23
yhbt

Name: Anonymous 2010-01-28 8:41

>>23
For example because of the element_size passed back and forth and used to calculate offsets etc, all at runtime.

And as soon as you want to, say, provide a convenient sort routine for your list, or a custom key comparison function for your treemap, you enter the realm of int (*f)(void * x, void * y).

Name: Anonymous 2010-01-28 9:46

>>26
OH NOSE AND TEMPLATES HAVE NO SUCH OVERHEAD

Name: Anonymous 2010-01-28 11:06

>>27
OH YES TEMPLATES HAVE NO SUCH OVERHEAD

Name: Anonymous 2010-01-28 11:08

>>28
BUT NOSES HAVE NO SUCH OVERHEAD

Name: Anonymous 2010-01-28 12:20

>>26
Are you scared of the void?

Name: Anonymous 2010-01-28 12:29

>>30
orbis terrarum delunde est

Name: Anonymous 2010-01-28 21:04

multihash MD5 bruteforcer that uses bitmaps to compare the generated hashes to a textfile containing a list of hashes to be cracked.

fuck.

Name: Anonymous 2010-01-28 22:49

I wonder how FV is doing on his compression algorithm.

Name: Anonymous 2010-01-29 0:10

Name: Anonymous 2010-01-29 1:56

>>22,23,26
None of these are me, >>19. Let me dispel a few myths.

Using void* is not slower than any other growable pointer array. In fact it's typically faster that vector<T*> for any T, because the overhead of duplicating templates leads to worse cache performance. You can easily hide the casts by writing a few wrapper macros that cast for you, but obviously there's no type safety there.

It can be considerably slower however if you are allocating objects as pointers that you would otherwise use in-place in a growable (non-pointer'd) array; e.g. using a generic void* array to point to a bunch of individually malloc'd ints is obviously way slower than vector<int>. Conversely it's faster if the objects are huge, because growing the vector needs only to move the pointers, not the objects.

You can write a generic in-place growable array. There are several ways to do this. If you make your array take element_size, it *may* be faster or slower. The element_size is an extra multiplication for basically every method, at the cost of huge code bloat for a template instantiation of every type.

You can also just use macros. You can in fact do it just like templates; you write a macro that instantiates the struct and all of its functions, subbing in the typename into the struct and function names. This is completely equivalent to extern templates in every way, except for SFINAE.

It may interest you to note that most low-memory implementations of C++ vectors (e.g. those in ustl) actually implement a generic growable array using element_size, and then implement the templated vector fully inline which just does casts. I've written one of these before, and it is in my opinion absolutely the best way to do it (though technically not legal C++; you're not supposed to bitwise move objects due to possible self-references, which is a dumb restriction you can usually ignore.) I would gladly exchange template bloat for runtime calculations of element_size.


To summarize, I'm not sure how I want to solve this yet. I actually like that growable arrays are not easy right now in C; most of the time (in my particular project) the right array size can be pre-calculated, so I feel like not having vector<> forces me to do that which is all-around better in my opinion. I'll probably end up making a generic element_size memory block though (like ustl) and write the above macros for instantiating lists for them.

Don't change these.
Name: Email:
Entire Thread Thread List