I am trying to define macro that would only expand to anything
if certain cfg option is defined, otherwise it should be no-op,
but I cannot find a way to do it. Pretty much I want some form of #ifdef.
The closest thing I can find is to enclose generated code in a function, and
just do this:
#cfg(
Most of your comments below do not apply to a properly implemented
negative index scheme.
So, it seems clear to me, that I haven't been able to get it across to you.
I guess we can both agree that spending more time on this thread is
unproductive, especially
since the real question is whether
On 04/04/14 04:12 PM, Manu Thambi wrote:
>
> On 04/04/2014 02:51 PM, Daniel Micay wrote:
>>
>> Storing at a negative index removes the cost at indexing, but not
>> elsewhere. It still consumes more memory and makes `push` slower,
>> especially since it has to do more than more offset based on alig
Hello,
I've some problem to find a solution for something I want to do with a
vector of enum. This is an example of what I want to do:
trait Base{
fn set_something(&mut self);
}
struct FirstThink;
impl Base for FirstThink{
fn set_something(&mut self){}
}
struct SecondThink;
On 04/04/2014 02:51 PM, Daniel Micay wrote:
Storing at a negative index removes the cost at indexing, but not
elsewhere. It still consumes more memory and makes `push` slower,
especially since it has to do more than more offset based on alignment
with at least one overflow check.
In the "nega
As you've discovered in bug #13325, dealing with external constants in
static expressions is sometimes a little tricky. I would avoid casting
for now (as happens in the bug) in favor of stronger types. For
example, this compiles and runs for me:
extern {
fn foo();
fn bar();
Is it possible to port the following C code to rust?
__attribute__ ((section(".isr_vector")))
void (* const isr_vector_table[])(void) = {
&_stack_base,
main, // Reset
isr_nmi, // NMI
isr_hardfault,// Hard Fault
0,// CM3 Memory Management
On 04/04/14 01:50 PM, Manu Thambi wrote:
>
> As Nathan mentioned, the capacity is stored at a negative offset to the
> pointer to the heap.
Storing at a negative index removes the cost at indexing, but not
elsewhere. It still consumes more memory and makes `push` slower,
especially since it has to
Thanks for the detailed reply. You clearly have done a lot of work on
the code,
and I have just been following the mailing lists for a while. So, I
might be misunderstanding something here.
On 04/04/2014 11:37 AM, Daniel Micay wrote:
It bloats the code size by requiring extra overflow checks
On 04/04/14 10:51 AM, Manu Thambi wrote:
>
>> Needing to use a header seriously hurts the performance. The new
>> vector is 7x faster at pushing elements when space isn't reserved
>> compared to the old one, all due to leaving off the length/capacity
>> header. The overhead would be less if it sto
Needing to use a header seriously hurts the performance. The new
vector is 7x faster at pushing elements when space isn't reserved
compared to the old one, all due to leaving off the length/capacity
header. The overhead would be less if it stored the capacity inside
*and* outside the vector,
> On 04 Apr 2014, at 12:30, Vadim Chugunov wrote:
>
> Regarding the original idea: Why use a whole bit, when you only need one
> value out of all possible type's values? For example, for floats, one of
> the NaNs could be used for this purpose without any issues with overflow as
> would hap
On 03/04/14 11:48 PM, Nathan Myers wrote:
>
>>> Perhaps the best thing is to wait a month (or two or three) until DST
>>> is more of a reality and then see how we feel.
>>
>> Are you thinking we should also wait before converting the current uses
>> of ~[T] to Vec? Doing the migration gives us the
I've submitted an RFC for this one:
https://github.com/rust-lang/rfcs/pull/29
On Sat, Mar 29, 2014 at 6:14 PM, Bill Myers wrote:
> I think the best solution is to add uN and sN types where N is not a power
> of two, which LLVM should already support.
>
> Then you can write your match like this:
Regarding the original idea: Why use a whole bit, when you only need one
value out of all possible type's values? For example, for floats, one of
the NaNs could be used for this purpose without any issues with overflow as
would happen in your proposal.
Regarding "which types?": Perhaps this sh
Hey folks,
I took the slides from my talk at last week's PDX-Rust meetup & slapped
together a blog post that covers some of the innards of the Rust compiler
in a little more detail:
http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/
It kind of reads somewhere between a high l
Okay. But first I'd like to get some input on for what types T should the
language guarantee this suggested optimization for Option. Because the
optimization could be done for any type T from which at least one or more of
these new primitive data types is accessible. But it's not clear whether o
17 matches
Mail list logo
