Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Dec 1999
Offline Last Active Private

#5285544 Why is my struct destructor not called?

Posted by SiCrane on 07 April 2016 - 12:19 AM

You could explicitly invoke the dtor before you invoke the ctor again.
a = A();

This would be a bad idea in the general case. The assignment operator would assume that the object is in a valid state, but the destructor for most non trivial objects would put it in an invalid state. Ex: it may deallocate internal buffers, but the assignment operator may assume that those buffers are allocated.

#5283635 Can memory leaks only caused by using the new keyword?

Posted by SiCrane on 26 March 2016 - 05:47 PM

Memory can also be directly allocated with malloc() or related functions such as realloc() or calloc() or with direct OS calls such as the HeapAlloc() function in Windows.

#5272421 C++ interfaces and library decoupling

Posted by SiCrane on 23 January 2016 - 07:51 PM

To be fair, each library still has to know about the other in COM because they have to have access to the interface definition.

Not necessarily. It's a lot easier if the static types of all the interfaces necessary are available, but a library that implements the IDispatch interface can be dynamically interrogated and manipulated. Both libraries need to know about COM automation, but they don't necessarily need to know about each other. For example, this is how scripting support for new components was implemented in Office (up to around 2003, no idea if later versions of Office changed their inner workings). If you added a new charting widget to your worksheet, Excel wouldn't know about new interfaces it added over the base OLE stuff, but you could still manipulate them through VBA because the charting widget would implement the IDispatch interfaces VBA would use to make the actual calls.

For dynamic libraries your options are far more limited, as C++ cannot be used. (Insert arguments about how C++ can be used under special conditions A, B, or C) In most cases you'll be dealing with C APIs and things like function pointers.

You may want to be a lot more clear about what you mean by "C++ cannot be used" as it's pretty obvious that people do write dynamic libraries in C++. Again, many COM DLLs are written in C++. Right now your statement only makes sense if you already know what it means.

#5272408 C++ interfaces and library decoupling

Posted by SiCrane on 23 January 2016 - 05:21 PM

With proper design firewalls that can work. In particular you need to make sure that the libraries are compiled in a compatible manner (ex: both libraries agree what the size of the various types are) and one binary doesn't mess with the implementation details of the other (ex: no deleting something new'd by the other - note that this means that if your interface contains inline functions, in particular template code which is implicitly inlined, then you may have problems). One example of this at work is COM, which allows binaries built by different compilers (and programming languages) to work together on Windows.

#5270218 Python for 1st language?

Posted by SiCrane on 08 January 2016 - 10:48 PM

Nothing wrong with Python as a first language, but if your eventual goal is PC programming with C++, you may want to start with C# instead. Difficulty-wise it's roughly equal to Python, and it's closer to C++. In terms of game programming C# is probably easier than Python with better libraries and frameworks available.

#5269986 Should I Take AP Biology?

Posted by SiCrane on 07 January 2016 - 10:53 PM

A lot of universities give benefits for students with more credit hours such as being able to register earlier or being able to more easily qualify for better parking permits. Usually one AP test by itself wouldn't make much of a difference for this purpose, but you're already interested in two more. So if you think you can get a four or five on the AP exam, I'd recommend taking the course even if you don't think it would apply towards your major.

#5268786 Global Initialization

Posted by SiCrane on 01 January 2016 - 10:52 PM

Statically initialized objects have lifetimes that you cannot control. It happens before main(), and is frequently a source of issues.

It usually happens before main(), but it's not guaranteed. That standard only says that if it's initialized after main() starts, it'll be initialized before first use. This generally means that objects at namespace scope or static class members will be initialized before main() but objects with static storage duration with function scope will be initialized in the first call to that function. However, there's an important caveat that unreferenced objects at namespace scope may never be initialized at all.

#5268496 Generating many configurations of a class at compile time

Posted by SiCrane on 30 December 2015 - 11:55 AM

There's nothing fundamentally wrong with this approach. Boost has a preprocessor library for supporting this kind of thing if you try to do anything more complex than your example. One important implementation note: if you have a header designed to be included multiple times, save yourself some maintenance headaches and stick a comment up top saying that the lack of header guards or pragma once is deliberate.

#5262307 Integrating a scripting language

Posted by SiCrane on 16 November 2015 - 02:34 PM

AngelScript also supports weak references.

#5261016 Problem with variable arguments

Posted by SiCrane on 08 November 2015 - 11:49 AM

Note that right now C++ has two language features for variadic arguments: the old C style variadic functions and variadic template function parameters. You are using the syntax for the former. However, you can't do argument forwarding with C-style variadic functions. You'll need variadic templates for that.

#5260148 C++ enum class error

Posted by SiCrane on 02 November 2015 - 11:09 AM

Your code as posted compiles for me. You may want to post your actual code.

#5259511 C++ Interfaces

Posted by SiCrane on 28 October 2015 - 11:01 PM

You would store a (smart) pointer to the interface type. So IShader * or something like std::shared_ptr<IShader>.

#5257954 Does calling ~myclass() (destructor) deletes the object?

Posted by SiCrane on 19 October 2015 - 01:44 PM

Manually calling the destructor just runs the destructor code, it doesn't free the memory for the object like delete would. 

#5241137 Md5 Password Hasher would you use this.

Posted by SiCrane on 17 July 2015 - 07:09 PM

If you want a one size fits all, don't want to think about it choice for storing password hashes, just use bcrypt. There are situations where it's not the best choice, but it's a good default at the moment.

#5240873 typeid operator

Posted by SiCrane on 16 July 2015 - 01:11 PM

hash_code() can return the same for different types due to hash collisions. name() can be the same for different types because name isn't guaranteed to be a fully qualified name (if you have class Foo in namespace bar and class Foo in namespace baz, name() might be "Foo" for both, despite being different types).


I've been told that originally people wanted stronger guarantees for name(), but someone noted that with dynamic linking it was possible for two modules to have different types with the exact same qualified name and then all sorts of corner cases came out and we got a water downed type_info specification. I don't know how true this is, but I do know that other aspects of RTTI that seem screwed up are due to supporting dynamic linking. In any case, one way to get around the problem of dynamic libraries containing potentially the same named types is to embed something like the base module address to the name or hash code. However, if you do that, if the module loads in a different address in two different runs, then name() or hash_code() could change between runs.