Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

"foo"=="foo"? OH SHI-

Name: Anonymous 2011-12-12 14:07


haxus_the_great@leetbawx: cat anus.c
int main()
{
  if ("foo" == "foo") {
    return 1;
  } else {
    return 0;
  }
}
haxus_the_great@leetbawx: gcc anus.c -o anus
haxus_the_great@leetbawx: ./anus
haxus_the_great@leetbawx: echo $?
1
haxus_the_great@leetbawx:
U mad? U jelly? Come at me bro.

Name: Anonymous 2011-12-12 14:11

>>1
yeah this is how you compare strings in C... what's your point OP?

Name: Anonymous 2011-12-12 14:14

>>2
Is that you, FV?

>>1
I believe compiler optimized it out so both "foo" point at same adress.

Name: Anonymous 2011-12-12 14:18

>>1
Thats a common mistake, strings are handled as pointers to char array which need to be processed by strcmp(str1,str2)

Name: Anonymous 2011-12-12 15:12

>>2,4
...

Name: Anonymous 2011-12-12 15:57

>>3
So whenever the compiler encounters a string literal, it has to search all previous literals in the compilation unit and match against them, just to find out whether it can merge the current one to a previous one?

That's could possibly make compilation slow as fuck.

Name: Anonymous 2011-12-12 16:04


cat t.c
int main()
{
  if ("foo" == "foo") {
    return 1;
  } else {
    return 0;
  }
}

>cat t.s
        .file   "t.c"
        .def    ___main;        .scl    2;      .type   32;     .endef
        .text
        .globl  _main
        .def    _main;  .scl    2;      .type   32;     .endef
_main:
LFB0:
        .cfi_startproc
        pushl   %ebp
        .cfi_def_cfa_offset 8
        .cfi_offset 5, -8
        movl    %esp, %ebp
        .cfi_def_cfa_register 5
        andl    $-16, %esp
        call    ___main
        movl    $1, %eax
        leave
        .cfi_restore 5
        .cfi_def_cfa 4, 4
        ret
        .cfi_endproc
LFE0:

gcc -S is your friend, gcc removed the if statement and just returned 1

>>6
implying gcc compilation is fast to begin with


and no C doesn't compare strings with ==, go back to C++ you moron. == compares pointer values in that case. but as you can see gcc removes it anyway since it knows it'll always return 1

Name: Anonymous 2011-12-12 16:07

>>6 `
>checking if a hash exists in a set is slow[/code]
You're not a programmer, are you?

Name: ENTERPRISE QUALITY STRING 2011-12-12 16:07



/* *********************
  *  SCALABLE SOLUTIONS FOR YOUR BUSINESS, CLOUD CAPABLE AND BOOSTS YOUR EMPLOYEES PRODUCTIVITY BY A 13% MARGIN *
   */
import java.util.*

public class AbstractStringComparator () {
    public static void main(String[] args, AbstractMainBuilder main) {
        private static String anus = new String(StringFactoryFactory.getInstance(StringFactoryFactory.setValue("anus")); // Sets string value to "anus"
        private static String hax = new String(StringFactoryFactory.getInstance(StringFactoryFactory.setValue("hax")); // Sets string value to "hax"
        if (anus.getValue().equals(hax.getValue())) { // Checks if both values are the same
        {
             Object booleanValue = (boolean) new Object(boolean, (boolean) "true"); // Sets value to true
         }
        else
        {
             Object booleanValue = (boolean) new Object(boolean, (boolean) "false"); // Sets value to false
        } // Ends condition
        return (boolean) AbstractBooleanBeansContainer(booleanValue.getValue());
}

Name: Anonymous 2011-12-12 17:06

>>7
GNU/Assembler
Make me unsee.

Name: Anonymous 2011-12-12 17:18

>>10
GNU/Buttembler

Name: Anonymous 2011-12-12 17:32

>>6
it's called "string pooling" and every decent compiler (actually, linker) does that

Name: Anonymous 2011-12-12 17:34

>>6
O(1) is usually considered fast bro

Name: Anonymous 2011-12-12 17:37

>>12
I'm sure this kind of optimisation affects any values, not only strings.

>>13
Still, C++ (not sure about C) compilers are known as very slow.

Name: Anonymous 2011-12-12 17:43

>>14
The reason C++ compilers are slow isn't because of O(1) hash lookups though, trust me bro.

Name: Anonymous 2011-12-12 18:28

>>15
Yeah, I haven't denied that! Just wanted to mention that there are another problems with C++ compilers.

Name: Anonymous 2011-12-12 19:02


~/host/prog$ cat test.c
int main()
{
  if ("foo" == "foo") {
    return 1;
  } else {
    return 0;
  }
}
~/host/prog$ cat test.s
        .file   "test.c"
        .text
.globl main
        .type   main, @function
main:
.LFB0:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        movq    %rsp, %rbp
        .cfi_offset 6, -16
        .cfi_def_cfa_register 6
        movl    $1, %eax
        leave
        ret
        .cfi_endproc
.LFE0:
        .size   main, .-main
        .ident  "GCC: (Debian 4.4.5-8) 4.4.5"
        .section        .note.GNU-stack,"",@progbits


why is windows gcc bloat

Name: Anonymous 2011-12-12 20:47


TITLE    foo.c
    .386P
    .model FLAT
PUBLIC    _main
;    COMDAT _main
_TEXT    SEGMENT
_main    PROC NEAR                    ; COMDAT
; File foo.c
; Line 4
    push    1
    pop    eax
; Line 8
    ret    0
_main    ENDP
_TEXT    ENDS
END
lol MSVC6

Name: Anonymous 2011-12-12 21:33

>>18
gcc is bloated compared to that.

Why does it label it's own lines tho?

Name: Anonymous 2011-12-13 2:15

>>8
>implying compilers rely on hashes
>implying hashes can't ever collide
>implying people wouldn't die when a heartbeater is in error because shitty compiler resorted to using hashes
ISHYGDDT

Name: Anonymous 2011-12-13 2:17

>>20`
>implying
>implying >implying
>implying >implying >implying >implying
>implying >implying >implying >implying >implying >implying >implying >implying
>implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying
>implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying
>implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying
>implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying
>implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying >implying

