These are chat archives for rust-lang/rust
Anyone know why my gtk-rs app is getting progressively slower as the app lives?
After around 30s - 1min the front end (GTK) starts to lag like crazy or outright freeze
u64seems like an overkill...
&mut [u8], and a higher-level layer could then choose appropriate buffer (either stack allocated or heap allocated).
Like, if you statically know that you are expecting
u64, it should be possible to use
[u8; 8]. But I am probably wrong, because I don't know the precise API here :)
Though byteorder is defenitelly the best way to go from
[u8] to primitives.
How does this works
let mut rdr = Cursor::new(vec![2, 5, 3, 0]); assert_eq!(0x8, rdr.read_u64::<BigEndian>().unwrap()
compared to a
unsigned char buffer; unsigned int64 = (unsigned int64) buffer;
to_leare build in since 1.0! Thanks a lot for pointing that out @jplatte ! All this time ignorant me was sure that there's a macro generated loop with
<<8somewhere inside byteorder...
swap_bytesyet... But I'd still assume that it is as efficient as is possible
core::intrinsics, so it goes directly into LLVM I think
tokio_core::net::TcpStreamwhich gives me
FramedReader/Writer) and on the other handside I need to run my main loop
@arielb1 Uhm it's defined like this on the rust side
#[link_name="wglGetProcAddress"] pub fn GetProcAddress(lpszProc: types::LPCSTR) -> types::PROC;
but don't know where to search for
PROC in the windows files..
types::PROCis the same as you posted above
#[repr(C)] struct Function; *const Functionor whatever
#ifdef _WIN64 typedef INT_PTR (FAR WINAPI *FARPROC)(); typedef INT_PTR (NEAR WINAPI *NEARPROC)(); typedef INT_PTR (WINAPI *PROC)(); #else typedef int (FAR WINAPI *FARPROC)(); typedef int (NEAR WINAPI *NEARPROC)(); typedef int (WINAPI *PROC)(); #endif // _WIN64 #else typedef int (CALLBACK *FARPROC)(); typedef int (CALLBACK *NEARPROC)(); typedef int (CALLBACK *PROC)(); #endif #if _MSC_VER >= 1200 #pragma warning(pop) #endif #else typedef INT_PTR (WINAPI *FARPROC)(void); typedef INT_PTR (WINAPI *NEARPROC)(void); typedef INT_PTR (WINAPI *PROC)(void); #endif
GetProcAddresswhen we see it returns a function pointer
test::black_box(|| GetProcAddress() as *const ())
running: "make" "build_lib_static" "-j" "16" command did not execute successfully: "make" "build_lib_static" "-j" "16" expected success, got: exit code: 2 --- stderr make: *** No rule to make target '/home/paulf/rust2/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c', needed by 'src/jemalloc.o'. Stop.
fn from_str<'a, T>(s: &'a str) -> Result<T><- what if my T needs to live for longer than my string?
Resultis created inside of the fn and does not use data borrowed from
strdoes not live live long enough, and must be valid for the static lifetime