win32 c++ fstream wide argument - unicode

See link for what I'm talking about.
I want to use point 1 in the link and
#define tfopen _wfopen
#define _T(s) L##s
to do exactly what the link says is possible:
std::ifstream file( tfopen("filename.txt", _T("r") );
But gcc (mingw) 4.4 says there's no matching call...
Am I doing it wrong or is the info in the link above incorrect?

You need to use the macro for the first parameter to tfopen, which in your case is "filename.txt"
std::ifstream file( tfopen(_T("filename.txt"), _T("r") );

The simple answer is that you're missing a _T. However, you may want to rethink the entire TCHAR approach and just call _wfopen (assuming Windows-only code).

Related

Printing to console in VDM++?

How do I print text or values to the console to validate that my model is working correctly?
I would like to do something like this:
class Main
operations
public Run: () ==> ()
Run() ==
print "Text"
print mon.Func()
end Main
It seems to be possible, but I just cant figure out how to do it.
You need to use the VDM IO library. There are a couple of operations that do what you want - println (for printing fixed values) and printf, which has parameter substitution. So you would call IO`println("hello"), for example.
In the latest release of Overture and VDMJ, you can also use a VDM annotation to print values without adding anything to the "content" of the specification itself. Annotations are rather added as comments. See #Printf.
Nick Battle answered my question but for other beginners to VDM, there is missing a detail to his answer, how to include libraries.
Before one can use the IO library, you first have to include it.
I am using Overture and to include libraries into your project, you have to right-click on the project in the side menu and press New > Add VDM Library.
You can then choose which libraries you want to include in a menu that pops up.
Here you choose IO.
After this you should be able to print out values using the IO`println(val) function.

How to reliably detect os/platform in Go

Here's what I'm currently using, which I think gets the job done, but there's got to be a better way:
func isWindows() bool {
return os.PathSeparator == '\\' && os.PathListSeparator == ';'
}
As you can see, in my case all I need to know is how to detect windows but I'd like to know the way to detect any platform/os.
Play:
http://play.golang.org/p/r4lYWDJDxL
Detection at compile time
If you're doing this to have different implementations depending on the OS, it is more useful to
have separate files with the implementation of that feature and add build tags to each
of the files. This is used in many places in the standard library, for example in the os package.
These so-called "Build constraints" or "Build tags" are explained here.
Say you have the constant PATH_SEPARATOR and you want that platform-dependent, you
would make two files, one for Windows and one for the (UNIX) rest:
/project/path_windows.go
/project/path_unix.go
The code of these files would then be:
path_windows.go
// +build windows
package project
const PATH_SEPARATOR = '\\'
path_unix.go
// +build !windows
package project
const PATH_SEPARATOR = '/'
You can now access PATH_SEPARATOR in your code and have it platform dependant.
Detection at runtime
If you want to determine the operating system at runtime, use the runtime.GOOS
variable:
if runtime.GOOS == "windows" {
fmt.Println("Hello from Windows")
}
While this is compiled into the runtime and therefore ignores the environment,
you can nevertheless be relatively certain that the value is correct.
The reason for this is that every platform that is worth distinguishing needs
rebuilding due to different executable formats and thus has a new GOOS value.
Have you looked at the runtime package? It has a GOOS const: http://golang.org/pkg/runtime/#pkg-constants
It's 2022 and the correct answer for go 1.18+ is:
At runtime you want:
if runtime.GOOS == "windows" {
// windows specific code here...
}
If you need to determine the filesystem path separator character
Use: os.PathSeparator
Examples:
c:\program files
/usr/local/bin
If you need the Path List separator as used by the PATH environment variable
Use: os.PathListSeparator
Examples:
/usr/local/bin:/usr/local:
"C:\windows";"c:\windows\system32";
Since this is an older question and answer I have found another solution.
You could simply use the constants defined in the os package. This const returns a rune so you would need to use string conversion also.
string(os.PathSeparator)
string(os.PathListSeparator)
Example: https://play.golang.org/p/g6jnF7W5_pJ
I just stumbled on this looking for something else and noticed the age of this post so I'll add a more updated addition. If you're just trying to handle the correct filepath I would use filepath.Join(). Its takes all of the guesswork out of os issues. If there is more you need, other than just filepath, using the runtime constants (runtime.GOOS & runtime.GOARCH) are the way to go: playground example
I tested in Go 1.17.1 which really worked for me.
package main
import (
"fmt"
"runtime"
)
func main(){
fmt.Println(runtime.GOOS)
}
Output:
darwin
With regards to detecting the platform, you can use Distribution Detector project to detect the Linux distribution being run.
The first answer from #nemo is the most apropiate, i just wanted to point out that if you are currently a user of gopls language server the build tags may not work as intended.
There's no solution or workaround up to now, the most you can do is change your editor's lsp configs (vscode, neovim, emacs, etc) to select a build tag in order to being able to edit the files with that tag without errors.
Editing files with another tag will not work, and trying to select multiple tags fails as well.
This is the current progress of the issue github#go/x/tools/gopls

cfscript Code Assist in CFBuilder

I'm increasingly using cfscript, and like it where appropriately used.
One problem is that there doesn't appear to be any code assist for cfscript in CF Builder, so I find myself writing the tag of a function to leverage the code Assist, then converting to cfscript (which is silly).
For example:
addParam() is the cfscript equivalent of <cfqueryparam >. I get code assist when writing the the tag version, but not the script equivalent.
Does anyone know if there is a code assist library available for cfscript in cfBuilder? Or is this just a downside of working with cfscript?
Many Thanks in advance!
Jason
Your example is not using native CFScript, it's using the hack-solution Adobe provided for some shortcomings of CFScript's coverage of CF tags, which are implemented as a bunch of CFCs in the custom tags dir of your install. This stuff is not representative of CFML & its CFScript support as a whole.
I find that CFB gives hinting for most native functionality... is this not the case for you? What if you try listAppend() for example? Do you get code-assist for that?
UPDATE
I wonder if you get a warning in CFB on your line equivalent to this:
o = new Query();
? I do, by default. I have to make a link to the CustomTags/com dir, and then use this syntax:
o = new com.adobe.Query();
Then I don't get a warning, and indeed I get the code assist you're expecting. I cannot get it to give me hinting on just the non-qualified path to Query.cfc though.
Not ideal. Or maybe I'm missing something, too.

How could I embedded socket in Lua internally, just like oslib, debuglib?

I want to implement the function like embedding the socket function in my Lua build.
So I don't need to copy socket.core.dll any more (just for fun).
I search the maillist, and see some guys discuss the topic,
http://lua-users.org/lists/lua-l/2005-10/msg00269.html
But I have question for the details steps, who could give me a detailed steps for changing the lua and luasocket code to make them work together (not with dll method).
I tried these steps in windows xp with VC2008:
1) copy luasocket code to Lua project.
2) add some code
static const luaL_Reg lualibs[] = {
{"", luaopen_base},
{LUA_LOADLIBNAME, luaopen_package},
{LUA_TABLIBNAME, luaopen_table},
{LUA_IOLIBNAME, luaopen_io},
{LUA_OSLIBNAME, luaopen_os},
{LUA_STRLIBNAME, luaopen_string},
{LUA_MATHLIBNAME, luaopen_math},
{LUA_DBLIBNAME, luaopen_debug},
{LUA_SOCKETLIBNAME, luaopen_socket_core}, // add this line
{LUA_MIMELIBNAME, luaopen_socket_core}, // add this line
{NULL, NULL}
};
3) build the project, and run it.
When I type print(socket._VERSION), it shows luasocket 2.0.2, it is correct.
When I type print(socket.dns.toip("localhost")), it shows 127.0.0.1 table: 00480AD0, it is correct too.
But when I try to use other features, for example bind, it can't work.
Who could tell me the reason?
you need put luasocket stuff into the package.preload table, in this way:
lua_getfield(L, LUA_GLOBALSINDEX, "package");
lua_getfield(L, -1, "preload");
lua_pushcfunction(L, luaopen_socket_core);
lua_setfield(L, -2, "socket.core");
// add mime.core yourself...
luasocket is a mixed C/lua module, you need to bundle both versions into your application if you want it to work without any extra files.
socket.lua loads socket.core (from socket/core.dll)
mime.lua loads mime.core (from mime/core.dll)
So in order for your application to work you will need to build all the .dll files and the .lua files into your application and manually load them (or set them up to be loaded correctly via custom package loaders).
The email you quoted is tweaking the package.preload table (in a way that appears a tad odd now but might work anyway) to get the built-in C code to be loaded correctly when require is called.
Try running
for k, v in pairs(socket) do print(k, v) end
and maybe we'll be able to help.

gen_bridge_metadata and the iPhone

Is it possible to run gen_bridge_metadata on iPhone frameworks? I keep running into the problem of gen_bridge_metadata not using my preprocessor defines...
So a call like this...
IPHONE_SDK=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.sdk
gen_bridge_metadata -c '-I$IPHONE_SDK/usr/include -DTARGET_OS_IPHONE' --framework "$IPHONE_SDK/System/Library/Frameworks/UIKit.framework"
... will just ignore the TARGET_OS_IPHONE define and try including some MAC_OS files.
No.
Ignoring TARGET_ OS_IPHONE will get you nowhere (as far as I know.)
You can try a third party workaround, mobileOrchard looks into different ones, but I don't think you're getting anywhere. :(