Jump to content

  • Log In with Google      Sign In   
  • Create Account

Bregma

Member Since 09 Dec 2005
Offline Last Active Today, 04:28 AM

#5299885 sort list

Posted by on 09 July 2016 - 09:25 AM

I get this error:
Multiple markers at this line
    - ‘test2’ was not declared in this scope
    - expected primary-expression before ‘&’

'test2' was not declared in the scope. The error message is not ambiguous. You can not just take the address of an undeclared variable like that.

What you want to do is pass the function itself, not call the function.

Ausfalllinie.sort(compare);




#5297969 Have I been aged out of the industry? And where else can I go?

Posted by on 25 June 2016 - 05:26 AM

It's not your age (you're way younger than me).  You just need to get that depression under control, nobody needs that around the workplace, and trust me, interviewers see it right away.




#5297919 Is there any reason to prefer procedural programming over OOP

Posted by on 24 June 2016 - 03:25 PM

 

He is certainly entitled to his opinion but in my opinion the standard library contains a lot of what I would consider 'modern OO for C++' (while not 'classically taught OO' which nowadays often feels to me like the 'bad OO' anyway).

Do you have any examples?  Certainly most of the container classes seem very non-OO to me.  Vectors don't know how to iterate over themselves.  Rather, the algorithms to do things with vectors are kept at arms length and divorced from the containers.  That's not in the slightest how OO designs tend to work.  In fact, it's the complete opposite.  OO is about coupling code and data.  The C++ containers are all about decoupling code and data.  Much of the standard library following the STL stuff has followed a similar pattern.

 


Howsabout <random> and <regex>? <iterator>? <functional>? <string>??? <mutex> and all the threading stuff?




#5297306 Is there any reason to prefer procedural programming over OOP

Posted by on 20 June 2016 - 06:55 AM

OOP is a way of organizing procedural programming so that you can focus your reasoning on the complex interactions between large sets of data and rules.  It's not like they're mutually exclusive, since they actually address different domains of thought.

 

