As a Vulkan noob, I see vkCreateDebugUtilsMessengerEXT used in tutorials,which looks similar to OpenGL Debug Output extension. Both also share same enumerators.
Please explain the difference and use case.
There are/were two extensions in Vulkan that involve handling this kind of debug report callback stuff: VK_EXT_debug_report and VK_EXT_debug_utils. Debug report was the first one and has essentially been abandoned in favor of the second. Debug report was solely devoted to providing a callback interface, while debug utils provides APIs for naming things and various other debugging systems.
Debug report is officially a deprecated extension, so going forward, you should use debug utils.
Related
Can anybody explain how can i call .net methods(from .dll) in my java code but i dont want to write/use C/C++ Code please expalin it Step by Step
You haven't given us any information to work off (How large are the two projects? Are you forced to use a specific CLR/JRE? Can they be two separate processes or do you just need to access a bunch of methods? Stuff like that), but I can point you in a general direction...
IKVM.NET is an implementation of Java that runs on the CLR. If you run your Java program in there, you can interop with any other .NET language easily.
If you can't use this for some reason, then you're probably going to have to embed Mono in your application and write some JNI bindings to start an instance of the CLR, then load and invoke your code.
If you've got a small amount of methods, consider just porting the code to Java instead of creating this huge system in order to get a small amount of functionality.
I can't explain it step by step because you haven't provided very much information as to what restrictions you have or how it needs to be done. Also, this isn't something trivial. You're trying to get two language runtimes to interact with each other without using native code, when native code is the only thing either runtime can interoperate with.
I'm fairly new to programming and wanted to start programming more efficiently. Try as I may I often find myself straying from the MVC model.
I was wondering are there any tips or methods in keeping your code organized when coding in xcode objc? To be more specific (I know you guys like that :) I want to
Be able to write libraries or self-containing code that can bring from one project to another
Share my code with others as open sourced projects
Prevent myself from writing messy code that does not follow proper structure
Use a high warning level. Build cleanly.
Remove all static analyzer issues.
Write some unit tests.
Keep the public interfaces small.
Specify your library's dependencies (e.g. minimum SDK versions and dependent libraries).
Compile against multiple/supported OS versions regularly.
Learn to create and manage static library targets. This is all you should need to support and reuse the library in another project (unless you drag external resources into the picture, which becomes a pain).
No global state (e.g. singletons, global variables).
Be precise about support in multithreaded contexts (more commonly, that concurrency shall be the client's responsibility).
Document your public interface (maybe your private one too…).
Define a precise and uniform error model.
You can never have enough error detection.
Set very high standards -- Build them for reuse as reference implementations.
Determine the granularity of the libraries early on. These should be very small and focused.
Consider using C or C++ implementations for your backend/core libraries (that stuff can be stripped).
Do establish and specify any prefixes for your library's objc classes and categories. Use good prefixes too.
Minimize visible dependencies (e.g. don't #import tons of frameworks which could be hidden).
Be sure it compiles without the client needing to add additional #imports.
Don't rely on clients putting things in specific places, or that resources will have specific names.
Be very conservative about memory consumption and execution costs.
No leaks.
No zombies.
No slow blocking operations on the main thread.
Don't publish something until it's been well tested, and has been stable for some time. Bugs break clients' code, then they are less likely to reuse your library if it keeps breaking their program.
Study, use, and learn from good libraries.
Ask somebody (ideally, who's more experienced than you) to review your code.
Do use/exercise the libraries wherever appropriate in your projects.
Fix bugs before adding features.
Don't let that scare you -- it can be really fun, and you can learn a lot in the process.
There are a number of ways you can reuse code:
Store the code in a common directory and include that directory in your projects. Simple, but can have versioning issues.
Create a separate project which builds a static iOS library and then create a framework. More complex to setup because it involves scripting to build the framework directory structure. But easy to use in other projects and can handle versioning and device/simulator combined libs.
Create a separate project which builds a static iOS library and then include this as a subproject in other projects. Avoids having to build frameworks and the results can be more optimised.
That's the basic 3, there are of course a number of variations on these and how you go about them. A lot of what you decide to do is going to come down to who you are going to do this for. For example I like sub projects for my own code, but for code I want to make available for others, I think frameworks are better. even if they are more work to create. Plus I can then wrap them up with docsets of the api documentation and upload the whole lot as a DMG to github for others to download.
With the inclusion of Microsoft Fakes in Visual Studio 11, I thought it would be worth to look into again, since I did not find Moles mature enough last i checked. The documentation is still sparse, but I cannot find any reference to mocks, i.e. the ability to set up and verify expectations on the faked objects.
Does anyone know if this is currently included (as a feature in the library) or will be?
It is not included currently, but we are considering something in this area.
Although they are not included, you can use stubs to hack in the same behavior. In your stub you can capture whether the method was called and the parameters that were called. Of course, by the time you start doing that you're almost hand rolling your own mocks.
In the meantime I'd suggest Moq or RhinoMocks. I find the syntax simpler and I'm not a fan of the generated code that Microsoft Fakes uses anyhow. Try renaming a method on one of your fakes using a refactoring tool. It's not possible because your fake is a generated class, not an instance of the interface you are stubbing.
When running a program in VS debug mode, I use the Debug.Print and watch the Immidiate Window. I'm sure there are more advanced ways to debug, but I haven't learned so far.
But I would like to know how is the best way to track both log of exceptions as well as in-code specific method print-outs (like Debug.Print), during "released" runtime; outside VS.
I would like for two purpose:
Write to log text-file
Write to UI window, like a rich-textbox.
Is this a case I should use Console.Writline? I have never used that, so if you could briefly explain if this is the right tool for what I want to accomplish, or what other ways I should consider.
Thanks!
I strongly suggest looking at log4Net rather than using Writeline. It is more robust, comprehensive, easy to use and configurable.
There an introduction here.
One of the major benefits of using a logging tool like log4Net is the ability to turn on (verbose) logging at runtime.
This answer to a question about C++ unit test frameworks suggests a possibility that had not occurred to me before: using C++/CLI and NUnit to create unit tests for native C++ code.
We use NUnit for our C# tests, so the possibility of using it for C++ as well seems enticing.
I've never used managed C++, so my concern is are there any practical limitations to this approach? Are many of you doing this? If so, what was your experience like?
We do this all of the time. We have many assemblies written with C++/CLI and use C# and NUnit to test them. Actually, since our goal is to provide assemblies that work well with C#, doing this makes sure that we have accomplished that.
You can also write NUnit tests in C++/CLI and call unmanaged C++. Probably the best way is the keep your pure unmanaged C++ in a lib, and then make a test assembly that uses NUnit and links to the lib.
It works very well and gives you the benefit of having parameterised tests as well as a common test runner and framework if you're in a mixed environment.
There are two downsides, neither of which is serious for most cases:
If you're being really picky, the tests are no longer being run in a purely native environment so there's an outside possibility that something may work under test but fail at runtime. I think you'd have to be doing something fairly exotic for this to matter.
You rely on your C++ code being able to be included into a C++/CLI program. Sometimes this can have clashes with headers and it forces your code to build OK with UNICODE. In general, this is a good thing as it uncovers crufty bits of code (like inconsistent use of Ansi variants of Win32 calls). Bear in mind that it's only the headers being included so what it may well show is that you are exposing headers at too high a level - some of your includes should probably be within your cpp implementation files.
My experience is that it is not possible to use NUnit to test C++ native code through C++/CLI because you will have trouble loading and using native code.
I have tried using nunit to load a basic c++/cli test dll linked against "just thread" which is an implementation of the c++ standard thread library.
Test dlls won't even load with the latest version of NUnit (2.6.2).
So definitely not the way to go!
I never used one, but isn't there a port? Perhaps http://cunit.sourceforge.net/documentation.html would work for you.
The biggest concern is the learning curve of the C++/CLI language (formerly Managed C++) itself, if the tests need to be understood or maintained by non-C++ developers.
It takes a minimum of 1-2 years of C++ OOP experience in order to be able to make contributions into a C++CLI/NUnit test project and to solve the various issues that arise between the managed-native code interfaces. (By contribution, I mean being able to work standalone and able to make mock objects, implement and consume native interfaces in C++/CLI, etc. to meet all testing needs.)
Some people may just never grasp C++/CLI good enough to be able to contribute.
For certain types of native software libraries with very demanding test needs, C++/CLI/NUnit is the only combination that will meet all of the unit testing needs while keeping the test code agile and able to respond to changes. I recommend the book xUnit Test Patterns: Refactoring Test Code to go along this direction.