Jump to content

  • Log In with Google      Sign In   
  • Create Account


SiCrane

Member Since 09 Dec 1999
Offline Last Active Today, 10:36 AM
*****

#4922653 DLL question - plugin system

Posted by SiCrane on 16 March 2012 - 01:20 PM

On Windows, the layout of the vtable for an abstract base class is de facto standardized - it's how COM is defined for C++, so if your compiler supports COM and the other compiler supports COM it should be able to support your application.


#4922606 DLL question - plugin system

Posted by SiCrane on 16 March 2012 - 09:42 AM

I really don't see why you need to use an intermediary DLL here. Just define your model class as deriving from an abstract base class and pass pointers of those to the DLL.


#4922270 Template classes

Posted by SiCrane on 15 March 2012 - 07:48 AM

To fix the compiler error you would change your code to:

template<class identifier>
void myclass<identifier>::function()
{
   //---
}
As noted above you'll get a linker error without explicit instantiation if you put that code in a source file.


#4921796 How to get the file extension using boost filesystem

Posted by SiCrane on 13 March 2012 - 04:52 PM

You would probably want to use the extension() function with path objects.


#4921752 Whats the worst a bad pointer could do

Posted by SiCrane on 13 March 2012 - 02:48 PM

It depends on your platform. On a platform with protected memory like modern PC operating systems the worst it could probably do is provide a security hole that could be exploited. On other platforms it could crash the computer, corrupt the operating system or similar feats.


#4920756 COM as a way to implement the use of STL containers across a DLL

Posted by SiCrane on 09 March 2012 - 02:56 PM

This will partially work (in that you can create and use the class, but you can't use it as a base class, and it will generate a warning)

Did you notice that the OP mentioned different compilers? Standard library classes do not have a single implementation. std::string could be implemented with the small string optimization on one compiler and not with another. Try using a DLL with the first implementation with a different compiler is completely undefined.

It's got nothing to do with compiler packing, it's simply the inability to guarantee the size of the CSL containers (due to additional debugging nonsense).

Again, size is only part of the problem. Standard library containers can have fundamentally different implementations with different compilers.




#4919782 Why can't static const float members be initialized in a class?

Posted by SiCrane on 06 March 2012 - 09:14 AM

The only thing that has been missing is a strict and standardized definition for what value the compiler will create when making these constants.

Which doesn't exist in the current standard. It even says the exact opposite, that the standard "imposes no restrictions on the accuracy of floating-point operations" (Section 5.19).

You need to trust me

No, I don't. What was asked was the reason that the standards committee forbade inline definitions for static const floats in the previous standard. Not your supposition why they forbade it. If you can't cite an actual source then there is no reason to trust you, especially as your answer is in contradiction with what the standard actually says.


#4919652 COM as a way to implement the use of STL containers across a DLL

Posted by SiCrane on 05 March 2012 - 08:15 PM

As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.


#4919597 Why can't static const float members be initialized in a class?

Posted by SiCrane on 05 March 2012 - 04:17 PM

It is the correct explanation.

Source?


#4919446 Why can't static const float members be initialized in a class?

Posted by SiCrane on 05 March 2012 - 08:13 AM

It's also an incorrect explanation. If that was the reason, then compilers like gcc wouldn't have been able to offer static const float member variables with inline definitions as extensions. And changing a variable defined as const isn't legal even if they have storage. There's nothing inherent to floating point numbers that requires them to be initialized at runtime otherwise constexpr wouldn't work with floats.


#4919224 Why can't static const float members be initialized in a class?

Posted by SiCrane on 04 March 2012 - 12:18 PM

Nice way to take posts out of context. This is the post those were the response to:

Is it because float is old-school..
Because i can use

static const long color = ... //Works like a charm.

The long type works because it's an integral type and float doesn't because it's not a integral or enumeration type. And if you were actually paying attention to the thread rather than locking in on random details to nitpick you'd notice that the C++11 standard does currently allow for inline literal type initialization, so there currently is no technical limitation.

However, since you seem to have all the answers here, why didn't you give the reasons? Or do you just like lecturing from a position of ignorance?


#4919198 Why would this fail?

Posted by SiCrane on 04 March 2012 - 10:37 AM

Depending on your compiler, it may have heap debugging facilities. For example, the code sanchopan posted is MSVC specific. On Windows you can also use Application Verifier to debug some kinds of heap usage errors such as buffer overruns.


#4919193 Why can't static const float members be initialized in a class?

Posted by SiCrane on 04 March 2012 - 10:28 AM

Or upgrade to C++11 and use constexpr.


#4918769 Run-Time Check Failure #0 Fun Stadium

Posted by SiCrane on 02 March 2012 - 07:59 PM

In this case you can use a dynamic_cast to get from one interface to the other. A C style cast will just reinterpret the address as the other interface, but with multiple interfaces the interfaces have different addresses for the same object.


#4917740 Explain this set of Code

Posted by SiCrane on 29 February 2012 - 07:54 AM

I've always wondered whether there was a practical application for the flexibility of this rule, beyond the literal 0 value...

This is the explanation I've heard: programmers frequently misuse the NULL macro, such as assigning it to integers. Sometimes some issues can be detected by using a null pointer constant other than 0. For example, if pointers are 64-bit and ints are 32-bit, assigning 0 to an int won't give you warning that an int doesn't have enough bits to represent an actual full pointer. On the other hand, if long long could hold that value you can #define NULL ((long long)0) which would still be a legal null pointer constant but would also tell you that your destination size is too small if you tried assigning to a regular int.




PARTNERS