Could I ever want to access the address zero?
Neither in C nor in C++ null-pointer value is in any way tied to physical address 0
. The fact that you use constant 0
in the source code to set a pointer to null-pointer value is nothing more than just a piece of syntactic sugar. The compiler is required to translate it into the actual physical address used as null-pointer value on the specific platform.
In other words, 0
in the source code has no physical importance whatsoever. It could have been 42
or 13
, for example. I.e. the language authors, if they so pleased, could have made it so that you'd have to do p = 42
in order to set the pointer p
to null-pointer value. Again, this does not mean that the physical address 42
would have to be reserved for null pointers. The compiler would be required to translate source code p = 42
into machine code that would stuff the actual physical null-pointer value (0x0000
or 0xBAAD
) into the pointer p
. That's exactly how it is now with constant 0
.
Also note, that neither C nor C++ provides a strictly defined feature that would allow you to assign a specific physical address to a pointer. So your question about "how one would assign 0 address to a pointer" formally has no answer. You simply can't assign a specific address to a pointer in C/C++. However, in the realm of implementation-defined features, the explicit integer-to-pointer conversion is intended to have that effect. So, you'd do it as follows
uintptr_t address = 0;
void *p = (void *) address;
Note, that this is not the same as doing
void *p = 0;
The latter always produces the null-pointer value, while the former in general case does not. The former will normally produce a pointer to physical address 0
, which might or might not be the null-pointer value on the given platform.
How do I do a literal *int64 in Go?
The Go Language Specification (Address operators) does not allow to take the address of a numeric constant (not of an untyped nor of a typed constant).
The operand must be addressable, that is, either a variable, pointer indirection, or slice indexing operation; or a field selector of an addressable struct operand; or an array indexing operation of an addressable array. As an exception to the addressability requirement,
x
[in the expression of&x
] may also be a (possibly parenthesized) composite literal.
For reasoning why this isn't allowed, see related question: Find address of constant in go. A similar question (similarly not allowed to take its address): How can I store reference to the result of an operation in Go?
0) Generic solution (from Go 1.18)
Generics are added in Go 1.18. This means we can create a single, generic Ptr()
function that returns a pointer to whatever value we pass to it. Hopefully it'll get added to the standard library. Until then, you can use github.com/icza/gog
, the gog.Ptr()
function (disclosure: I'm the author).
This is how it can look like:
func Ptr[T any](v T) *T {
return &v
}
Testing it:
i := Ptr(2)
log.Printf("%T %v", i, *i)
s := Ptr("abc")
log.Printf("%T %v", s, *s)
x := Ptr[any](nil)
log.Printf("%T %v", x, *x)
Which will output (try it on the Go Playground):
2009/11/10 23:00:00 *int 2
2009/11/10 23:00:00 *string abc
2009/11/10 23:00:00 *interface {} <nil>
Your other options (prior to Go 1.18) (try all on the Go Playground):
1) With new()
You can simply use the builtin new()
function to allocate a new zero-valued int64
and get its address:
instance := SomeType{
SomeField: new(int64),
}
But note that this can only be used to allocate and obtain a pointer to the zero value of any type.
2) With helper variable
Simplest and recommended for non-zero elements is to use a helper variable whose address can be taken:
helper := int64(2)
instance2 := SomeType{
SomeField: &helper,
}
3) With helper function
Note: Helper functions to acquire a pointer to a non-zero value are available in my github.com/icza/gox
library, in the gox
package, so you don't have to add these to all your projects where you need it.
Or if you need this many times, you can create a helper function which allocates and returns an *int64
:
func create(x int64) *int64 {
return &x
}
And using it:
instance3 := SomeType{
SomeField: create(3),
}
Note that we actually didn't allocate anything, the Go compiler did that when we returned the address of the function argument. The Go compiler performs escape analysis, and allocates local variables on the heap (instead of the stack) if they may escape the function. For details, see Is returning a slice of a local array in a Go function safe?
4) With a one-liner anonymous function
instance4 := SomeType{
SomeField: func() *int64 { i := int64(4); return &i }(),
}
Or as a (shorter) alternative:
instance4 := SomeType{
SomeField: func(i int64) *int64 { return &i }(4),
}
5) With slice literal, indexing and taking address
If you would want *SomeField
to be other than 0
, then you need something addressable.
You can still do that, but that's ugly:
instance5 := SomeType{
SomeField: &[]int64{5}[0],
}
fmt.Println(*instance2.SomeField) // Prints 5
What happens here is an []int64
slice is created with a literal, having one element (5
). And it is indexed (0th element) and the address of the 0th element is taken. In the background an array of [1]int64
will also be allocated and used as the backing array for the slice. So there is a lot of boilerplate here.
6) With a helper struct literal
Let's examine the exception to the addressability requirements:
As an exception to the addressability requirement,
x
[in the expression of&x
] may also be a (possibly parenthesized) composite literal.
This means that taking the address of a composite literal, e.g. a struct literal is ok. If we do so, we will have the struct value allocated and a pointer obtained to it. But if so, another requirement will become available to us: "field selector of an addressable struct operand". So if the struct literal contains a field of type int64
, we can also take the address of that field!
Let's see this option in action. We will use this wrapper struct type:
type intwrapper struct {
x int64
}
And now we can do:
instance6 := SomeType{
SomeField: &(&intwrapper{6}).x,
}
Note that this
&(&intwrapper{6}).x
means the following:
& ( (&intwrapper{6}).x )
But we can omit the "outer" parenthesis as the address operator &
is applied to the result of the selector expression.
Also note that in the background the following will happen (this is also a valid syntax):
&(*(&intwrapper{6})).x
7) With helper anonymous struct literal
The principle is the same as with case #6, but we can also use an anonymous struct literal, so no helper/wrapper struct type definition needed:
instance7 := SomeType{
SomeField: &(&struct{ x int64 }{7}).x,
}
Pointers vs. values in parameters and return values
tl;dr:
- Methods using receiver pointers are common; the rule of thumb for receivers is, "If in doubt, use a pointer."
- Slices, maps, channels, strings, function values, and interface values are implemented with pointers internally, and a pointer to them is often redundant.
- Elsewhere, use pointers for big structs or structs you'll have to change, and otherwise pass values, because getting things changed by surprise via a pointer is confusing.
One case where you should often use a pointer:
- Receivers are pointers more often than other arguments. It's not unusual for methods to modify the thing they're called on, or for named types to be large structs, so the guidance is to default to pointers except in rare cases.
- Jeff Hodges' copyfighter tool automatically searches for non-tiny receivers passed by value.
- Jeff Hodges' copyfighter tool automatically searches for non-tiny receivers passed by value.
Some situations where you don't need pointers:
Code review guidelines suggest passing small structs like
type Point struct { latitude, longitude float64 }
, and maybe even things a bit bigger, as values, unless the function you're calling needs to be able to modify them in place.- Value semantics avoid aliasing situations where an assignment over here changes a value over there by surprise.
- Passing small structs by value can be more efficient by avoiding cache misses or heap allocations. In any case, when pointers and values perform similarly, the Go-y approach is to choose whatever provides the more natural semantics rather than squeeze out every last bit of speed.
- So, Go Wiki's code review comments page suggests passing by value when structs are small and likely to stay that way.
- If the "large" cutoff seems vague, it is; arguably many structs are in a range where either a pointer or a value is OK. As a lower bound, the code review comments suggest slices (three machine words) are reasonable to use as value receivers. As something nearer an upper bound,
bytes.Replace
takes 10 words' worth of args (three slices and anint
). You can find situations where copying even large structs turns out a performance win, but the rule of thumb is not to.
For slices, you don't need to pass a pointer to change elements of the array.
io.Reader.Read(p []byte)
changes the bytes ofp
, for instance. It's arguably a special case of "treat little structs like values," since internally you're passing around a little structure called a slice header (see Russ Cox (rsc)'s explanation). Similarly, you don't need a pointer to modify a map or communicate on a channel.For slices you'll reslice (change the start/length/capacity of), built-in functions like
append
accept a slice value and return a new one. I'd imitate that; it avoids aliasing, returning a new slice helps call attention to the fact that a new array might be allocated, and it's familiar to callers.- It's not always practical follow that pattern. Some tools like database interfaces or serializers need to append to a slice whose type isn't known at compile time. They sometimes accept a pointer to a slice in an
interface{}
parameter.
- It's not always practical follow that pattern. Some tools like database interfaces or serializers need to append to a slice whose type isn't known at compile time. They sometimes accept a pointer to a slice in an
Maps, channels, strings, and function and interface values, like slices, are internally references or structures that contain references already, so if you're just trying to avoid getting the underlying data copied, you don't need to pass pointers to them. (rsc wrote a separate post on how interface values are stored).
- You still may need to pass pointers in the rarer case that you want to modify the caller's struct:
flag.StringVar
takes a*string
for that reason, for example.
- You still may need to pass pointers in the rarer case that you want to modify the caller's struct:
Where you use pointers:
Consider whether your function should be a method on whichever struct you need a pointer to. People expect a lot of methods on
x
to modifyx
, so making the modified struct the receiver may help to minimize surprise. There are guidelines on when receivers should be pointers.Functions that have effects on their non-receiver params should make that clear in the godoc, or better yet, the godoc and the name (like
reader.WriteTo(writer)
).You mention accepting a pointer to avoid allocations by allowing reuse; changing APIs for the sake of memory reuse is an optimization I'd delay until it's clear the allocations have a nontrivial cost, and then I'd look for a way that doesn't force the trickier API on all users:
- For avoiding allocations, Go's escape analysis is your friend. You can sometimes help it avoid heap allocations by making types that can be initialized with a trivial constructor, a plain literal, or a useful zero value like
bytes.Buffer
. - Consider a
Reset()
method to put an object back in a blank state, like some stdlib types offer. Users who don't care or can't save an allocation don't have to call it. - Consider writing modify-in-place methods and create-from-scratch functions as matching pairs, for convenience:
existingUser.LoadFromJSON(json []byte) error
could be wrapped byNewUserFromJSON(json []byte) (*User, error)
. Again, it pushes the choice between laziness and pinching allocations to the individual caller. - Callers seeking to recycle memory can let
sync.Pool
handle some details. If a particular allocation creates a lot of memory pressure, you're confident you know when the alloc is no longer used, and you don't have a better optimization available,sync.Pool
can help. (CloudFlare published a useful (pre-sync.Pool
) blog post about recycling.)
- For avoiding allocations, Go's escape analysis is your friend. You can sometimes help it avoid heap allocations by making types that can be initialized with a trivial constructor, a plain literal, or a useful zero value like
Finally, on whether your slices should be of pointers: slices of values can be useful, and save you allocations and cache misses. There can be blockers:
- The API to create your items might force pointers on you, e.g. you have to call
NewFoo() *Foo
rather than let Go initialize with the zero value. - The desired lifetimes of the items might not all be the same. The whole slice is freed at once; if 99% of the items are no longer useful but you have pointers to the other 1%, all of the array remains allocated.
- Copying or moving the values might cause you performance or correctness problems, making pointers more attractive. Notably,
append
copies items when it grows the underlying array. Pointers to slice items from before theappend
may not point to where the item was copied after, copying can be slower for huge structs, and for e.g.sync.Mutex
copying isn't allowed. Insert/delete in the middle and sorting also move items around so similar considerations can apply.
Broadly, value slices can make sense if either you get all of your items in place up front and don't move them (e.g., no more append
s after initial setup), or if you do keep moving them around but you're confident that's OK (no/careful use of pointers to items, and items are small or you've measured the perf impact). Sometimes it comes down to something more specific to your situation, but that's a rough guide.
Is NULL always zero in C?
I'm assuming you mean the null pointer. It is guaranteed to compare equal to 0
.1 But it doesn't have to be represented with all-zero bits.2
See also the comp.lang.c FAQ on null pointers.
- See C99, 6.3.2.3.
- There's no explicit claim; but see the footnote for C99, 7.20.3 (thanks to @birryree in the comments).
How to fix Error: listen EADDRINUSE while using NodeJS?
EADDRINUSE
means that the port number which listen()
tries to bind the server to is already in use.
So, in your case, there must be running a server on port 80 already.
If you have another webserver running on this port you have to put node.js behind that server and proxy it through it.
You should check for the listening
event like this, to see if the server is really listening:
var http=require('http');
var server=http.createServer(function(req,res){
res.end('test');
});
server.on('listening',function(){
console.log('ok, server is running');
});
server.listen(80);
IP-address ending with zero?
An IP address ending in .0
is perfectly legal these days. However, some devices (and firewall policies) believe that it isn't.
In the old "classfull" addressing scheme, IPs from 192.0.0.0 to 223.255.255.255 were considered "class C" space, i.e. they had an implicit subnet mask of 255.255.255.0.
So, back then, you couldn't actually have a .0
host address, because .0
was the "network address". Similarly you couldn't have a .255
address within that range because that was the broadcast address.
About 20 years ago, though, everyone changed to "classless" CIDR style addressing, with variable length subnet masks, and no implicit subnet masks. If you've got a /23
then there shouldn't be any reason why you can't use the .255
that's at the end of the first /24
and the .0
that's at the start of the next.
However, 5+ years ago when I was in the ISP industry our system would happily give out .0
and .255
addresses to end users, but then we found that they couldn't reach Microsoft's websites because they had either broken kit, or overzealous firewall rules. We ended up having to exclude those addresses, even though they're legal.
What is the difference between 0.0.0.0, 127.0.0.1 and localhost?
127.0.0.1
is normally the IP address assigned to the "loopback" or local-only interface. This is a "fake" network adapter that can only communicate within the same host. It's often used when you want a network-capable application to only serve clients on the same host. A process that is listening on 127.0.0.1
for connections will only receive local connections on that socket.
"localhost" is normally the hostname for the 127.0.0.1
IP address. It's usually set in /etc/hosts
(or the Windows equivalent named "hosts" somewhere under %WINDIR%
). You can use it just like any other hostname - try "ping localhost" to see how it resolves to 127.0.0.1
.
0.0.0.0
has a couple of different meanings, but in this context, when a server is told to listen on 0.0.0.0
that means "listen on every available network interface". The loopback adapter with IP address 127.0.0.1
from the perspective of the server process looks just like any other network adapter on the machine, so a server told to listen on 0.0.0.0
will accept connections on that interface too.
That hopefully answers the IP side of your question. I'm not familiar with Jekyll or Vagrant, but I'm guessing that your port forwarding 8080 => 4000
is somehow bound to a particular network adapter, so it isn't in the path when you connect locally to 127.0.0.1
What is the meaning of '*' and '&'?
This is possibly one of the most confusing things in Go. There are basically 3 cases you need to understand:
The &
Operator
&
goes in front of a variable when you want to get that variable's memory address.
The *
Operator
*
goes in front of a variable that holds a memory address and resolves it (it is therefore the counterpart to the &
operator). It goes and gets the thing that the pointer was pointing at, e.g. *myString
.
myString := "Hi"
fmt.Println(*&myString) // prints "Hi"
or more usefully, something like
myStructPointer = &myStruct
// ...
(*myStructPointer).someAttribute = "New Value"
*
in front of a Type
When *
is put in front of a type, e.g. *string
, it becomes part of the type declaration, so you can say "this variable holds a pointer to a string". For example:
var str_pointer *string
So the confusing thing is that the *
really gets used for 2 separate (albeit related) things. The star can be an operator or part of a type.
Related Topics
Iterate Through a C++ Vector Using a 'For' Loop
Osx - Replace Gcc Version 4.2.1 with 4.9 Installed via Homebrew
Restrict C++ Template Parameter to Subclass
C++ Vector, What Happens Whenever It Expands/Reallocate on Stack
How to Create My Own Ostream/Streambuf
Dark Transparent Layer Over a Qmainwindow in Qt
Decltype as a Return Type in Class Member Function
Why Do I Get _Crtisvalidheappointer(Block) And/Or Is_Block_Type_Valid(Header->_Block_Use) Assertions
How to Set the Padding of Qtableview Cells Through CSS
What Does _Declspec(Dllimport) Really Mean
A Good Example for Boost::Algorithm::Join
Compiling External C++ Library for Use with iOS Project