The best design is the one that you don’t need to explain to the others

 

Yeah, like we need another pretentious debate about some pretentious concept de grandeur.

This one though, someone’s going prove it for good.

The ego of a computer scientist

 

is larger than the ones of all EE, Material, Telecom, Chemical, Structural and Mechanical Engineers combined.

For no bloody reason…

[c/c++] use reference variable to set values

    ExpandedVertex& beforeVec = (*m_hVecGlobalVecRef)[i];

    beforeVec.pos.x = temp_hPos[i*4] ;

    beforeVec.pos.y = temp_hPos[i*4+1];

    beforeVec.pos.z = temp_hPos[i*4+2];

    beforeVec.mass = temp_hPos[i*4+3];

    beforeVec.vel.x = temp_hVel[i*4];

    beforeVec.vel.y = temp_hVel[i*4+1];

    beforeVec.vel.z = temp_hVel[i*4+2];

    beforeVec.mass = temp_hVel[i*4+3];

[opengl] http://www.opengl.org/wiki/Vertex_Buffer_Object#Vertex_Array_Object ?

http://rauwendaal.net/2011/02/10/how-to-use-cuda-3-0s-new-graphics-interoperability-api-with-opengl/

[opengl] glGenBuffers, glBindBuffer, glBufferData

--- Nvidia ParticleSystem particleSystem.cpp ---

uint

ParticleSystem::createVBO(uint size)

{

    GLuint vbo;

    glGenBuffers(1, &vbo);

    glBindBuffer(GL_ARRAY_BUFFER, vbo);

    glBufferData(GL_ARRAY_BUFFER, size, 0, GL_DYNAMIC_DRAW);

    glBindBuffer(GL_ARRAY_BUFFER, 0);

    return vbo;

}

--- glGenBuffers()

http://stackoverflow.com/questions/12102864/assist-me-to-understand-opengl-glgenbuffers

glGenBuffers doesn't work quite like what you expect. When you call glGenBuffers, it doesn't actuallycreate anything. It just returns a list of integers that are not currently used as buffer names.

The actual 'object' is not created until you call glBindBuffer. So you can just make up any integer you like and pass it to glBindBuffer and a valid buffer will be created at that index. glGenBuffers is actually not required at all, it's just there as a convenience function to give you an unused integer.

So if you just create an array of random integers, as long as none of them overlap, you can use that as your list of buffers without calling glGenBuffers. That's why your code works whether you tell glGenBuffers to create 1 or 2 buffers. As long as you have two buffers with two different names, it doesn't matter where the integer came from.

A little demonstration:

int buf;
glGenBuffers(1, &buf);
glIsBuffer(buf); //FALSE - buffer has not been created yet
glBindBuffer(GL_ARRAY_BUFFER, buf);
glIsBuffer(buf); //TRUE - buffer created on bind

http://www.opengl.org/sdk/docs/man/xhtml/glGenBuffers.xml

--- glBufferData()

http://stackoverflow.com/a/5402762

What does glBufferData do?

glBufferData does at least two things, and optionally a third. It allocates buffer storage and lays down the usage of the buffer. Optionally, if the pointer argument is non-null, it will fill the buffer with the pointed-to data. The similar glBufferSubData differs insofar as it only updates (possibly a subrange of) data, it does not allocate storage or anything else.

http://www.opengl.org/sdk/docs/man/xhtml/glBufferData.xml

void glBufferData(	GLenum	target,
	GLsizeiptr	size,
	const GLvoid *	data,
	GLenum	usage);

Parameters

target

Specifies the target buffer object. The symbolic constant must be GL_ARRAY_BUFFER, GL_ATOMIC_COUNTER_BUFFER, GL_COPY_READ_BUFFER, GL_COPY_WRITE_BUFFER, GL_DRAW_INDIRECT_BUFFER,GL_DISPATCH_INDIRECT_BUFFER, GL_ELEMENT_ARRAY_BUFFER, GL_PIXEL_PACK_BUFFER, GL_PIXEL_UNPACK_BUFFER, GL_SHADER_STORAGE_BUFFER, GL_TEXTURE_BUFFER, GL_TRANSFORM_FEEDBACK_BUFFER, or GL_UNIFORM_BUFFER.

size

Specifies the size in bytes of the buffer object's new data store.

data

Specifies a pointer to data that will be copied into the data store for initialization, or NULL if no data is to be copied.

usage

Specifies the expected usage pattern of the data store. The symbolic constant must be GL_STREAM_DRAW, GL_STREAM_READ, GL_STREAM_COPY, GL_STATIC_DRAW, GL_STATIC_READ, GL_STATIC_COPY,GL_DYNAMIC_DRAW, GL_DYNAMIC_READ, or GL_DYNAMIC_COPY.

Description

glBufferData creates a new data store for the buffer object currently bound to target. Any pre-existing data store is deleted. The new data store is created with the specified size in bytes and usage. If data is not NULL, the data store is initialized with data from this pointer. In its initial state, the new data store is not mapped, it has a NULL mapped pointer, and its mapped access is GL_READ_WRITE.
usage is a hint to the GL implementation as to how a buffer object's data store will be accessed. This enables the GL implementation to make more intelligent decisions that may significantly impact buffer object performance. It does not, however, constrain the actual usage of the data store. 

