Search Results

Search found 88 results on 4 pages for 'dereference'.

Page 4/4 | < Previous Page | 1 2 3 4 

  • Indices instead of pointers in STL containers?

    - by zvrba
    Due to specific requirements [*], I need a singly-linked list implementation that uses integer indices instead of pointers to link nodes. The indices are always interpreted with respect to a vector containing the list nodes. I thought I might achieve this by defining my own allocator, but looking into the gcc's implementation of , they explicitly use pointers for the link fields in the list nodes (i.e., they do not use the pointer type provided by the allocator): struct _List_node_base { _List_node_base* _M_next; ///< Self-explanatory _List_node_base* _M_prev; ///< Self-explanatory ... } (For this purpose, the allocator interface is also deficient in that it does not define a dereference function; "dereferencing" an integer index always needs a pointer to the underlying storage.) Do you know a library of STL-like data structures (i am mostly in need of singly- and doubly-linked list) that use indices (wrt. a base vector) instead of pointers to link nodes? [*] Saving space: the lists will contain many 32-bit integers. With two pointers per node (STL list is doubly-linked), the overhead is 200%, or 400% on 64-bit platform, not counting the overhead of the default allocator.

    Read the article

  • How do you use boost iterators

    - by Neil G
    It worked, and then I added the typedefs so that I could have a const_sparse_iterator as well. Now, when I compile this and try to use sparse_iterator, it says: /Users/neilrg/nn/src/./core/sparse_vector.h:331: error: invalid use of incomplete type 'struct sparse_vector<A>::sparse_iterator' Here's the code. More code here. tempalte<typename T> class sparse_vector { // There is more code at my previous question, but this might be enough...? private: template<typename base_type> class sparse_iterator_private : public boost::iterator_adaptor< sparse_iterator_private<base_type> // Derived , base_type // Base , value_type // Value , boost::random_access_traversal_tag // CategoryOrTraversal > { private: struct enabler {}; // a private type avoids misuse public: sparse_iterator_private() : sparse_iterator_private<base_type>::iterator_adaptor_(0) {} explicit sparse_iterator_private(typename array_type::iterator&& p) : sparse_iterator_private<base_type>::iterator_adaptor_(p) {} private: friend class boost::iterator_core_access; reference dereference() const { return this->base()->value; } }; public: typedef sparse_iterator_private<typename array_type::iterator> sparse_iterator; typedef sparse_iterator_private<typename array_type::const_iterator> const_sparse_iterator; };

    Read the article

  • C++ Virtual Methods for Class-Specific Attributes or External Structure

    - by acanaday
    I have a set of classes which are all derived from a common base class. I want to use these classes polymorphically. The interface defines a set of getter methods whose return values are constant across a given derived class, but vary from one derived class to another. e.g.: enum AVal { A_VAL_ONE, A_VAL_TWO, A_VAL_THREE }; enum BVal { B_VAL_ONE, B_VAL_TWO, B_VAL_THREE }; class Base { //... virtual AVal getAVal() const = 0; virtual BVal getBVal() const = 0; //... }; class One : public Base { //... AVal getAVal() const { return A_VAL_ONE }; BVal getBVal() const { return B_VAL_ONE }; //... }; class Two : public Base { //... AVal getAVal() const { return A_VAL_TWO }; BVal getBVal() const { return B_VAL_TWO }; //... }; etc. Is this a common way of doing things? If performance is an important consideration, would I be better off pulling the attributes out into an external structure, e.g.: struct Vals { AVal a_val; VBal b_val; }; storing a Vals* in each instance, and rewriting Base as follows? class Base { //... public: AVal getAVal() const { return _vals->a_val; }; BVal getBVal() const { return _vals->b_val; }; //... private: Vals* _vals; }; Is the extra dereference essentially the same as the vtable lookup? What is the established idiom for this type of situation? Are both of these solutions dumb? Any insights are greatly appreciated

    Read the article

  • Why do I get "request for member in something not a struct or union" from this code?

    - by pyroxene
    I'm trying to teach myself C by coding up a linked list. I'm new to pointers and memory management and I'm getting a bit confused. I have this code: /* Remove a node from the list and rejiggle the pointers */ void rm_node(struct node **listP, int index) { struct node *prev; struct node *n = *listP; if (index == 0) { *listP = *listP->next; free(n); return; } for (index; index > 0; index--) { n = n->next; if (index == 2) { prev = n; } } prev->next = n->next; free(n); } to remove an element from the list. If I want to remove the first node, I still need some way of referring to the list, which is why the listP arg is a double pointer, so it can point to the first element of the list and allow me to free the node that used to be the head. However, when I try to dereference listP to access the pointer to the next node, the compiler tells me error: request for member ‘next’ in something not a structure or union . What am I doing wrong here? I think I might be hopelessly mixed up..?

    Read the article

  • How can I pass an array resulting from a Perl method by reference?

    - by arareko
    Some XML::LibXML methods return arrays instead of references to arrays. Instead of doing this: $self->process_items($xml->findnodes('items/item')); I want to do something like: $self->process_items(\$xml->findnodes('items/item')); So that in process_items() I can dereference the original array instead of creating a copy: sub process_items { my ($self, $items) = @_; foreach my $item (@$items) { # do something... } } I can always store the results of findnodes() into an array and then pass the array reference to my own method, but let's say I want to try a reduced version of my code. Is that the correct syntax for passing the method results or should I use something different? Thanks! EDIT: Now suppose I want to change process_items() to process_item() so I can do stuff on a single element of the referenced array inside a loop. Something like: $self->process_item($_) for ([ $xml->findnodes('items/item') ]); This doesn't work as process_item() is executed only once because a single value is passed to the for loop (the reference to the array from findnodes()). What's the proper way of using $_ in this case?

    Read the article

  • Why won't my code segfault on Windows 7?

    - by Trevor
    This is an unusual question to ask but here goes: In my code, I accidentally dereference NULL somewhere. But instead of the application crashing with a segfault, it seems to stop execution of the current function and just return control back to the UI. This makes debugging difficult because I would normally like to be alerted to the crash so I can attach a debugger. What could be causing this? Specifically, my code is an ODBC Driver (ie. a DLL). My test application is ODBC Test (odbct32w.exe) which allows me to explicitly call the ODBC API functions in my DLL. When I call one of the functions which has a known segfault, instead of crashing the application, ODBC Test simply returns control to the UI without printing the result of the function call. I can then call any function in my driver again. I do know that technically the application calls the ODBC driver manager which loads and calls the functions in my driver. But that is beside the point as my segfault (or whatever is happening) causes the driver manager function to not return either (as evidenced by the application not printing a result). One of my co-workers with a similar machine experiences this same problem while another does not but we have not been able to determine any specific differences.

    Read the article

  • How to interpret kernel panics?

    - by Owen
    Hi all, I'm new to linux kernel and could barely understand how to debug kernel panics. I have this error below and I don't know where in the C code should I start checking. I was thinking maybe I could echo what functions are being called so I could check where in the code is this null pointer dereferenced. What print function should I use ? How do you interpret the error message below? Unable to handle kernel NULL pointer dereference at virtual address 0000000d pgd = c7bdc000 [0000000d] *pgd=4785f031, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT Modules linked in: bcm5892_secdom_fw(P) bcm5892_lcd snd_bcm5892 msr bcm5892_sci bcm589x_ohci_p12 bcm5892_skeypad hx_decoder(P) pinnacle hx_memalloc(P) bcm_udc_dwc scsi_mod g_serial sd_mod usb_storage CPU: 0 Tainted: P (2.6.27.39-WR3.0.2ax_standard #1) PC is at __kmalloc+0x70/0xdc LR is at __kmalloc+0x48/0xdc pc : [c0098cc8] lr : [c0098ca0] psr: 20000093 sp : c7a9fd50 ip : c03a4378 fp : c7a9fd7c r10: bf0708b4 r9 : c7a9e000 r8 : 00000040 r7 : bf06d03c r6 : 00000020 r5 : a0000093 r4 : 0000000d r3 : 00000000 r2 : 00000094 r1 : 00000020 r0 : c03a4378 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387d Table: 47bdc008 DAC: 00000015 Process sh (pid: 1088, stack limit = 0xc7a9e260) Stack: (0xc7a9fd50 to 0xc7aa0000) fd40: c7a6a1d0 00000020 c7a9fd7c c7ba8fc0 fd60: 00000040 c7a6a1d0 00000020 c71598c0 c7a9fd9c c7a9fd80 bf06d03c c0098c64 fd80: c71598c0 00000003 c7a6a1d0 bf06c83c c7a9fdbc c7a9fda0 bf06d098 bf06d008 fda0: c7159880 00000000 c7a6a2d8 c7159898 c7a9fde4 c7a9fdc0 bf06d130 bf06d078 fdc0: c79ca000 c7159880 00000000 00000000 c7afbc00 c7a9e000 c7a9fe0c c7a9fde8 fde0: bf06d4b4 bf06d0f0 00000000 c79fd280 00000000 0f700000 c7a9e000 00000241 fe00: c7a9fe3c c7a9fe10 c01c37b4 bf06d300 00000000 c7afbc00 00000000 00000000 fe20: c79cba84 c7463c78 c79fd280 c7473b00 c7a9fe6c c7a9fe40 c00a184c c01c35e4 fe40: 00000000 c7bb0005 c7a9fe64 c79fd280 c7463c78 00000000 c00a1640 c785e380 fe60: c7a9fe94 c7a9fe70 c009c438 c00a164c c79fd280 c7a9fed8 c7a9fed8 00000003 fe80: 00000242 00000000 c7a9feb4 c7a9fe98 c009c614 c009c2a4 00000000 c7a9fed8 fea0: c7a9fed8 00000000 c7a9ff64 c7a9feb8 c00aa6bc c009c5e8 00000242 000001b6 fec0: 000001b6 00000241 00000022 00000000 00000000 c7a9fee0 c785e380 c7473b00 fee0: d8666b0d 00000006 c7bb0005 00000300 00000000 00000000 00000001 40002000 ff00: c7a9ff70 c79b10a0 c79b10a0 00005402 00000003 c78d69c0 ffffff9c 00000242 ff20: 000001b6 c79fd280 c7a9ff64 c7a9ff38 c785e380 c7473b00 00000000 00000241 ff40: 000001b6 ffffff9c 00000003 c7bb0000 c7a9e000 00000000 c7a9ff94 c7a9ff68 ff60: c009c128 c00aa380 4d18b5f0 08000000 00000000 00071214 0007128c 00071214 ff80: 00000005 c0027ee4 c7a9ffa4 c7a9ff98 c009c274 c009c0d8 00000000 c7a9ffa8 ffa0: c0027d40 c009c25c 00071214 0007128c 0007128c 00000241 000001b6 00000000 ffc0: 00071214 0007128c 00071214 00000005 00073580 00000003 000713e0 400010d0 ffe0: 00000001 bef0c7b8 000269cc 4d214fec 60000010 0007128c 00000000 00000000 Backtrace: [] (__kmalloc+0x0/0xdc) from [] (gs_alloc_req+0x40/0x70 [g_serial]) r8:c71598c0 r7:00000020 r6:c7a6a1d0 r5:00000040 r4:c7ba8fc0 [] (gs_alloc_req+0x0/0x70 [g_serial]) from [] (gs_alloc_requests+0x2c/0x78 [g_serial]) r7:bf06c83c r6:c7a6a1d0 r5:00000003 r4:c71598c0 [] (gs_alloc_requests+0x0/0x78 [g_serial]) from [] (gs_start_io+0x4c/0xac [g_serial]) r7:c7159898 r6:c7a6a2d8 r5:00000000 r4:c7159880 [] (gs_start_io+0x0/0xac [g_serial]) from [] (gs_open+0x1c0/0x224 [g_serial]) r9:c7a9e000 r8:c7afbc00 r7:00000000 r6:00000000 r5:c7159880 r4:c79ca000 [] (gs_open+0x0/0x224 [g_serial]) from [] (tty_open+0x1dc/0x314) [] (tty_open+0x0/0x314) from [] (chrdev_open+0x20c/0x22c) [] (chrdev_open+0x0/0x22c) from [] (__dentry_open+0x1a0/0x2b8) r8:c785e380 r7:c00a1640 r6:00000000 r5:c7463c78 r4:c79fd280 [] (__dentry_open+0x0/0x2b8) from [] (nameidata_to_filp+0x38/0x50) [] (nameidata_to_filp+0x0/0x50) from [] (do_filp_open+0x348/0x6f4) r4:00000000 [] (do_filp_open+0x0/0x6f4) from [] (do_sys_open+0x5c/0x170) [] (do_sys_open+0x0/0x170) from [] (sys_open+0x24/0x28) r8:c0027ee4 r7:00000005 r6:00071214 r5:0007128c r4:00071214 [] (sys_open+0x0/0x28) from [] (ret_fast_syscall+0x0/0x2c) Code: e59c4080 e59c8090 e3540000 159c308c (17943103) ---[ end trace be196e7cee3cb1c9 ]--- note: sh[1088] exited with preempt_count 2 process '-/bin/sh' (pid 1088) exited. Scheduling for restart. Welcome to Wind River Linux

    Read the article

  • string s; &s+1; Legal? UB?

    - by John Dibling
    Consider the following code: #include <cstdlib> #include <iostream> #include <string> #include <vector> #include <algorithm> using namespace std; int main() { string myAry[] = { "Mary", "had", "a", "Little", "Lamb" }; const size_t numStrs = sizeof(myStr)/sizeof(myAry[0]); vector<string> myVec(&myAry[0], &myAry[numStrs]); copy( myVec.begin(), myVec.end(), ostream_iterator<string>(cout, " ")); return 0; } Of interest here is &myAry[numStrs]: numStrs is equal to 5, so &myAry[numStrs] points to something that doesn't exist; the sixth element in the array. There is another example of this in the above code: myVec.end(), which points to one-past-the-end of the vector myVec. It's perfecly legal to take the address of this element that doesn't exist. We know the size of string, so we know where the address of the 6th element of a C-style array of strings must point to. So long as we only evaluate this pointer and never dereference it, we're fine. We can even compare it to other pointers for equality. The STL does this all the time in algorithms that act on a range of iterators. The end() iterator points past the end, and the loops keep looping while a counter != end(). So now consider this: #include <cstdlib> #include <iostream> #include <string> #include <vector> #include <algorithm> using namespace std; int main() { string myStr = "Mary"; string* myPtr = &myStr; vector<string> myVec2(myPtr, &myPtr[1]); copy( myVec2.begin(), myVec2.end(), ostream_iterator<string>(cout, " ")); return 0; } Is this code legal and well-defined? It is legal and well-defined to take the address of an array element past the end, as in &myAry[numStrs], so should it be legal and well-defined to pretend that myPtr is also an array?

    Read the article

  • How do you return a string from a function correctly in Dynamic C?

    - by aquanar
    I have a program I am trying to debug, but Dynamic C apparently treats strings differently than normal C does (well, character arrays, anyway). I have a function that I made to make an 8 character long (well, 10 to include the \0 ) string of 0s and 1s to show me the contents of an 8-bit char variable. (IE, I give it the number 13, it returns the string "0001101\0" ) When I use the code below, it prints out !{happy face] 6 times (well, the second one is the happy face alone for some reason), each return comes back as 0xDEAE or "!\x02. I thought it would dereference it and return the appropriate string, but it appears to just be sending the pointer and attempting to parse it. This may seem silly, but my experience was actually in C++ and Java, so going back to C brings up a few issues that were dealt with in later programming languages that I'm not entirely sure how to deal with (like the lack of string variables). How could I fix this code, or how would be a better way to do what I am trying to do (I thought maybe sending in a pointer to a character array and working on it from the function might work, but I thought I should ask to see if maybe I'm just trying to reinvent the wheel). Currently I have it set up like this: this is an excerpt from the main() display[0] = '\0'; for(i=0;i<6;i++) { sprintf(s, "%s ", *char_to_bits(buffer[i])); strcat(display, s); } DispStr(8,5, display); and this is the offending function: char *char_to_bits(char x) { char bits[16]; strcpy(bits,"00000000\0"); if (x & 0x01) bits[7]='1'; if (x & 0x02) bits[6]='1'; if (x & 0x04) bits[5]='1'; if (x & 0x08) bits[4]='1'; if (x & 0x10) bits[3]='1'; if (x & 0x20) bits[2]='1'; if (x & 0x40) bits[1]='1'; if (x & 0x80) bits[0]='1'; return bits; } and just for the sake of completion, the other function is used to output to the stdio window at a specific location: void DispStr(int x, int y, char *s) { x += 0x20; y += 0x20; printf ("\x1B=%c%c%s", x, y, s); }

    Read the article

  • Is it possible to repair a Cisco 3500 XL (3548) switch with POST Error messages?

    - by Alex
    I've got an old Cisco 3500 XL, and it seems to have hardware issues. I've loaded the latest IOS and cleared all config. Does anyone have any experience fixing the switch core? I'm a reasonably competent SMD solderer, can I replace/reflow some chips? I've checked the power supply voltages and it's all within tolerance, and no visible signs of any component damage. Some chips are hot to the touch. I understand that these were EOL as of 2007, but should have a lifetime warranty for the electronics. I don't have a Cisco support contract, so I can't file a ticket. What should I do? Console output: switch: dir flash: Directory of flash:/ 2 -rwx 1811584 <date> c3500xl-c3h2s-mz.120-5.WC17.bin 1799680 bytes available (1812992 bytes used) switch: boot Loading "flash:c3500xl-c3h2s-mz.120-5.WC17.bin"...################################################################################################################################################################################### File "flash:c3500xl-c3h2s-mz.120-5.WC17.bin" uncompressed and installed, entry point: 0x3000 executing... Restricted Rights Legend Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013. cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706 Cisco Internetwork Operating System Software IOS (tm) C3500XL Software (C3500XL-C3H2S-M), Version 12.0(5)WC17, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2007 by cisco Systems, Inc. Compiled Tue 13-Feb-07 15:04 by antonino Image text-base: 0x00003000, data-base: 0x00352924 Initializing C3500XL flash... flashfs[1]: 1 files, 1 directories flashfs[1]: 0 orphaned files, 0 orphaned directories flashfs[1]: Total bytes: 3612672 flashfs[1]: Bytes used: 1812992 flashfs[1]: Bytes available: 1799680 flashfs[1]: flashfs fsck took 3 seconds. flashfs[1]: Initialization complete. ...done Initializing C3500XL flash. C3500XL POST: System Board Test: Passed C3500XL POST: Daughter Card Test: Passed C3500XL POST: CPU Buffer Test: Passed C3500XL POST: CPU Notify RAM Test: Passed C3500XL POST: CPU Interface Test: Passed C3500XL POST: Testing Switch Core: Passed Error with Switch Core BIST test Phase 0. Returns: Test Complete Low : 0x0FFFFFFF, Test Complete High : 0xFFFFFFFE Test Phase Low : 0x00000040, Test Phase High : 0x00000000 Test Phase Third : 0x00000000, Test Complete Third : 0x000001F8 C3500XL POST FAILURE: Testing Switch Core: Failed C3500XL POST FAILURE: Testing Buffer Table: Failed C3500XL POST FAILURE: Data Buffer Test: Failed C3500XL POST FAILURE: Configuring Switch Parameters: Failed C3500XL POST FAILURE: Switch Core BIST failed. C3500XL POST FAILURE: Cannot test Modules due to failure of Switch Core POST Del Mar Failure (0th Del Mar): req system failed to init C3500XL POST FAILURE: C3500XL POST FAILURE: ATM: required system failed to init C3500XL POST: Ethernet Controller Test: Passed C3500XL POST FAILURE: MII Test: Failed C3500XL POST FAILURE: Error waiting for Ethernet Controller and SW_PARAMS C3500XL POST FAILURE: Initialization/POST failed C3500XL POST FAILURE: AT: Failing because system POST failed Exception (8192)! Debug Exception (Could be NULL pointer dereference) CPU Register Context: Vector = 0x00002000 PC = 0x000F36F4 MSR = 0x00029200 CR = 0x22000024 LR = 0x000F6964 CTR = 0x001DE46C XER = 0x00000000 R0 = 0x00000000 R1 = 0x004E2580 R2 = 0x00000000 R3 = 0x00000000 R4 = 0x00000001 R5 = 0x00000000 R6 = 0x004E2718 R7 = 0x004E2718 R8 = 0x00000008 R9 = 0x00000000 R10 = 0x0000FFFF R11 = 0x00480000 R12 = 0x42000024 R13 = 0x00000000 R14 = 0x00000000 R15 = 0x00000000 R16 = 0x00000000 R17 = 0x00000000 R18 = 0x00000000 R19 = 0x00000000 R20 = 0x00000000 R21 = 0x00000000 R22 = 0x00000000 R23 = 0x00000000 R24 = 0x00000000 R25 = 0x00000020 R26 = 0x004E2718 R27 = 0x004E2718 R28 = 0x00000020 R29 = 0x00002513 R30 = 0x00000001 R31 = 0x00000000 Stack trace: PC = 0x000F36F4, SP = 0x004E2580 Frame 00: SP = 0x004E25A0 PC = 0x40000016 Frame 01: SP = 0x004E2618 PC = 0x000F6964 Frame 02: SP = 0x004E26A8 PC = 0x000F76DC Frame 03: SP = 0x004E26C8 PC = 0x000E8114 Frame 04: SP = 0x004E26F0 PC = 0x001F5BF8 Frame 05: SP = 0x004E2710 PC = 0x001F5CF4 Frame 06: SP = 0x004E2748 PC = 0x0023F4DC Frame 07: SP = 0x004E2750 PC = 0x0023E650 Frame 08: SP = 0x004E27C8 PC = 0x0023E89C Frame 09: SP = 0x004E27E0 PC = 0x0028AF34 Frame 10: SP = 0x004E27E8 PC = 0x001E38F8 Frame 11: SP = 0x004E2808 PC = 0x001E39A8 Frame 12: SP = 0x004E2820 PC = 0x0014E220 Frame 13: SP = 0x004E28C8 PC = 0x0014E39C Frame 14: SP = 0x00000000 PC = 0x001EB510

    Read the article

  • Need help with BOOST_FOREACH/compiler bug

    - by Jacek Lawrynowicz
    I know that boost or compiler should be last to blame, but I can't see another explanation here. I'm using msvc 2008 SP1 and boost 1.43. In the following code snippet execution never leaves third BOOST_FOREACH loop typedef Graph<unsigned, unsigned>::VertexIterator Iter; Graph<unsigned, unsigned> g; g.createVertex(0x66); // works fine Iter it = g.getVertices().first, end = g.getVertices().second; for(; it != end; ++it) ; // fine std::pair<Iter, Iter> p = g.getVertices(); BOOST_FOREACH(unsigned handle, p) ; // fine unsigned vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; // oops, infinite loop vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; // ... last block repeated 7 times Iterator code: class Iterator : public boost::iterator_facade<Iterator, unsigned const, boost::bidirectional_traversal_tag> { public: Iterator() : list(NULL), handle(INVALID_ELEMENT_HANDLE) {} explicit Iterator(const VectorElementsList &list, unsigned handle = INVALID_ELEMENT_HANDLE) : list(&list), handle(handle) {} friend std::ostream& operator<<(std::ostream &s, const Iterator &it) { s << "[list: " << it.list <<", handle: " << it.handle << "]"; return s; } private: friend class boost::iterator_core_access; void increment() { handle = list->getNext(handle); } void decrement() { handle = list->getPrev(handle); } unsigned const& dereference() const { return handle; } bool equal(Iterator const& other) const { return handle == other.handle && list == other.list; } const VectorElementsList<T> *list; unsigned handle; }; Some ASM fun: vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) // initialization 013E1369 mov edi,dword ptr [___defaultmatherr+8 (13E5034h)] // end iterator handle: 0xFFFFFFFF 013E136F mov ebp,dword ptr [esp+0ACh] // begin iterator handle: 0x0 013E1376 lea esi,[esp+0A8h] // begin iterator list pointer 013E137D mov ebx,esi 013E137F nop // forever loop begin 013E1380 cmp ebp,edi 013E1382 jne main+238h (13E1388h) 013E1384 cmp ebx,esi 013E1386 je main+244h (13E1394h) 013E1388 lea eax,[esp+18h] 013E138C push eax // here iterator is incremented in ram 013E138D call boost::iterator_facade<detail::VectorElementsList<Graph<unsigned int,unsigned int>::VertexWrapper>::Iterator,unsigned int const ,boost::bidirectional_traversal_tag,unsigned int const &,int>::operator++ (13E18E0h) 013E1392 jmp main+230h (13E1380h) vertex_count++; // forever loop end It's easy to see that iterator handle is cached in EBP and it never gets incremented despite of a call to iterator operator++() function. I've replaced Itarator implmentation with one deriving from std::iterator and the issue persisted, so this is not iterator_facade fault. This problem exists only on msvc 2008 SP1 x86 and amd64 release builds. Debug builds on msvc 2008 and debug/release builds on msvc 2010 and gcc 4.4 (linux) works fine. Furthermore the BOOST_FOREACH block must be repeaded exacly 10 times. If it's repeaded 9 times, it's all OK. I guess that due to BOOST_FOREACH use of template trickery (const auto_any), compiler assumes that iterator handle is constant and never reads its real value again. I would be very happy to hear that my code is wrong, correct it and move on with BOOST_FOREACH, which I'm very found of (as opposed to BOOST_FOREVER :). May be related to: http://stackoverflow.com/questions/1275852/why-does-boost-foreach-not-work-sometimes-with-c-strings

    Read the article

  • Defend PHP; convince me it isn't horrible

    - by Jason L
    I made a tongue-in-cheek comment in another question thread calling PHP a terrible language and it got down-voted like crazy. Apparently there are lots of people here who love PHP. So I'm genuinely curious. What am I missing? What makes PHP a good language? Here are my reasons for disliking it: PHP has inconsistent naming of built-in and library functions. Predictable naming patterns are important in any design. PHP has inconsistent parameter ordering of built-in functions, eg array_map vs. array_filter which is annoying in the simple cases and raises all sorts of unexpected behaviour or worse. The PHP developers constantly deprecate built-in functions and lower-level functionality. A good example is when they deprecated pass-by-reference for functions. This created a nightmare for anyone doing, say, function callbacks. A lack of consideration in redesign. The above deprecation eliminated the ability to, in many cases, provide default keyword values for functions. They fixed this in PHP 5, but they deprecated the pass-by-reference in PHP 4! Poor execution of name spaces (formerly no name spaces at all). Now that name spaces exist, what do we use as the dereference character? Backslash! The character used universally for escaping, even in PHP! Overly-broad implicit type conversion leads to bugs. I have no problem with implicit conversions of, say, float to integer or back again. But PHP (last I checked) will happily attempt to magically convert an array to an integer. Poor recursion performance. Recursion is a fundamentally important tool for writing in any language; it can make complex algorithms far simpler. Poor support is inexcusable. Functions are case insensitive. I have no idea what they were thinking on this one. A programming language is a way to specify behavior to both a computer and a reader of the code without ambiguity. Case insensitivity introduces much ambiguity. PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that doesn't do so, but it's actually easier to write code in the incorrect (from a sound design perspective) manner. PHP performance is abysmal without caching. Does anyone sell a commercial caching product for PHP? Oh, look, the designers of PHP do. Worst of all, PHP convinces people that designing web applications is easy. And it does indeed make much of the effort involved much easier. But the fact is, designing a web application that is both secure and efficient is a very difficult task. By convincing so many to take up programming, PHP has taught an entire subgroup of programmers bad habits and bad design. It's given them access to capabilities that they lack the understanding to use safely. This has led to PHP's reputation as being insecure. (However, I will readily admit that PHP is no more or less secure than any other web programming language.) What is it that I'm missing about PHP? I'm seeing an organically-grown, poorly-managed mess of a language that's spawning poor programmers. So convince me otherwise!

    Read the article

  • Is this too much code for a header only library?

    - by Billy ONeal
    It seems like I had to inline quite a bit of code here. I'm wondering if it's bad design practice to leave this entirely in a header file like this: #pragma once #include <string> #include <boost/noncopyable.hpp> #include <boost/make_shared.hpp> #include <boost/iterator/iterator_facade.hpp> #include <Windows.h> #include "../Exception.hpp" namespace WindowsAPI { namespace FileSystem { class FileData; struct AllResults; struct FilesOnly; template <typename Filter_T = AllResults> class DirectoryIterator; namespace detail { class DirectoryIteratorImpl : public boost::noncopyable { WIN32_FIND_DATAW currentData; HANDLE hFind; std::wstring root; public: inline DirectoryIteratorImpl(); inline explicit DirectoryIteratorImpl(const std::wstring& pathSpec); inline void increment(); inline bool equal(const DirectoryIteratorImpl& other) const; inline const std::wstring& GetPathRoot() const; inline const WIN32_FIND_DATAW& GetCurrentFindData() const; inline ~DirectoryIteratorImpl(); }; } class FileData //Serves as a proxy to the WIN32_FIND_DATA struture inside the iterator. { boost::shared_ptr<detail::DirectoryIteratorImpl> iteratorSource; public: FileData(const boost::shared_ptr<detail::DirectoryIteratorImpl>& parent) : iteratorSource(parent) {}; DWORD GetAttributes() const { return iteratorSource->GetCurrentFindData().dwFileAttributes; }; bool IsDirectory() const { return (GetAttributes() | FILE_ATTRIBUTE_DIRECTORY) != 0; }; bool IsFile() const { return !IsDirectory(); }; bool IsArchive() const { return (GetAttributes() | FILE_ATTRIBUTE_ARCHIVE) != 0; }; bool IsReadOnly() const { return (GetAttributes() | FILE_ATTRIBUTE_READONLY) != 0; }; unsigned __int64 GetSize() const { ULARGE_INTEGER intValue; intValue.LowPart = iteratorSource->GetCurrentFindData().nFileSizeLow; intValue.HighPart = iteratorSource->GetCurrentFindData().nFileSizeHigh; return intValue.QuadPart; }; std::wstring GetFolderPath() const { return iteratorSource->GetPathRoot(); }; std::wstring GetFileName() const { return iteratorSource->GetCurrentFindData().cFileName; }; std::wstring GetFullFileName() const { return GetFolderPath() + GetFileName(); }; std::wstring GetShortFileName() const { return iteratorSource->GetCurrentFindData().cAlternateFileName; }; FILETIME GetCreationTime() const { return iteratorSource->GetCurrentFindData().ftCreationTime; }; FILETIME GetLastAccessTime() const { return iteratorSource->GetCurrentFindData().ftLastAccessTime; }; FILETIME GetLastWriteTime() const { return iteratorSource->GetCurrentFindData().ftLastWriteTime; }; }; struct AllResults : public std::unary_function<const FileData&, bool> { bool operator()(const FileData&) { return true; }; }; struct FilesOnly : public std::unary_function<const FileData&, bool> { bool operator()(const FileData& arg) { return arg.IsFile(); }; }; template <typename Filter_T> class DirectoryIterator : public boost::iterator_facade<DirectoryIterator<Filter_T>, const FileData, std::input_iterator_tag> { friend class boost::iterator_core_access; boost::shared_ptr<detail::DirectoryIteratorImpl> impl; FileData current; Filter_T filter; void increment() { do { impl->increment(); } while (! filter(current)); }; bool equal(const DirectoryIterator& other) const { return impl->equal(*other.impl); }; const FileData& dereference() const { return current; }; public: DirectoryIterator(Filter_T functor = Filter_T()) : impl(boost::make_shared<detail::DirectoryIteratorImpl>()), current(impl), filter(functor) { }; explicit DirectoryIterator(const std::wstring& pathSpec, Filter_T functor = Filter_T()) : impl(boost::make_shared<detail::DirectoryIteratorImpl>(pathSpec)), current(impl), filter(functor) { }; }; namespace detail { DirectoryIteratorImpl::DirectoryIteratorImpl() : hFind(INVALID_HANDLE_VALUE) { } DirectoryIteratorImpl::DirectoryIteratorImpl(const std::wstring& pathSpec) { std::wstring::const_iterator lastSlash = std::find(pathSpec.rbegin(), pathSpec.rend(), L'\\').base(); root.assign(pathSpec.begin(), lastSlash); hFind = FindFirstFileW(pathSpec.c_str(), &currentData); if (hFind == INVALID_HANDLE_VALUE) WindowsApiException::ThrowFromLastError(); while (!wcscmp(currentData.cFileName, L".") || !wcscmp(currentData.cFileName, L"..")) { increment(); } } void DirectoryIteratorImpl::increment() { BOOL success = FindNextFile(hFind, &currentData); if (success) return; DWORD error = GetLastError(); if (error == ERROR_NO_MORE_FILES) { FindClose(hFind); hFind = INVALID_HANDLE_VALUE; } else { WindowsApiException::Throw(error); } } DirectoryIteratorImpl::~DirectoryIteratorImpl() { if (hFind != INVALID_HANDLE_VALUE) FindClose(hFind); } bool DirectoryIteratorImpl::equal(const DirectoryIteratorImpl& other) const { if (this == &other) return true; return hFind == other.hFind; } const std::wstring& DirectoryIteratorImpl::GetPathRoot() const { return root; } const WIN32_FIND_DATAW& DirectoryIteratorImpl::GetCurrentFindData() const { return currentData; } } }}

    Read the article

< Previous Page | 1 2 3 4