Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Aug 2000
Online Last Active Today, 12:32 AM

#5264392 Casting a vector of arrays

Posted by BitMaster on 01 December 2015 - 05:42 AM

it is just that pushing code fetishes over cpp is pointless).

As someone who earns his living working in C++ codebases of considerable size and complexity and sins: no. This is no "pushing fetishes". Not sticking to rules like that is a direct cause for countless lost hours.

#5263773 Casting a vector of arrays

Posted by BitMaster on 27 November 2015 - 02:03 AM

but this gives me an error when trying to compile. It says something about invalid static cast from std::array... aka{unsigned char *} to char*.

Always copy and paste complete error messages. Never "something" an error message.

That said, unsigned char and char are distinct types. So are pointers to these types. You need to be more exact what you cast to what.

Edit: You need reinterpret_cast to change the pointer types.

#5261722 simple java question

Posted by BitMaster on 12 November 2015 - 01:23 AM

Edit: not worth a fight and I'm under enough stress without opening a can of worms and arguing exact semantics and explanation methods.

#5261485 Generic Installer - Cross Platform

Posted by BitMaster on 11 November 2015 - 01:46 AM

I would just like to agree with the above. I have never encountered an installer generator across multiple platforms (as distinct as Windows, MacOS and Linux) and I would be surprised if there was one. Pleasantly surprised, but still surprised.

CMake (via CPack) for example can abstract that away up to a point, but it still uses NSIS on Windows, Bundles on MacOS and I'm-not-really-sure-what on Linux. You are still going to need significant platform-dependent settings and polishing though.

#5261482 simple java question

Posted by BitMaster on 11 November 2015 - 01:34 AM

In Java Strings are immutable.

They are, but that does not matter here. The assignment
i = "0"
is syntactic sugar for
i = new String("0");
which should make what happens much clearer.

#5261328 Problem with variable arguments

Posted by BitMaster on 10 November 2015 - 05:17 AM

You appear to be passing everything as a template parameter now, including things that make absolutely no sense. On top of that you don't even call addObj then. I would strongly recommend to take a huge step back and forget about parameter packs for now. You seriously need a lot more practice and experience with basic C++ and basic templates.

#5261131 Can someone please explain + example of 'ownership'

Posted by BitMaster on 09 November 2015 - 08:50 AM

What you wrote was just an example of a relation between two classes you chose to call ownership (you could as well have called them 'holder' and lose even the extremely superficial relationship to the question). It has nothing to do with the questions asked by the OP which were about the core concept of software development. In most cases resources being owned by someone will not know who owns them (and not care about it at all).

#5261129 Can someone please explain + example of 'ownership'

Posted by BitMaster on 09 November 2015 - 08:41 AM

A simple explanation of ownership can be seen like a cup class and liquid class : the cup owns the liquid.
That could be like that :

class Cup;

class Liquid
  Liquid( Cup* Owner ) :
  m_Owner( Owner )

  Cup* GetOwner() const
    return m_Owner;

  Cup* m_Owner;
Now you can get the owner from liquid to know what cup owns this liquid.

That is not a useful example at all. None of the important bits can be gleaned from it. For the core concept of ownership the interesting part would be the definition of Cup. When is a liquid created? When is it destroyed? What happens when you copy a Cup? Are you allowed to copy a Cup? Can two Cup instances share the same Liquid?

#5261125 Can someone please explain + example of 'ownership'

Posted by BitMaster on 09 November 2015 - 08:37 AM

A and B could be anything. They could be objects. They could be a handle to an operating system resource. They could be an opaque type you need for interaction with a library.

Ownership and the proper definition of it is pretty much a core issue in software development. If you get ownership right a lot of problem sources are just gone.

You always have to deal with ownership (at least for non-trivial programs). In the simplest case whenever you 'new' something the immediate question you need to ask it: "and who does the 'delete' now?" (the 'when?' is also an interesting problem but usually just another facet of the same core issue).

Common problems if you don't get ownership right include:
  • memory leaks
  • freeing resources more than once
  • accessing resources after they have already already been freed
Finding the right ownership semantics for a problem is part of being an experienced developer. There is no 'The Solution', you need to look at your situation and weigh pros and cons of possible solution to arrive at ownership semantics.

For example if several models you are rendering use the same texture "rusty_metal_grate.png" it would be a waste to upload it for each model which needs it. They could all share it. So, instead of each model loading the texture from disk and uploading it to video memory they ask the AssetCache for it. The AssetCache either loads the texture from disk and instantiates it or returns an already existing instance. When a model is done with it, it does not destroy the texture (that would mean every other model using the texture is broken, most likely crashing the application when they next try to use it), it informs the AssetManager they no longer need it. In most cases the AssetManager will then just note down that the resource is used by one less user. Only if the last user releases the resource it could consider freeing it.

In other situations you explicitly don't want to share, for example because each owner wants to make modifications to a resource which could be contradictory. Or liable to race conditions because each owner lives in a different thread and you cannot/don't want to enforce some kind of synchronization.

You can fill whole topics of a book with discussions about the concept without exhausting it. In the context of C++ RAII is an important related subject as is the Rule of Three. It might also be a good idea to take a look at the standard library's std::shared_ptr and std::unique_ptr.

#5260736 Possible to forward declare a sub class?

Posted by BitMaster on 06 November 2015 - 03:01 AM

That is not what is typically called a subclass. However, the same rules as I listed above still apply to it. You cannot create an instance of Two without its complete definition being known.

What you could do in this case is create a kind of factory function declared in One but implemented where the full definition of One::Two is known.

#pragma once

class One
	int doSomething()
		cTwo = createTwo();
		return 0;

	class Two;
	Two* cTwo;

        Two* createTwo();

// Implementation in a different file
class One::Two
	int test()
		return 0;


One::Two* One::createTwo()
   return new Two();

#5260733 Possible to forward declare a sub class?

Posted by BitMaster on 06 November 2015 - 02:49 AM

A forward declaration just tells the compiler there is a type with that name. The compiler knows neither the size of the type nor any inheritance relationship.

In a nutshell:
class C { ... };
class S;

S myVar; // invalid, the compiler does not know anything about S, not even how much memory it needs
S* myPointer; // no problem, a pointer or reference to an opaque type is fine
C* myBasePointer = myPointer; // invalid, the compiler has no knowledge of any relation between C and S at this point

#5260471 C++ calling a class constructor in a function argument

Posted by BitMaster on 04 November 2015 - 03:34 AM

'SecondClass' has not been declared inside the MainClass.

'secondClass' has been declared to be member data of type 'SecondClass' inside MainClass. Obviously when you say something contains something, you should be able to use it.

#5260457 blender multi-texture to opengl

Posted by BitMaster on 04 November 2015 - 01:55 AM

I don't think Wavefront .obj files can deal with that in a standard way. Wavefronts are nice to get things started but I would not consider them for serious work.

This has nothing to do with OpenGL, by the way.

#5260289 How does this "pop_front()" implementation work?

Posted by BitMaster on 03 November 2015 - 05:43 AM

The move assignment in C++ is basically like the copy assignment, the key difference being that the moved object is left in an "will not be used again" state.

That is not true in this context. Standard library constructs guarantee (unless explicitly stated otherwise and I still can't say any class that does) that they are in 'unspecified but valid' state. You are explicitly allowed to do any operations on them which do not have preconditions. The standard also requires that any objects you put into its container stick to the same rule.

Edit: maybe some examples are useful:
std::vector<MyData> data = { ... };
somethingElse = std::move(data);
// data is now in an unspecified but valid state
std::cout << data.size() << "\n"; // <-- this is never a problem although we don't know what will be printed
std::cout << data.front() << "\n"; // <-- this is an ERROR. data can be empty in which case we violate the precondition of front()
data.clear(); // from here on we know data is empty
data.push_back(...); // now we know there is one element in there
std::cout << data.front() << "\n"; // this is no problem now

#5260270 Problem with OpenGL error

Posted by BitMaster on 03 November 2015 - 01:28 AM

Are you absolutely certain you are correctly checking the compile status of both shaders? The code you posted does not do any checks on the shaders and I cannot think of any other reason for the linker to cop out with such an error message. You should also verify none of the shader objects you attach are 0 for some reason or you deleted them too early.