Jump to content

  • Log In with Google      Sign In   
  • Create Account

BitMaster

Member Since 08 Aug 2000
Online Last Active Today, 02:34 AM

#5256847 Luabind - 'abort' when trying to call object method which contains lu...

Posted by BitMaster on 12 October 2015 - 07:29 AM

Are you absolutely certain LUABIND_NO_EXCEPTIONS is not defined? If the line is definitely reached, is it possible the error happens because something bad happens when luabind::error tries to read extra information from the Lua state? I believe the default behavior of Lua is to call exit when it needs to raise an error (see also Lua's lua_atpanic.

Additionally, if you try to throw an exception out of any function which is marked as noexcept you will get terminate called. Note that none of the things I listed actually call abort(), but it might depend on your exact compiler.

The only thing I can think of which explicitly calls abort() would be a failed assert. With a decent debugger you should be able to find the exact line where things go wrong.


#5256813 Linker errors Eugh!

Posted by BitMaster on 12 October 2015 - 02:13 AM

This dude -link below- explains in his video that the GLEW files are precompiled for visual studio and not minGW so that's why they won't work:

While static libraries compiled for one compiler are usually not compatible with libraries compiled by another compiler that is not always the case (for example gcc and clang are meant to largely inter-operate). At the same time even within the same compiler you can have incompatibilities.
The most common example is MSVC and the used runtime. Usually you will need two version of a library (one linking to the Debug and one linking to the Release runtime). Mixing them will (depending on the circumstances and version of MSVC) not work at all or cause highly subtle but ultimately fatal bugs. Apart from that MSVC allows you to chose between two different runtimes (each with a Debug and Release variant) and there are even compile flags/definitions which can make compiled incompatible.
Note that for a pure C library (like GLEW is) this would normally not matter but most prepared MSVC-packages I have seen are set up in a way that they will still cause subtle issues by pulling in the wrong standard library if mishandled.
Linking dynamically largely alleviates the problem (provided the library has properly designed pure C interface) but having to distribute possibly another runtime library just because the library was compiled in the wrong way is extremely annoying.
 

He gives links to pre-compiled files -link below- for minGW so you can get it running, how frustrating!

I would strongly recommend you get into the habit of building libraries you use yourself. First, it is extremely good practice, second at some point you be in a position where you will need to do that anyway: You might be using MSVC 2013 but the library you need to use is only available precompiled for MSVC 2008 or any other scenario. You might also need to use compile settings which are uncommon and break the ABI.
I have personally seen how wrong things can go if you rely on prebuilt files, even straight from the creators. For example I once ran into a severe trouble with pthread because of this. Despite the fact it's a pure C library the prebuilts from the official site link dynamically to the C++ runtime which is unfortunately not mentioned anywhere, nor the version. Long story short, the whole program failed in a cryptic way on some customer machines until I compiled it myself under known parameters.
 

One more issue is that if you use the pre-compiled files then they might be for a different version of windows and still cause errors. 
 
e.g.
glewGetErrorString@4 could not be located

That is highly unlikely. That probably means someone compiled the library wrong.
 

Do I need GLEW or can I just use SDL2 and run all input and sound through that? What's the difference between them as I'm not really sure why I'm wasting my time and sanity trying to get GLEW working.

You will need something like GLEW on Windows. Windows does not give you anything more than OpenGL 1.1 (which is not really enough to do anything fun and interesting) and everything else has to be queried over the extension mechanism. That is a lot of boring work. I would also advise against trying to muck around with function pointers (and all the interesting problems that can happen when you cast them to the wrong type) if dealing with library linkage already gives you so much trouble.


#5256724 Assign different functions to different structs in std::vector<>

Posted by BitMaster on 11 October 2015 - 01:22 PM

struct MyStruct
{
   std::function<void ()> func;
   MyStruct() = default;
   MyStruct(const std::function<void ()>& func):func(func) { }
};

// ...

std::vector<MyStruct> funcs;
funcs.push_back(&myBla);
funcs.push_back(&myBlub);
for (const auto& f : funcs)
   f.func();
Obviously in this simple case you would rather store the std::function<> directly inside the container instead of putting them into a pointless structure.

Edit: Stupid forum editor mangled all template parameters...


#5256167 Map/Hash a range of D3DXVECTOR3 into a grid space?

Posted by BitMaster on 08 October 2015 - 03:10 AM

The insert member function of the map types requires std::pairs because an insert only makes sense if you supply both a key and its corresponding value. In your case you need to insert std::pair<D3DXVECTOR3, cPoint*>.


#5256155 Map/Hash a range of D3DXVECTOR3 into a grid space?

Posted by BitMaster on 08 October 2015 - 12:43 AM

I am puzzled where the unordered_map should be sparsed and a range of D3DXVECTOR3 should map
into this space.
But this statement just won't work


What does not work? Does it not compile? Then what are the exact compile errors?
Does it compile but crash at runtime? What happens when you use the debugger to home in on the crash site? Where is it? What is the local state?
Does it compile and run but not do what you expect? What do you expect? What do you observe?


#5255955 Expression templates for arguments of different types

Posted by BitMaster on 07 October 2015 - 01:21 AM

I strongly advise against doing thing like this in an implicit way, it can cause some truly horribly to locate precision problems.

Make it easy for a user to convert a VectorX from one underlying scalar type to another (explicit constructor, to<newScalar>() member function) but do not do anything based on implicit conversion. If things are of different underlying types, the compiler should scream at you. When you consider the conversion justified it should be easy and simple to explicitly request it. At the same time it should be obvious from the code that such a conversion happens.


#5255774 Thoughts on the Boost.Build system? (as opposed to CMake?)

Posted by BitMaster on 06 October 2015 - 01:56 AM

I don't think I ever had that problem. Maybe you are doing something wrong?

 
Very possibly. All I know is that when I run CMake on various different projects that are not mine, I end up with loads of solution files, with extra solutions like ZERO_CHECK and so forth, and a bunch of other accompanying files and folders, all cluttering up the root directory.


The key problem is probably that you don't do a proper out of source build as JTippetts already suggested. Any build directory of a non-trivial project will be a bit of a mess. CMake has to add a bit on top of what you need there because it needs custom build steps to detect when it has to rerun itself, but compared to what a regular project already needs it's not really much. In all the IDEs I know those are placed rather unobtrusively though.
CMake makes out of source builds easy: you pick a source directory and the build directory where you want to place all generated files and the compiler does its magic (actually there is one generator which puts one extra file outside the build directory but that is only because one IDE cannot deal with it otherwise).
Personally I like to place my build directory as a 'build'-subdirectory of my source directory and set that directory to be completely ignored by source control. Others require the build directory to be completely separate (for example 'D:\projects\myproject' and 'D:\projects\myproject-build'.


#5255673 Using whitelisting to run untrusted C# code safely

Posted by BitMaster on 05 October 2015 - 10:36 AM

I have some major philosophical problems with the title, I don't see how you can run untrusted code safely in any way.
Either you trust the code and then by definition it's safe enough to run it, or you don't trust the code which means it is unsafe to run by definition. (The latter doesn't need to stop you from running it, it is mostly a slight shift towards expecting malicious behavior by default.)
 
People have been trying to keep crackers out of systems by doing anything you can imagine and a lot more you didn't yet think of, and so far, in the past 25-30 years, they failed. And that is about systems you can only access remotely, by network cable. You let code run on a CPU inside the machine itself! I believe you're just fooling yourself if you think it can be anywhere near safe if you don't trust the code.
 
If you want to make the C# code useful, you must give it some power, which means it is exploitable, even if it's just DoS-ing the local system. You can make it difficult to do harm, but in the end, a malicious person with enough motivation or knowledge cannot be stopped.


I strongly object to this line of thought. Let's look at StarCraft (the original) and Warcraft 3. A player could go online and browse for games to play with people. While both games came with premade maps, they also contained powerful map editors. When you entered a game with a map you did not have, you automatically downloaded it (as well as having a thriving ecosystem of sites where users could upload, comment and download maps). Apart from the pure map data the maps could also contain significant amount of scripts (after all, that's where the whole Defense of the Ancients concept came from: a Warcraft 3 map which ended up being popular).
That worked because the map scripts were properly sandboxed and to my knowledge there was never any exploit where the risk to a player was ever more than "it's not fun".

Granted, the OP's initial idea of using C# is probably not feasible (but I already wrote about that and talked about alternatives). Care must be taken to properly sandbox things but it has been done in the past and, especially if you only need a limited scope, it is doable.


#5255613 Using whitelisting to run untrusted C# code safely

Posted by BitMaster on 05 October 2015 - 01:34 AM

Let's say it like this: I'm pretty certain you cannot break the sandbox without giving a malicious user access to the Lua standard library. The malicious user can still make the Lua VM run out of memory though and the host program has to handle that correctly (mishandled error conditions which usually do not happen are after all a very popular exploit vector). The malicious user can also deadlock a thread unless extra precautions are taken.
Whichever API you inject into Lua (and you have to inject something, unless you just want Lua as a glorified .ini file) must also handle being called in malicious ways.

I don't think you can get much better than Lua for sandboxing purposes though. Out of the box it gives you nothing dangerous and you can control exactly which piece of user code sees what. A lot of other languages can do something like an 'import <feature>' or have access to global objects which you cannot prevent without jumping through a lot of extra hoops.


#5255606 Using whitelisting to run untrusted C# code safely

Posted by BitMaster on 05 October 2015 - 12:57 AM

I have little experience with C# but I have read into sandboxing a bit in the past. From my knowledge sandboxing works better in some languages than in others (and not at all in a few).

Lua for example should work pretty well because the language constructs available can't be reasonably used to break out of the sandbox or sabotage it. You have to be careful about which 'standard library' functions you give the user though (metatable manipulation and raw* functions are an obvious red flag, but they have a wiki page talking about it).


#5255603 Thoughts on the Boost.Build system? (as opposed to CMake?)

Posted by BitMaster on 05 October 2015 - 12:43 AM

I'm unhappy with quite a few bits of CMake.

However, I also haven't found anything yet I would use to replace it. I have come to accept that build system generators are probably always going to be quite a bit messy.

That said, at work we need a largish project (or at least parts of that project) to build on four different platforms. I know from experience that whatever hoops CMake requires of us to jump through is much better than having to deal with the platforms individual build systems by hand.

Even at home for my personal projects I'm using CMake though. It is used by a lot of people nowadays which means you find quite a bit of information when you get stuck. Finding important details about the other build system generators can get quite a bit more difficult. Increasingly many projects come with CMake right out of the box too. While some of them can be messy to integrate I have now found a few which you can just drop into your project 3rdparty subdirectory and integrate seamlessly as a dependency (not that important on *nux but reduces the pain on Windows if you want to).
It also integrates rather well with my IDE of choice (QtCreator) and should I decide to switch IDE at some later point the decision is just a CMake generate away.

the way CMake clutters up my folders with a million files just irks me a bit

I don't think I ever had that problem. Maybe you are doing something wrong?


#5255091 which program I should use for a text adventure

Posted by BitMaster on 02 October 2015 - 02:37 AM

There is also Inform and TADS. You might also want to take a look at a more specialized forum.


#5254775 vector push_back creates error when multi threading

Posted by BitMaster on 30 September 2015 - 07:48 AM

No. Every time you call doit, the function creates its own mutex. As written, it is completely useless and just wastes CPU cycles. No blocking will ever happen.

You need to do something like this:

std::mutex my_global_doit_mutex;

void doit(std::vector<int>& d)
{
   std::lock_guard<std::mutex> guard(my_global_doit_mutex);
   for (int i = 0; i < 10000;i++)
      d.push_back(15);
}
This is the simplest possible example.


#5254771 Problem with glew.h

Posted by BitMaster on 30 September 2015 - 07:41 AM

LPRECT is just a typedef for a RECT*. You need to do something like this:
RECT rect;
if (GetWindowRect(m_Hwnd, &rect))
{
	m_Width = rect.right - rect.left;
	m_Height = rect.bottom - rect.top;
}

// rect is now freed automatically
// you never leak memory, you never need to manually delete it.



#5254344 Don't want to iterate the cells in order to find one?

Posted by BitMaster on 28 September 2015 - 01:55 AM

You can gain O(1) access if there is a suitable formula to map positions to grid identifiers. For example if your grid consists of unit length cells, starting at at (0, 0, 0) and extending in the direction of the positive axis you can trivially extract intermediate X, Y, Z integer identifiers for that cell. Mapping those three identifiers to a grid identifier should be easy then (for example Z * width * height + Y * width + X but there are other possibilities).

Depending on what exactly you are doing that might not be possible and you rather want to look at spatial partitioning, for example via octrees which gives you O(log n).




PARTNERS