Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Siquo]

But... killing puppies is a good thing!

Anyway, you can just use a static or singleton and then pretend you're not using globals. Even though it's generally the same thing.

[Skyrunner]

Hmm... well, I use a single global struct to handle all the passing of data to other classes in my project, because I'm too lazy to make a "better" implementation.


I have another peculiar problem. It's involving the debug vs release build modes of Visual Studio. Debug mode works fine, but it's dependent on DLLs like msvcr100d.dll which only come with Visual Studio, not with the C++ redistributable. Also, from a quick google search, it says Debug mode doesn't optimize code.
On the other hand, Release mode throws a ton of errors. D:

Code: [Select]

1>Baseclass.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall TCODConsole::putChar(int,int,int,enum TCOD_bkgnd_flag_t)" (__imp_?putChar@TCODConsole@@QAEXHHHW4TCOD_bkgnd_flag_t@@@Z)
1>Baseclass.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall TCODConsole::setCharForeground(int,int,class TCODColor const &)" (__imp_?setCharForeground@TCODConsole@@QAEXHHABVTCODColor@@@Z)
1>Baseclass.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall TCODConsole::setCharBackground(int,int,class TCODColor const &,enum TCOD_bkgnd_flag_t)" (__imp_?setCharBackground@TCODConsole@@QAEXHHABVTCODColor@@W4TCOD_bkgnd_flag_t@@@Z)
1>Engine.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl TCODConsole::blit(class TCODConsole const *,int,int,int,int,class TCODConsole *,int,int,float,float)" (__imp_?blit@TCODConsole@@SAXPBV1@HHHHPAV1@HHMM@Z)
1>Engine.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall TCODConsole::clear(void)" (__imp_?clear@TCODConsole@@QAEXXZ)
1>PODS.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall TCODConsole::~TCODConsole(void)" (__imp_??1TCODConsole@@UAE@XZ)
1>PODS.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TCODConsole::TCODConsole(int,int)" (__imp_??0TCODConsole@@QAE@HH@Z)
1>PODS.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall TCODConsole::setDefaultBackground(class TCODColor)" (__imp_?setDefaultBackground@TCODConsole@@QAEXVTCODColor@@@Z)
1>PODS.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static class TCODColor const TCODColor::black" (__imp_?black@TCODColor@@2V1@B)
1>PODS.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static class TCODColor const TCODColor::yellow" (__imp_?yellow@TCODColor@@2V1@B)
1>PODS.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TCODColor::TCODColor(int,int,int)" (__imp_??0TCODColor@@QAE@HHH@Z)
1>PODS.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall TCODColor::TCODColor(void)" (__imp_??0TCODColor@@QAE@XZ)
1>TCODEngine.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl TCODConsole::flush(void)" (__imp_?flush@TCODConsole@@SAXXZ)
1>TCODEngine.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl TCODConsole::setCustomFont(char const *,int,int,int)" (__imp_?setCustomFont@TCODConsole@@SAXPBDHHH@Z)
1>TCODEngine.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl TCODConsole::initRoot(int,int,char const *,bool,enum TCOD_renderer_t)" (__imp_?initRoot@TCODConsole@@SAXHHPBD_NW4TCOD_renderer_t@@@Z)
1>TCODEngine.obj : error LNK2001: unresolved external symbol _SDL_PollEvent
1>TCODEngine.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl TCODSystem::setFps(int)" (__imp_?setFps@TCODSystem@@SAXH@Z)
1>TCODEngine.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static class TCODConsole * TCODConsole::root" (__imp_?root@TCODConsole@@2PAV1@A)
1>TCODEngine.obj : error LNK2001: unresolved external symbol _SDL_Quit
1>MSVCRT.lib(crtexe.obj) : error LNK2001: unresolved external symbol _main
1>C:\Users\Administrator\Documents\Visual Studio 2010\Projects\ASCII sandbox\Release\ASCII sandbox.exe : fatal error LNK1120: 20 unresolved externals
I can only make out gibberish Dx Any help?

Or ways to make a build that optimizes code and isn't dependent on debug libraries like the above-mentioned -d suffixed dll?

If not optimization, at least not being dependent.
I'm using libtcod and SDL, btw.

[MorleyDev]

I tend to favour a service layer with dependencies to services injected at construction. Really useful way of handling dependencies in a none-global reusable manner. Not perfect but very flexible.

Also much easier to test and TDD if you care about that.

[alway]

I have another peculiar problem. It's involving the debug vs release build modes of Visual Studio. Debug mode works fine, but it's dependent on DLLs like msvcr100d.dll which only come with Visual Studio, not with the C++ redistributable. Also, from a quick google search, it says Debug mode doesn't optimize code.
On the other hand, Release mode throws a ton of errors. D:

I'm using libtcod and SDL, btw.

Check through your project properties for release mode. Often times the libraries/other options won't carry over from the debug setting to the release setting. Change the configuration you are viewing from the dropdown menu in the upper-left, then go through and check for the libraries you are using. By the looks of it, libtcod isn't being linked correctly.

[Skyrunner]

Ahhhhh. Excellent, thanks!

_{^{Also, sorry for clogging up the thread with all my questions Dx}}

[GalenEvil]

But... Skyru! This is a Q&A thread of sorts all questions are good questions >.>

[GlyphGryph]

Here's a question - what's a good way to approach classes and object handling in js?

I've seen several different approaches, and I'm honestly not sure which to use (or even under which situation, if there are different reasons to use them).

Right now I'm going with a sort of factory-based structure, I guess? So I get:

Code: [Select]

function myClass(Thing){
  Thing.stuff = 4;
  Thing.method = function(){ return (Thing.stuff + Thing.value) };
 
  return Thing;
}

var myObject = myClass({value: 9});
myObject.method()  // Should return 13
But for all I know this is an absolute stupid way to handle this stuff. And the inheritance handling they it be pretty primitive for that approach. Any suggestions here on a better approach?

My javascript up until this point has mainly been logic and view manipulation, and mostly working through jQuery - this is the first time I've really messed with the structural components.

[Nadaka]

The best thing to do is to embrace the js prototyping object oriented approach.

[da_nang]

Care to extrapolate on "approaching" classes? If you mean designing them, there's UML. Use class diagrams, state charts and be clever with design patterns where suitable (but don't go nuts with them).
Abstraction and modularity are your friends, or so I've been told. If an attribute of a class can't be defined as a primitive data type or string, then it's probably better to give it its own class.

[Siquo]

This should work, right? I'm getting some weird different numbers if I try it, though

Spoiler (click to show/hide)

Code: [Select]

struct NPoint {
  NPoint(double x, double y): x(x),y(y){}
  double x;
  double y;
};

std::vector<NPoint> edgepoints;
// <snip> then I fill the list, reading it out: all okay
double* pointlist = (double*)&edgepoints;

for(int i = 0;i<edgepoints.size();i++){
  std::cout<<" "<<pointlist[i]; // weird stuff printing here.
}

Edit: DOH, of course &vector doesn't work, it's a wrapper. I needed vector.data() for the pointer...

[GlyphGryph]

Care to extrapolate on "approaching" classes? If you mean designing them, there's UML. Use class diagrams, state charts and be clever with design patterns where suitable (but don't go nuts with them).
Abstraction and modularity are your friends, or so I've been told. If an attribute of a class can't be defined as a primitive data type or string, then it's probably better to give it its own class.

No, no, I'm good enough at all that abstract stuff, I'm just concerned about actual literal implementation. Javascript doesn't actually have classes (no class, whatsoever) - you need need to sort of build your own class system to program that way. It's all object inheritence, so "classes" end up being factories or something, there's multiple ways to implement it.

It's kind of like Ruby in that way (Ruby also doesn't have actual classes), but ruby does a much better job of pretending.

I'm actually a fairly good programmer when it comes to general structure and flow, but I fall down hard on things like syntax and language-level details. And terminology, I'm bad at that too.

[Nadaka]

prototyping is merely a different way of approaching OOP without classes. You don't need to reinvent classes in js.

[GlyphGryph]

At least I've finally figured out that it is, in fact, different from capital P "Prototype", which is awful, and was causing me to filter out any blurbs about prototype mentally.

But what is the actual advantage of the prototype approach as opposed to simply using a function to define them? Just smaller objects?

I'm assuming there's more to prototype stuff than what I've read so far, though, something to differentiate it more than that.

[Nadaka]

With prototyping, you can change the prototype definition and it can update all objects with that prototype. It also means that until an objects inherited member is modified, it exists with the prototype default value and doesn't actually consume any memory.

[GlyphGryph]

Care to expound on the use of the first bit? I'm not saying the cases where that ability would come in useful.

The performance abilities of the second might not be terribly important on my current project, but never hurt really.