--- glBindBuffer()

http://www.opengl.org/sdk/docs/man/xhtml/glBindBuffer.xml

void glBindBuffer(	GLenum	target,
	GLuint	buffer);

.... Buffer object names are unsigned integers. The value zero is reserved, ..., buffer set to zero effectively unbinds any buffer object previously bound, and restores client memory usage for that buffer object target (if supported for that target)...

What’s db normalization?

 

http://en.wikipedia.org/wiki/Database_normalization

Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency. Normalization usually involves dividing large tables into smaller (and less redundant) tables and defining relationships between them. The objective is to isolate data so that additions, deletions, and modifications of a field can be made in just one table and then propagated through the rest of the database via the defined relationships.

1NF
First normal form
Two versions: E.F. Codd (1970), C.J. Date (2003)
1970 ^[1] and 2003 ^[9]
Table faithfully represents a relation, primarily meaning it has at least one candidate key

2NF
Second normal form
E.F. Codd
1971 ^[2]
No non-prime attribute in the table is functionally dependent on a proper subset of any candidate key

3NF
Third normal form
Two versions: E.F. Codd (1971), C. Zaniolo (1982)
1971 ^[2] and 1982 ^[10]
Every non-prime attribute is non-transitively dependent on every candidate key in the table. The attributes that do not contribute to the description of the primary key are removed from the table. In other words, no transitive dependency is allowed.

Ways to create threads?

 

Defining Thread.run()

public class MyThread extends Thread {
  public void run(){
     System.out.println("MyThread running");
  }
}

MyThread myThread = new MyThread();
myTread.start();

 

Defining Runnable

Runnable myRunnable = new Runnable(){

  public void run(){
     System.out.println("Runnable running");
  }
}

Thread thread = new Thread(myRunnable);
thread.start();

http://tutorials.jenkov.com/java-concurrency/creating-and-starting-threads.html

[c++] gcnew and new

 

http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/a10e4f13-6167-4f1a-bba6-c6010cdf6f89

The new and gcnew operator are similar. Both allocate memory and invoke the constructor of the object. Whereas new allocates memory from a native heap and returns a pointer, gcnew will allocate memory from the GC heap and return a handle. A boxed value type is easy to recognize, as the type is simply a handle to value type. For example:

      int m = 42;             // integer on the stack
      int* n = new int(42);   // integer on a native heap
      int^ o = gcnew int(42); // boxed integer on the GC heap

There are other ways to create boxed value types, but I will leave that for another time when I discuss the implementation of boxed value types.

Why is it important to distinguish whether an instance of an object is on the GC heap or a native heap? The GC algorithm implemented by the CLR is a generational compacting garbage collector. This means that the memory location of the object can change upon each garbage collection. This does not happen on the native heap. A pointer refers to an instance in memory that never moves. The garbage collector ensures that a handle always points to the right instance.

[java] garbage collection tuning

 

http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html#ixzz2MjpjTapL

“

Garbage collection tuning is a long exercise and requires lot of profiling of application and patience to get it right. While working with High volume low latency Electronic trading system I have worked with some of the project where we need to increase the performance of Java application by profiling and finding what causing full GC and I found that Garbage collection tuning largely depends on application profile, what kind of object application has and what are there average lifetime etc. for example if an application has too many short lived object then making Eden space wide enough or larger will reduces number of minor collections. you can also control size of both young and Tenured generation using JVM parameters for example setting -XX:NewRatio=3 means that the ratio among the young and tenured generation is 1:3 , you got to be careful on sizing these generation. As making young generation larger will reduce size of tenured generation which will force Major collection to occur more frequently which pauses application thread during that duration results in degraded or reduced throughput. The parameters NewSize and MaxNewSize are used to specify the young generation size from below and above.

“

[c++] std:vector and std:deque

 

One of the most obvious distinction will be reflected by that

- if you use std:vector to store a list of element

- then try to pass the address of the element (e.g. &vec[i]) around as reference to that element, it will not work as std:vec resize and rellocate itself to somewhere else as its size changes (so that it can occupy a set of contiguous memory spaces)

- std:deque does not have this problem, but the memory space it occupies could be scattered to anywhere

[c++] Another C++ pointer problem

Particle* particlePtr = new Particle(p0);

P.push_back(*particlePtr);
BreakableSpringForce2Particle* force2Ptr1 = new BreakableSpringForce2Particle(psb.PS.getParticlePtr(currIdx-1), particlePtr, &psb.PS, SPRING_BREAK_THRESHOLD);
psb.PS.F.push_back(force2Ptr1);
BreakableSpringForce2Particle* force2Ptr2 = new BreakableSpringForce2Particle(psb.PS.getParticlePtr(i*latitude), particlePtr, &psb.PS, SPRING_BREAK_THRESHOLD);

psb.PS.F.push_back(force2Ptr2);

// when force2Ptr2 update the particle through its ‘particlePtr’, it will writes to the corresponding particle in the P deque and overrides the changes done by force2Ptr1 previously.
// as if force2Ptr1 and force2Ptr2 maintain their own copy of the particle as well as can have change propogate to the particle on the P