Name: Anonymous 2011-12-13 3:30

>>20
You don't know how to implement a hash table, do you?

Name: Anonymous 2011-12-13 3:38

>>22
You can implement a hash table, but looking up shit from it is not constant. Hash table lookup's complexity is O(n) in average and worst cases due to collisions and chaining that's usually done with linked lists.
 
Yes, I said average case is linear. Hash table has fixed amount of buckets, and given massive enough input it just degenerates to a linked list with several buckets. This is really elementary stuff isn't it?

Ergo, deal with it.

Name: Anonymous 2011-12-13 3:55

>>23
I see you haven't read TAoCP.

Name: Anonymous 2011-12-13 4:07

>>23
Ahve you red you're TAoCP today?

Name: Anonymous 2011-12-13 5:15

>>23
You can implement a hash table, but looking up shit from it is not constant.
Yes it is.

Name: Anonymous 2011-12-13 5:15

>>24
You can achieve some sort of amortized constant complexity if you restructure the hash table after each 2N additions to the table.

Enjoy you're "constant" time when you have a hundred million entries in the table and it happens to start restucturing.

Name: Anonymous 2011-12-13 5:17

>>26
No it's not. If the load factor of the table is through the roof, it's SAF.

http://en.wikipedia.org/wiki/Hash_table#Separate_chaining

Name: Anonymous 2011-12-13 5:19

>>28
You don't understand average case versus worst case analysis?

Name: Anonymous 2011-12-13 5:21

>>29
Always prepare for worst! That's how I code!

Name: Anonymous 2011-12-13 5:23

>>30
Silly Anonymous, always uses balanced trees instead of hashing because of O(log(n)) worst case performance.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-13 5:24

Arrays are safer,more reliable in their simplicity and their access time is constant

Name: Anonymous 2011-12-13 5:25

>>32
Regular arrays are unsafe because they don't warn you when you step out of bounds.

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-13 5:28

>>33
Add bound checks, if ((accessed_element) >MAX_SIZE){; ERROR("ARRAY ACCESS INVALID");}

Name: Anonymous 2011-12-13 8:03

>>34
[code]
#include <void.h>
u4 MAX_SIZE = 10;
u4 REAL_SIZE = 0;
u4 EMPTY = 0;
void del(int * a, u4 i) {
  a[i] = NULL;
  EMPTY = i;
}
void add(int * a, u4 v) {
  if (REAL_SIZE + 10 > MAX_SIZE) {
    MAX_SIZE += 10;
    a = realloc(a, MAX_SIZE);
  }
  a[EMPTY]=v;
  REAL_SIZE++;
  while (a[++EMPTY]);
}
int get(int * a, int accessed_element) {
  if ((accessed_element) > MAX_SIZE){; ERROR("ARRAY ACCESS INVALID");}
  return a[accessed_element];
}
STDMAIN
  int * a = calloc(MAX_SIZE, sizeof(int));
  add(a, 24);
  del(a, 0);
  if (*get(a, 0)) puts("FV wins");
STDEND

Name: Anonymous 2011-12-13 8:04

>>35
two bugs

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-13 8:17

>>35
Thats not exactly what i had in mind, i don't make it a function, its just a macro.
#define MAX_SIZE 4096
#define ARRAY_NULL 2147483647
#define ERROR
#define intarr(X) calloc(MAX_SIZE,sizeof(int))
#define ADD(array,elm) ;array##_real_size++;array[array##_real_size]=elm;
#define DEL(array,el_num) ;array[el_num]=ARRAY_NULL;
#define GET(array,el_num) el_num>array##_real_size?ARRAY_NULL:array[el_num]
#define ERROR(val,x) if(val==ARRAY_NULL){puts(x);}

Name: Anonymous 2011-12-13 8:21

>>35
FV trying to use code tags

Name: F r o z e n V o i d !!mJCwdV5J0Xy2A21 2011-12-13 8:21

should be  array[array##_real_size++]=elm;

Name: Anonymous 2011-12-13 8:22

>>38
iteration: worse than in a linked list

Name: Anonymous 2011-12-13 8:23

>>38
Lol'd HarD

Name: Anonymous 2011-12-13 8:28

>>41
Lol'd SofT

Name: Anonymous 2011-12-13 9:43

>>20
Oh no, hash collision! The shitty /prog/rider didn't store his hashed objects in a linked list, did he?

Name: Anonymous 2011-12-14 15:48

>>37
#define ARRAY_NULL 2147483647

What the fu... Oh, it's just FrozenFurry

Name: Anonymous 2011-12-14 16:54

if you want FAST AS FUCK hashes, look no further than python

Name: Anonymous 2011-12-14 17:02

>>45
Ditto for FAST AS FUCK sort. If I recall correctly, Oracle pulled it into the official Java implementation.

Name: Anonymous 2011-12-14 17:51

>>44
#define ARRAY_NULL (rand())

Name: Anonymous 2011-12-14 19:33

>>44
Well, EOF is -1 on a lot of implementations.

Name: Anonymous 2011-12-14 23:39

>>48
And using it would... god forbid, actually make the code portable!
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -