Jump to content

  • Log In with Google      Sign In   
  • Create Account

BitMaster

Member Since 08 Aug 2000
Offline Last Active Today, 09:39 AM

#5299482 GL Synchronization between process

Posted by BitMaster on 07 July 2016 - 02:53 AM

Nope. I only mentioned the thread signaling in combination with the glFinish.
 
You can create a sync object, then "give" this sync object directly to another thread and this other thread with his own OpenGL Context can then wait/test for the sync object status.
 
EDIT: Just to include all details. You must create share OpenGL contexts to interchange anything between them. But most helper libraries, like for example SDL2, do this by default.


That is irrelevant though because the OP specified in #3 that they need the information between different processes, not just threads in the same process.


#5299155 class array to list

Posted by BitMaster on 05 July 2016 - 07:42 AM

Again, your constructor does not do what you think it does. This has nothing to do with classes, this is the basics of value assignment in C++ (or even C).


#5299110 class array to list

Posted by BitMaster on 05 July 2016 - 05:26 AM

Ausfaelle::Ausfaelle(int a, int b, int c, int d) {
    a = index;
    b = active;
    c = color;
    d = drValue;
}


You are assigning to local variables (the parameters to the constructor) and everything you do there is lost when the function returns.


#5298978 Creating OpenGL context in different OpenGL driver versions

Posted by BitMaster on 04 July 2016 - 02:40 AM

Do yourself a favor and use GLFW, or SDL to handle contexts. No one will look down on you for not learning all that platform specific stuff, and if they do, they're idiots, so you shouldn't listen to them anyway.

 
Well, I don't really care if someone knows I can handle buffers, memory, handles, pointers, etc. Actually your answer is out of context here, I would appreciate if you first learn to read the post at the top.


His answer is exactly in context here. Both GLFW and SDL have one core feature: create a window and initialize an OpenGL context for that window. SDL does come with some added utility on top of that but the core here is really the context creation (and window management). I have done it by hand. There is really no magic to it, it's just a huge chore. Especially once multiple platforms come in, sticking to the best practices of each platform and creating a valid context there is just one huge annoyance.

There are tons of interesting areas where you can have a lot of fun going into the nitty gritty details and doing things by hand and from the ground up. Wasting the limited time you have with stuff like window management when you do not need anything above the well-tried and exhaustively tested solutions does not feel like a smart move.

You also seem to be drawing some wild personalized, arbitrary distinction between what you think a developer is and what a programmer is. Personally I would not do that but if I absolutely had to, the roles would be reversed. A programmer would be someone coding to specifications using whatever library are required or allowed by the specifications. A software developer would deal with (or at least be qualified to do it) that but also with the steps coming before, including research and planning.


#5298601 .obj MESH loader

Posted by BitMaster on 30 June 2016 - 02:06 AM

Well, since you did not post any codes or described the problem in any detail this will be difficult to debug.

However, this is about Wavefront .obj files, so the obvious question first: did you account for the fact that Wavefront .obj files assume indices to be one-based?

Edit: Also, .obj files allow different indices for different attributes. Neither OpenGL nor DirectX allow that, so you will have to generate a different vertex for every distinct (vertex index, normal index) pair.


#5298379 [MSVC] Why does SDL initialize member variables?

Posted by BitMaster on 28 June 2016 - 07:18 AM

Well, if you have such an error than it's safer to have it on nullptr than some random value. The random value might be one you are allowed to access. nullptr reliably crashes.


#5298193 why that i get a signal SIGSEGV with my Multithread code?

Posted by BitMaster on 27 June 2016 - 02:12 AM

Personally I would point to Álvaro' advise in your other thread dealing with the same problem.


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

Posted by BitMaster on 25 June 2016 - 12:53 AM

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.


Even among the more traditional OO schools (heavy on inheritance and polymorphism) there are strong voices that member function should only be used where necessary and free functions be preferred (assuming of course you work in a language which has the concept of member functions to start with).

Setting that aside, this design makes the standard library containers more OO, not less. Based on the iterator category the compiler can select different algorithms depending on what kind of iterator it gets (all decisions are made at compile time which is a form of compile time polymorphism). That has several advantages. Without compile time polymorphism, I would we would either need virtual functions (runtime overhead) or having the algorithm tied directly to the container. Coupling the algorithm and container that strongly has negative side effects, for example every new container has to do the same work again. For example boost::small_vector is extremely similar to an std::vector. Thanks to that design decision the boost::small_vector can transparently make use of any algorithmic enhancement already available to the std::vector. There are also important questions about how to deal with algorithms taking input from more than one container as well.

Additionally, this design allows for cleaner extension. If I add a new algorithm I would have to modify every standard library container just to get it as a member function or have a free function when every other algorithm is not.

Avoiding a need for explicit member functions has other advantages in C++, especially once templates are involved. For example std::begin/std::end were added in C++11. When I have SomeType from SomeLibrary which would be sufficiently container-like I can still use it as a container in any template code simply by adding overloads for std::begin and std::end. That even works when I'm unable to modify SomeType's interface or it's an opaque type from a C library.

And even after all this, the nitty griddy internals of the std::containers are handled as member function and hidden from the outside. A container is supposed to store data (allocating and freeing memory as needed, initializing and destroying data at the adequate times). It must allow for adding and removing data. It must allow for accessing the data somehow (by index, by key, by sequence, ...). All of these things (which need the implementation details) are handled as member functions. Sorting a container or finding an element in the container or partitioning the container or anything else in algorithm or your own library is not part of the the container's job. It is good design not to pollute the interface of the container with 'also useful sometimes' but not 'mission-critical'. Note that some containers do consider some operations as part of their mission statement and add corresponding member functions (for example finding something in an std::set).

While we are talking about the containers, they also make use of composition in the form of an allocator. Currently you are stuck at compile time here (unless you are willing to do a bit of extra work) but C++17 has the polymorphic_allocator. Obviously that comes with a bit of extra cost then, but if polymorphism were free of any extra costs we would not be talking about any of this because the C++ standard library would have done it all in a more classic OO-y way.


#5297947 Including from the Standard C++ Library

Posted by BitMaster on 25 June 2016 - 12:02 AM

All these cmath, string, etc. are still regular headers, just without extension. At least VS automatically adds references to the C++ runtime libs, so all you need to do is to include the headers. The libs are imported "under the hood".


Well, the standard allows for standard library headers to be 'something special' instead of regular text files but I'm not aware of any implementation which really does it.

That said, the file extension of headers is irrelevant. .h, .hpp or .hh are commonly used. .inl is sometimes used to name files which contain inline definitions which are often included from their parent header. Nothing stops you from including .foo or .bar files as headers. C++ does not care, although people who read you code might have objections.

Not using an extension for your headers is another way to go but since all C++ standard library headers are usually extensionless I would argue that is bad style.


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

Posted by BitMaster on 24 June 2016 - 02:14 AM

Just for kicks, take a look how much inheritance or polymorhism is used in the C++ standard library.


Not that I disagree with your general point, but I don't know that I would necessarily call the standard library especially object-oriented - in fact, its original designer believes that the C++ standard library (or at least its predecessor) isn't even object-oriented at all, so I would say that the standard library is not really a useful example of "modern OO".


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).


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

Posted by BitMaster on 24 June 2016 - 01:24 AM

Don't look at me. I think the "but but I have to type "static" and put it in a class file!" complaint is stupid. If it looks like a duck and quacks like a duck... C# has exactly the same requirements thus why I dont see the point.


I have to agree here. I have developed a significantly less positive view of Java than I had in the past but I never understood (and still don't) that particular complaint. Procedural style in Java is possible without problems.

Okay, so I have to put my functions in a mandatory namespace and a bit counter-intuitively the namespace is declared with the 'class' keyword. We could add some syntactic sugar and add a 'namespace' keyword which just means 'class with all member functions and data automatically static' but among all the legitimate complains one could have with Java, this feels a bit ... pointless.


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

Posted by BitMaster on 24 June 2016 - 01:06 AM

Step 1: agree with Hodgman. Whew. That saved me some mental work and typing.
 

I'm sure your code is fantastic, but is probably not true OO.


I'd like to add a few comments about that though. Considering the amount of religious wars fought about what OO really means I'd say this statement is rather pointless.

Since it is scheduled to be hot today and I want to finish the work I need to finish with the minimum amount of time wasted allow me to speed up the usual process at this point. So:
Yes, my code is the real true OO.
No, you don't know what you are talking about.
You are also a <mild expletive of your choice>.

Disclaimer: this post may contain irony and/or joking hyperbole below the quote.


#5297675 what means these error?

Posted by BitMaster on 23 June 2016 - 03:32 AM

Again, you need to break into the crash with your debugger and inspect the state of variables. This kind of problem is bread and butter to any programmer. If you are unwilling to learn debugging this, you should change career/hobby.


#5296912 Is C++11's library a magic bullet for ALL multicore/multithread programming?

Posted by BitMaster on 17 June 2016 - 01:06 AM

They have added the libstdc++ runtime exception. From how I understand it that should allow you to link everything together (even completely statically) without any license side effects on your code.


#5296638 How to avoid Singletons/global variables

Posted by BitMaster on 15 June 2016 - 07:18 AM

Because I'm fairly certain that you're response isn't by using a singleton yourself, but because someone else told you so.

I have seen the pain and suffering singletons and global variables can cause (for reasons: see above). I know enough of phantom that I would be extremely surprised if he hadn't experienced it himself.
 

...

Again, you are working on a very small project, in specialized domain in what sounds to be practically an embedded device. Of course you have to work differently there than in more normal circumstances. The core problem I'm seeing here is that you try to transfer your experiences in a narrow and specialized field to the general case. In the general case what you are saying is extremely bad advice and practically everyone who worked there for a bit has the scars and emotional trauma to know that first hand.




PARTNERS