The expensive part of successful software development is the time spent reasoning about things (and recovering from poor reasoning, or coming up to speed on old or someone else's reasoning).  OOP helps reduce that cost when using procedural programming.  Some procedural programming languages laud that enforce a particular way of thinking about OOP via their restrictive syntax, which is designed to make things more code-monkey friendly to reduce costs.




#5297045 Object created in one class, needs to use variables in the class it was creat...

Posted by on 17 June 2016 - 05:15 PM

Have the MainGame update itself based on state reported by the Input object?

 

Have the MainGame register callbacks on the Input object so the Input object can ask the MainGame to update itself?

 

Use a message-passing protocol to communicate state between object?




#5296213 Trivially trivial?

Posted by on 12 June 2016 - 07:23 AM

The way the standard library was designed, and I would suggest trying to fight against the way it was designed will send you on an increasingly downward spiral, is to overload std::copy() for your class.

 

You should rely on std::copy() being used in an algorithm or container, knowing that it will call std::memcpy() for trivially-copyable objects and the copy constructor/move constructor/operator=() for non-trvially copyable objects, and your override of std::copy() can just call std::memcpy() if you have an object that you know is trivially copyable but the compiler can not deduce it on its own.  Most times, the compiler will do the right thing (even if you think you know better), and making it explicit that you're overriding the default compiler behaviour by supplying a std::copy() overload documents you decision, just like using a cast.  You are after all trying to communicate to the human reader that you're doing something unexpected and that you know better in this particular case, as opposed to just telling the compiler to do something.

 

You are explicitly allowed to overload std::copy() for just that reason.  In the std:: namespace no less.  Just like the big boys.




#5293575 Do you usually prefix your classes with the letter 'C' or something e...

Posted by on 26 May 2016 - 07:21 AM

You write code for humans to read, it's a work of literature.  To that end, semantics and readability are paramount.

 

Pyou vshould pnot vprefix nwords pwith aartificial aencoded pplanguage pconstructs aany amore cthan pyou vshould vdo pso pwith ahuman nspeech.  Pit vdoes pnot venhance nreadability.




#5293192 Is there a way to change initialisation order while keeping object layout ?

Posted by on 24 May 2016 - 06:39 AM

The committee had to choose some rule for initialization order.  The chose the one that will work reliably under all situations:  with the presence of explicit initialization or without.    I suppose the could have gone with "in the order of explicit initialization except when some explicit initializers are missing in which case you fall back to member declaration order and except when there is non-virtual multiple inheritance with differing base class constructor calls and also not in plain-old-data copy constructors or any classes derived from them and, well, there is no guarantee about default copy operators ever doing the right thing any more" but my guess is they thought that might be a little more error-prone and liable to unexpected behaviour.




#5292600 My C++ gotcha of the day

Posted by on 20 May 2016 - 04:32 AM

I expected for SFINEA to eigther give some compilation error that the class was not defined at this point, but not just silently tread it as if it was an empty class the whole time.


Huh. Any idea what SFINAE stands for? It should be a clue as to why it's unreasonable to expect an error in that situation.


#5291536 What book to start from

Posted by on 14 May 2016 - 05:33 AM

The book you should start with is your netbook.  By that, I mean start writing code.  It doesn't have to be good code, it doesn't have to work perfectly, but it's gotta be code and you have to write it.

 

Passive learning from a paper book is not nearly as effective as JFDI and see what happens.  Bits are cheap, use as many as you want.




#5290397 Is it real?

Posted by on 06 May 2016 - 06:07 AM

How long would it take to make something at the scale of Dragon Age Origins, if i already have all the assets (models, audio, arts etc.) and i'm using unreal engine? How long would the coding and uniting everything part take?

About the same time as it would take to make a movie like Star Wars VII: The Force Awakens if you already have a couple dozen actors lined up, a beach ball, and a really nice prosumer DSLR camera.




#5290395 I doubt I understand RAII just yet

Posted by on 06 May 2016 - 05:55 AM

You have it backwards.

 

RAII is a technique in which the lifetime of an object is identical to the acquisition of that resource.  When the object is created, the resource is acquired, and when the object is destroyed, the resource is released.  That's it.

 

You need to keep track of the lifetime of the object (and in fact all objects), but C++ is designed with several way to do that.  That's what makes RAII so powerful and useful:  it leverages technology built into the language and widely and easily understood and uses it to do an error-prone task outside the domain of the language itself.

 

Object lifetime control is a topic independent of RAII.  You need to master that first before worrying about RAII or pretty much anything else.  Hint: avoid pointers until it's really clear you need them.  Hint: put print statements in the constructors (all of them), copy operators, and destructors of your objects to help understand object lifetimes.




#5290276 how good is rand() ?

Posted by on 05 May 2016 - 11:59 AM

>>  It also has a tendency to have very poor randomness in the least significant bits, in particular it tends to alternate odd and even numbers so dont just use % to constrain the range, try >> it a couple of bits first.

 

i basically lerp from 0 thru 32767 (inclusive)  to 1 thru N (inclusive) for an N sided die roll.  i don't use mod.  so that low order lack of randomness should not affect me, correct?

 

Correct.  With N being significantly less than 32767 (like say, a d20 or a pair of percentile dice) you should also not be affected by the striping by using a lerp function.




#5290176 how good is rand() ?

Posted by on 04 May 2016 - 07:18 PM

how good is rand()  ?

 
Truth be told, modern implementations of rand() use a linear congruential generator with well-chosen parameters so that it's got a maximal sequence length and good apparent randomness so it's more than good enough for most applications.
 
Historically, there have been some implementations with notoriously bad chosen parameters and through the miracle of internet cargo culting, it has earned a poor but undeserved reputation.
 
As someone who implemented <random> for a widely used and well-known C++ standard library, I can tell you a few things about rand() vs. the std:: random number generators available since C++03/TR1.
 
The equivalent to rand() in C++ is std::minstd_rand, a small and fast LCG.  The main difference is that rand() uses hidden global state whereas std::minstd_rand is a stateful object.  An LCG can be implemented using one single multiplication instruction and one memory word, so it's very fast and takes very little memory.  It has the disadvantage of having a harmonic characteristic, ie you plot it on a graph you sill see stripes start to appear.  It also has a tendency to have very poor randomness in the least significant bits, in particular it tends to alternate odd and even numbers so dont just use % to constrain the range, try >> it a couple of bits first.

 

A popular PRNG is the Mersenne Twister, std::mt19937.  This has the advantage of a really long sequence and really good spectral characteristics, but it takes a lot of bit manipulation operations to generate the next number in sequence (ie. it's slow) and has a memory footprint of 2.5 kilobytes per instance.  It's extreme overkill for all but the most exacting of needs.

 

In between those two alternatives are the lagged Fibonacci generators (the std::ranlux* family) which use about 72 bytes of memory and no multiplications (they're very fast) but have clustering problems and show some harmonics.

 

There are also some PRNG adaptors that improve the characteristics of the above generators at cost of increased memory and CPU usage.

 

So, how good is rand()?  Not too bad really.  I don't like its use of hidden globals, which make reproduceability difficult to impossible and the harmonic traits show up sometimes when used for things like Perlin noise generation if you look really closely or use % on a small range, but it's good enough for most applications.  I use the c++ equivalent of std::minstd_rand instead.




#5289697 Hiding Company Nationality

Posted by on 02 May 2016 - 04:30 AM

I work for a company in which most developers are distributed worldwide.  We do have a bricks-and-mortar sales and support office in the USA (and one in China) because some jurisdictions are remarkably more xenophobic, but by and large you can not identify the colour of the skin or the width of the epicanthic fold of the developer when it comes to software.






PARTNERS