Your C\+\+ language dialect is set to "Compiler Default" in your project after being created by cmake. The default C\+\+ language version is C\+\+ 98, I believe. Changing the C\+\+ language dialect to c\+\+11 build successfully. Also, C\+\+ 98 does not support the ">>" in template definition, that came about in C\+\+ 11 as well. Not sure your "compiler_flags.cmake" file is being processed successfully. None of the settings defined in the file seem to be set (did a quick look at the Xcode project log to see how the compiler was invoked). You might want to change the "Clang" to "clang++" in your cmake file. Can't explain about colleague's Xcode 10. Should be the same compiler default. His/her invocation of cmake seems to be doing the right thing.

Is it really Bogus.c, not something like Bogus.cpp, Bogus.cc, Bogus.cxx? If it is really Bogus.c, how are you telling Xcode that it is a C++ file? This works for me on all versions of C++ >= 11: // Bogus.hpp #include <string> #include <initializer_list> #pragma once namespace Testit { class Bogus { public: Bogus() = default; Bogus(const std::string& _filename) noexcept; Bogus(int _argc, const char* _argv[]) noexcept; void set(const std::string& _key, const std::initializer_list<std::string> list); }; } // Bogus.cpp #include "Bogus.hpp" namespace Testit { Bogus::Bogus(const std::string& _filename) noexcept { } Bogus::Bogus(int _argc, const char* _argv[]) noexcept { } void Bogus::set(const std::string& _key, const std::initializer_list<std::string> list) { } } // main.cpp #include "Bogus.hpp" int main(int _argc, const char * _argv[]) { std::initializer_list<std::string> list = {"one","two","three"}; Testit::Bogus bogus(_argc,_argv); bogus.set("key",list); return 0; }

In your Xcode project for the Mac application, there should be a Main.storyboard file. Open it up (it will open in Interface Builder). What you should see is the menu bar for your app. Select the "Help" menu item and hit the delete key. Re-build. You can also edit the menu to remove other items in the menu items, and the items they contain, etc., that also don't make sense for your application

NSWindow has a "backgroundColor" variable that lets you set the window background color. NSWindowController has a variable "window" that contains the window the controller is controlling.

Has anyone ever filed an Apple feedback report with a feature request/bug report? Apple developers don't normally read these forums, and, if they do, they can't take unilateral action based on forum requests. You need to file a bug report. Link at bottom of page "Report Bugs"

Xcode 11.5 MacOS Catalina 10.15.5ML tool is under Xcode&gt;Developer Tools

Whether the system uses pread/pwrite is considered an implementation detail. However, it doesn't really matter. You an open a file with FileHandle.init, and then use the POSIX file descriptor (there is a FileHandle method to access the POSIX file descriptor) in your own calls to pread/pwrite.

You might want to look at this for dynamic library usage on MacOS.https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.htmlIt covers dlopen as part of the discussion

I wrote this little C program that uses the setenv/getenv on MacOS#include &lt;stdio.h&gt; #include &lt;stdlib.h&gt; int main(int argc, const char* argv[]) { const char* env_name = "DYLD_LIBRARY_PATH"; const char* value = "/opt/local/lib:/opt/freeware/lib:/opt/gnu/lib:/opt/lib"; printf("DYLD_LIBRARY_PATH = %s\n",getenv(env_name)); setenv(env_name,value,1); printf("DYLD_LIBRARY_PATH = %s\n",getenv(env_name)); return 0; }The first line of output shows (null) since I don't have a default DYLD_LIBRARY_PATH environment variable defined. Second line of output shows the environment variable set to the given value. Note that the setting modifies the environment for this instance execution; once execution is over, the modification is lost.This works fine as a normal user on my Mac system. MacOS Catalina 15.4.1

It sounds like your window size is too small for your content. Did you get a 230x400 size window? The (0,0) is the position of the window's lower left corner in screen coordinates. If you don't call window.center(), you see your window appear in the lower left hand corner. The window.center() call causes the default NSWIndowController to place the screen in the center.Might try something like this:window = NSWindow(...) window.contentView = NSHostingView(rootView: contentView &lt;figure out what the frame size should be&gt; window.setFrame(NSRect(x:0.0, y: 0.0, width: &lt;best width, height: &lt;best height&gt;), display: true) window.setFrameAutosaveName(...) window.center() window.makeKeyandShow()Using the setFrame call resets the frame and width display: true, causes the view to recalculate it's size.

I would expect there will improvements announced at WWDC to SwiftUI since Apple sees SwiftUI as important to their future development efforts. Whether they are major improvements will probably be in the eyes of the beholder. However, Apple rarely provides (I think never, but, that may be a little presumptuous on my part) roadmaps fot its internal product development (and SwiftUI is definitely, at this point, an internal development effort). Swift itself is an example. The open source Swift.org has public roadmaps, or at least publically defined goals, but what Apple does internally with the open-source is never discussed publicly until it is officially announced.

I use a config file (.xcconfig), and set the build setting CLANG_CXX_LANGUAGE_STANDARD = c++2a. Look at the config file support in the Xcode help to figure out how to use a config file.

What you are describing seems to fit the description of a Launch Agent, or Launch Daemon. There are guides in the Apple documentation on how to build a launch agent or launch daemon. Launch agents can even have a GUI (I think). Nice thing about agents and daemons is that can be started up by the system on demand, you don't have to start it manually.

iOS or macOS?If macOS, you have a choice of a Framework, or LIbrary project. The direct analog to a .dll is a dynamic library (.dylib). Frameworks, work well with the macOS infrastructure (a framework includes a dynamic library without the extension, along with headers, resources, etc.). You can use C, C++, Objective-C, Objective-C++, Swift, and any other language with special build rules, in any combination.For iOS, you can build a framework or a static library. Frameworks are same concept as macOS. You can create a Framework or static library project using either Swift or Objective-C/C++, but, once the project is created, you can write code in compatible languages. Objective-C++ is a pretty good amalgamation for using C++ code (use .mm files to automatically compile Objective-C++ code files).

The Parallel TS is not implemented in the clang system yet.