Jump to content

  • Log In with Google      Sign In   
  • Create Account


Ryan_001

Member Since 23 Apr 2003
Online Last Active Today, 08:15 PM
-----

Topics I've Started

C++ std::move() vs std::memcpy()

20 April 2014 - 11:02 AM

I was working on a vector-like container, and while writing a resize() function came across an interesting question.

 

When moving an object between locations, when would std::move() not give the same results as simply a std::memcpy()?

 

There were only two situations that I could think of.  One was when the move constructor (or assignment operator) was intentionally used to do something strange (ie. not actually move).  The other that when using std::move() the src object could (in theory) be reused, or at the very least has to be destroyed, where-as with the std::memcpy() neither applies.

 

But in every other case I could think of (pointers, handles, reference counting) simply copying the bits should have the same result as calling std::move().?


Component Entity and Data-Orientated Design

17 April 2014 - 10:00 AM

I have some spare time and have decided to play around with Component-Entity solutions.  One of the main 'advantages' that is often touted is the ability to organize data in a cache friendly manner by grouping components of similar type in the same block of contiguous memory.  The oft used example being processing the 'position' component of an entity.  
 
Thing is most usable systems will require multiple components.  A rendering system will require not just the position component, but facing, perhaps size/scaling, a model component, perhaps a shader component, and a host of others.  Likewise a physics system will require position, facing, velocity, momentum, and another half dozen components.  When working with many entities, all with varying number of components, there's no way a given entities components will fall in a nice order.  I can't see how cache coherency can be maintained in any but the simplest of scenarios.
 
Any ideas how memory management of a CE system should be approached in a real program?

MS Access question

14 March 2014 - 02:34 PM

I'm not sure if this is the right spot for this question, but the Access forums I've found online have been pretty poor, and you guys seem to be a pretty knowledgeable bunch, so I thought I'd ask here : )

 

I'm helping a family member with a database that's already been made in Access 2010.  I'm attempting to add data to TableA from another TableB, but I need to be able to show a 'Are you sure you wish to save changes' type dialog.  So I need to know if there are any differences between TableA and TableB.  The approach I was taking was to compare Count(TableA), Count(TableB), Count(TableA intersect TableB).  If all 3 counts were equal then no update has to be made, otherwise I have to perform an update.  I tried a bunch of different queries with varying success rates.

 

The main problem I have bumped into is that in some circumstances identical rows do not compare equal.  I've taken a table and copied/pasted it with nothing changed and then performed the intersection on the 2 seemingly identical tables, and some (but not all) of the rows do not compare equal to their counterpart.  I've inspected the tables visually, and as far as I can see nothing that was changed on the copy/paste.  Now I didn't just copy the rows, but I copied/pasted the full tables in design mode, structure/layout and data, to ensure that they were identical.

 

So this has left me rather stumped.  I'm admittedly an access 'noob' (the majority of my programming experiencing being with in C/C++), so perhaps I'm missing something.  Chances are this is not the 'optimal' why to do things, and by all means if you know of alternate methods I'm all ears, but that said I am helping a family member (ie. this is not my project) and hence they might not be conducent to large changes.

 

My rather noob-ish attempt at an intersection SQL query is here:

SELECT a.*
FROM TableA AS a, TableB AS b
WHERE (
a.[Staff Member]=b.[Staff Member] AND
a.[Day ID]=b.[Day ID] AND
a.[Shift Date]=b.[Shift Date] AND
a.[Start Time]=b.[Start Time] AND
a.[End Time]=b.[End Time] AND
a.[Duration]=b.[Duration] AND
a.[Position]=b.[Position] AND
a.[Shift Status]=b.[Shift Status] AND
a.[Wage]=b.[Wage] AND
a.[Medical Review]=b.[Medical Review] AND
a.[Comments]=b.[Comments]);

std::initializer list as array

23 January 2014 - 04:29 AM

Was cleaning up some older code and wanted to add an initializer_list to a simple wrapper class.  The data from the list is to be passed to an API function that accepts a pointer and length.

 

I was thinking of doing something like:

SetFloatArray(&*list.begin(),list.size());

Is this 'kosher'?  I'd like to avoid having to create a temporary store to copy the data.

 

Or perhaps just:

SetFloatArray(list.begin(),list.size());

would work?  http://en.cppreference.com/w/cpp/utility/initializer_list states that the iterator type is a pointer.


.fx syntax and/or tutorial

31 December 2013 - 11:56 AM

I'd like to better understand effect (.fx) files.  Up to know I've used individual shader functions in .hlsl files, but being able to group multiple functions, and shader state in a single file is something I'd like to do.  Unfortunately even after Google-ing around for a few hours I cannot seem to get any relevant info on them.  I've downloaded a number of different examples but they all seem to use different syntax.  For example some use:

VertexShader = compile vs_5_0 vertex_shader();

while others use:

SetVertexShader( CompileShader(vs_5_0,vertex_shader()) );

What's the difference?  What shader state can I set?  What are the types?  Is it better to use global variables or constant buffers?  Ect...

 

I can't seem to find a good tutorial or examples.  Even the samples I could find on MSDN were sparse at best.  I don't need info on how to compile or run the .fx files (thats all well documented) but rather what additional features/types/states/ect... do .fx files have that isn't found in normal hlsl files?


PARTNERS