Hi all,
While working on a parser, I've repeatedly encountered patterns like:
if c == ' ' || c == '\t' { /* handle whitespace */ }
if token == EOL || token == EOF { /* handle end markers */ }
if lexer.Type == TextLine || lexer.Type == WhitespaceLine { /* handle lines
*/ }
Go already al
On Tue, Mar 18, 2025 at 12:08 AM Jason E. Aten wrote:
>
> I'm porting some C code that does manual filesystem "extent"
> file space management from Linux to Darwin (and into Go).
>
> The Linux fallocate() call and its FALLOC_FL_INSERT_RANGE
> operation are not directly available on Darwin, but sug
Ok, seem to have got it,
I need to change function signature in the DLL to be pointers instead of go
objects.
Ex.
```
//export Run1
func Run1(ptext *byte) (stdout []byte, stderr []byte, err error) {
text := windows.BytePtrToString(ptext)
fmt.Println(text)
return nil, nil, nil
}
On Tue, Mar 18, 2025 at 4:51 PM Mike Schinkel wrote:
>
> While working on a parser, I've repeatedly encountered patterns like:
>
>if c == ' ' || c == '\t' { /* handle whitespace */ }
>if token == EOL || token == EOF { /* handle end markers */ }
>if lexer.Type == TextLine || lexer.Type
Why not use something like
if token.in(EOL,EOF) …
with varadic args this is trivial.
And with generics you probably only need to write a single ‘in’ function
(haven’t tested).
> On Mar 18, 2025, at 6:50 PM, Mike Schinkel wrote:
>
> Hi all,
>
> While working on a parser, I've repeatedly en
I have a DLL compiled with CGO. It exports 3 functions:
```
//export Run1
func Run(text string) (stdout []byte, stderr []byte, err error) {
fmt.Println(text)
return nil, nil, nil
}
//export Run2
func Run2() (stdout []byte, stderr []byte, err error) {
fmt.Println("Hey")
fmt.Prin
Inline cost is part of how Go decides what funcs to inline. There are some
interesting patterns (maybe even idioms?) in Go that specifically try to
inline a lot of code to prevent values from escaping to the heap when they
don't have to. Concrete examples from -gcflags='-m -m':
./main.go:7:6: c
s/code/cost
On Tuesday, March 18, 2025 at 10:22:48 PM UTC+8 tapi...@gmail.com wrote:
> Inline cost is estimated at compile time, not the real code.
>
> But I sorry to say "*new(T) has a smaller inline cost than T{}". it is a
> little larger in fact.
> The inline cost of new(T) is smaller than T{
See the section wrapped in """ in Jan's reply. Quoted differently:
> A parsing ambiguity arises when a composite literal using the TypeName
form of the LiteralType appears as an operand between the keyword and the
opening brace of the block of an "if", "for", or "switch" statement, and
the comp
I couldn't find a clear answer to my question. I didn't see what I was
supposed to find in the reference manual.
On my side I understood that the {} caused an ambiguity with the { of the
if clause. The ambiguity is removed by putting the expression in
parenthesis.
if (v == Version{}) {. // <-
On Tue, Mar 18, 2025 at 8:28 AM Jason E. Aten wrote:
> Thank you so much, Ian.
>
> On Tuesday, March 18, 2025 at 2:21:37 PM UTC Ian Lance Taylor wrote:
>
> Or in this case it seems simpler to just use the unix.FcntlFstore
> function which already exists and does the right thing.
>
>
> I think I m
Inline cost is estimated at compile time, not the real code.
But I sorry to say "*new(T) has a smaller inline cost than T{}". it is a
little larger in fact.
The inline cost of new(T) is smaller than T{}. I got it mixed up.
On Tuesday, March 18, 2025 at 2:39:19 PM UTC+8 Dan Kortschak wrote:
>
12 matches
Mail list logo
