Posts by deceptikon

This isn't a trivial exercise. Do you have a specific question?

this package is written in C and with structures and I can not change that so I am stuck ..

It doesn't change the fact that you need to do a deep copy. If you have no choice but to do it manually, do it manually. Alternatively, you can write wrapper classes around these problematic structures to introduce automatic resource management.

The original meaning of hacker back in the 1990's was basically a n00b of programming, maliciously or not.

The original meaning of hacker dates back to the 1960s and was the opposite of a n00b.

Test Foo{1, 2, 3} but not Test Foo = {1, 2, 3}

Those are not the same thing. The first is actually an alternative to the explicit Test Foo(1, 2, 3) while the second is an implicit expression similar to Test Foo = 123 (assuming you supported Test(int) as a non-explicit constructor).

And once again assuming that Test(int) is supported, you probably already know that Test Foo(123) is not the same as Test Foo = 123. The equals sign makes all the difference in your example.

Adding the curly brace alternative to C++ was a mistake, in my opinion.

Good hackers know how to program their own exploits and tools. Bad hackers, also known as script kiddies, mindlessly use exploits and tools written by good hackers. This is all using the negative connotation of "hacker", by the way.

So why does this happen?

If you try to call an explicit constructor with an implicit expression then obviously it's going to fail. That's what explicit means.

There are a number of ways to do it depending on your efficiency needs. Usually a priority queue is optimized for maximum retrieval speed of the highest priority item. So you would do a sorted insert of new items according to the priority relation:

template <typename T>
void PQueue<T>::Insert(T item)
{
    if (Full())
    {
        throw FullQueueException();
    }

    if (Empty())
    {
        _data[_size++] = item;
    }
    else
    {
        for (int i = _size - 1; i >= 0; --i)
        {
            if (item <= _data[i])
            {
                break;
            }

            _data[i + 1] = _data[i];
        }

        _data[++_size] = item;
    }
}

Likewise you do a sorted removal of the highest priority item for deletion. This is actually quite trivial as the highest priority item should be either the first or last in the array (storing it as the last item makes removal very efficient while as the first item you need to do a potentially expensive shift). Doing the priority lookup is equally trivial as you just return the item at the 0th index or n-1th index depending on how you've chosen to do the sort.

Most likely 1,048,576 items the size of Cand is too much memory for malloc() to find and allocate in a single contiguous block. You might be able to call perror() for a more useful error message, but I'm willing to bet even if you do get a message, it'll be along the lines of what I just said.

Try allocating fewer items.

First step: check to see if malloc() failed before dereferencing ptrCand:

Cand* ptrCand =  (Cand*)malloc(sizeof(Cand)*rows*cols);

if (!ptrCand)
{
    cout << "malloc() failed!" << endl;
}
else
{
    ptrCand[16*1024+16].status = 0.5; /* exception happens here*/
}

might be at the top of the file today and tomorrow i change that file with some other commands and now tbe ip is going to be somewhere in the middle or even at the bottem of the file...

That shouldn't matter at all. For example, just read each line and process the label accordingly:

while (getline(in, line))
{
    string label = GetLabel(line);
    string value = GetValue(line);

    if (label == "ip")
    {
        ...
    }
    else if (label == "something else")
    {
        ...
    }
    else if (label == "thing")
    {
        ...
    }
    else if (label == "another thing")
    {
        ...
    }
}

Obviously this approach involves a potentially long chain of if statements, but there are ways to handle the verbosity if you have more than a handful of labels with unique processing needs. One such method is the table lookup approach:

while (getline(in, line))
{
    string label = GetLabel(line);
    string value = GetValue(line);

    options[label](value);
}

Where beforehand you set up a dictionary of labels and corresponding functions or function objects:

map<string, void(*)(string const&)> options;

options["ip"] = &SetIp;
options["something else"] = &SetSomethingElse;
options["thing"] = &SetThing;
options["another thing"] = &SetAnotherThing;

You have no choice but to allocate new memory and copy the data pointed to by the pointers. The most robust way to do this would be to write a copy constructor for each of the structures that needs to handle a deep copy.

And of course, when you write a copy constructor, you should probably also write a constructor, destructor, and copy assignment operator. This would greatly simplify your usage of those structures on top of ensuring that memory is properly handled in any case.

I think it is usually quite opposite: it looks little strange to look some old newbie posts, when the poster has hundreds of posts and current signature by retroactive use of current info, and especially time they have now been members.

Honestly, I think leaving stats from the time of posting would be far more strange and confusing. At least this way all posts from a member are consistent, and that's quite useful. For example, I doubt I'm the only one who identifies regulars by their avatar. ;)

Could it be easily changed to put the time the poster had been member in time of posting?

For the record, user stats have always been retroactive in the thread and post view, even when we used vBulletin. I'm not sure this information exactly as requested would be useful since a little grade school math is all that's needed. Every post includes your join date, and along with the date of the post itself, figuring out how long the poster had been a member when the post was made is fairly simple.

Look in Convert.h and ask yourself how to define a member function outside of the class definition. That's your error. You'll also have overloading issues because the return type doesn't make a function signature unique.

I dont know if you ever made a program that is suppose to do something and that is detirmend by command in a file.

I have, many times.

i try to read the file but i cant read it in the correct way so that i can process the string word by word so that i can easily give diffirent integers, strings, chars values speciefied in the file. thus also doing certein functions...

It completely depends on the format of the file. For a simple format, such as this one:

ip=127.0.0.1
port=80
login=fooby
password=ZG9vYnk=

If I were doing it manually, I'd read a line, split it on '=', then assign the value to the appropriate runtime setting based on the key:

#include <fstream>
#include <iostream>
#include <stdexcept>
#include <sstream>
#include <string>

using namespace std;

class IniOption
{
public:
    IniOption(string const& s, char delim = '=');
    string const& Key() const { return _key; }
    string const& Value() const { return _value; }
private:
    string _key;
    string _value;
};

IniOption::IniOption(string const& s, char delim)
{
    istringstream iss(s);

    if (!(getline(iss, _key, delim) && getline(iss, _value)))
    {
        throw runtime_error("Invalid INI format");
    }
}

int main()
{
    ifstream in("test.txt");

    if (in)
    {
        string line;

        while (getline(in, line))
        {
            try
            {
                IniOption ini(line);

                cout << "Setting " << ini.Key() << " to '" << ini.Value() << "'" << endl;
            }
            catch (exception const& ex)
            {
                cout << ex.what() << endl;
            }
        }
    }
}

That's obviously a naive …

x += buffer.str; // Problem

str() is a member function: x += buffer.str();

double y = atof(x.c_str) * Multiplier; // Problem

c_str() is also a member function: 'double y = atof(x.c_str()) * Multiplier;'

Repeat that fix for every usage.

I'm not sure I understand what the problem is. Can you describe it in a different way?

Those names are stored as strings within the thread table for maximum efficiency. Updating them when making a name change would be unreasonably expensive (since we'd have to go through every thread from the beginning of time), and storing a link to the actual user to get the name would require another query every time the information is needed.

So yes, the name change is incomplete as far as historical information goes, but I don't think making it complete would be worth the cost.

Why should I override my constructors or add a move/copy to this class as the compiler suggests?

As the compiler suggests? I assume you're getting a warning to that effect, what does it say?

Input using the >> operator is delimited by whitespace, so by default you'll only read the next "word" in the stream. If you want a full line, use getline().

Click Me

A heap is like a binary search tree, but it isn't one. The heap property is less strict in that you can't tell from the current node whether to search the left or right subtree.

All you know is that the item in the current node is a match, couldn't possibly be in one of the subtrees (because it would have been higher than the current node), or the item exists in one of the subtrees. Therefore you have no choice but to search every node in one way or another. General search gives you an average case of O(N/2), which reduces to O(N).

while (1)
{
    // All your stuff

    comand.clear(); // Here
}

You don't clear command anywhere in that snippet. If it's not cleared anywhere else, then I'm not surprised that the previous data remains. After each iteration of the outer loop you can just say command.clear() to make it empty.

I wouldn't include print statements in these functions, as that limits flexibility. Rather, they should return some sort of error status (NULL is a common option).

Is it necessary to free the memory of the node that is deleted?

Yes.

I see three potential alternatives:

1. Keep the live preview, but let us toggle it with a check box (and remember the choice).
2. Keep the live preview, but let us toggle it with a profile option.
3. Ditch the live preview in favor of a preview request (perhaps in an AJAX popup).

I'm actually in favor of #3. After using it, the live preview is nifty but confusing. I find myself constantly clicking on the preview to set the cursor for editing...

Ooooh. I totally didn't make the connection with the live preview, now it makes more sense. :/

Click Me

The concept of a discussion forum is actually pretty simple, and a bare bones forum system is equally simple. Adding in other features, scalability, compatibility, and security are what take up the lion's share of effort.

If you have any specific questions about how Daniweb in particular works (and vBulletin to a lesser extent), I can answer those.

It has just come to my attention that he has indeed used this for spam. He is also using it for profit too.

Would this not be considered a breach of forum rules?

It's soundly in the gray area as far as self-promotion goes, but I think I'll allow it this time since we can't be expected to police the content of YouTube videos. If it were a link to his personal site (or if he starts promoting it directly in other threads) then I'd definitely call it a violation.

I'd like to respond to a poster, but i get a red warning about a code snippet being not correctly formatted. There is no code in my post, just some log references and a URL.

I think that's due to a perceived indentation, which is matched as a false positive for code. Since it's problematic to post or send the message as a PM, would you be kind enough to email it to Dani for troubleshooting? I don't yet have a daniweb email address, so she'll have to forward it to me: dani [at] daniwebmail.com.

With a solid test case, we can more effectively troubleshoot the problem.

This site... it's getting beyond me... i do not follow the reason for the parroting of my work as I type.... I haven't a clue about whitespace-sensitive text....what is whitespace? Paste does not appear as an option, only Ctrl-V...
I click on the parrot text, it disappears, I click in the typed section, the parrot reappears.. what is going on? I only have so much patience with stuff like this.

I have no idea what you're talking about. Parrot?

Or is this about a totally different thing?

Yes, totally different. You're thinking of fatal errors that halt execution without any chance for recovery. The return value from main() is for a graceful exit. Let's say you try to allocate memory and it fails. That's an error that can be caught and potentially recovered from, but if it can't be recovered from, exiting with an error status is reasonable:

#include <iostream>
#include <new>      // For bad_alloc
#include <cstdlib>  // For EXIT_FAILURE

using namespace std;

int main()
{
    try
    {
        int* mem = new int[12345];

        ...

        delete[] mem;
    }
    catch (bad_alloc const& ex)
    {
        cerr << "Error allocating memory: '" << ex.what() << "'\n";
        return EXIT_FAILURE;
    }
}

(1) means that there was something wrong.

While 1 can be an error code, the whole point of using 0 to signify success is because there's only a single success value but a large number of potential error values: anything in the range of int that's not zero.

So a more accurate description is that 0 is a success code sent to the C++ runtime while non-zero is an implementation-defined error code. The only portable values are 0, EXIT_SUCCESS (which is basically defined as 0), and EXIT_FAILURE. EXIT_SUCCESS and EXIT_FAILURE are both defined in <cstdlib>.

What is this new system we're talking about?

It's uniquely Daniweb's. Dani and I wrote it from scratch over the course of last winter.

Absolutely LOVE the new Daniweb...

Thanks! It's nice to get feedback, but positive feedback is better for the ego. ;)

In your case (being a moderator with unlimited edit permissions), I'd say just keep a running update on the code for the snippet and make sure to include an easily seen comment in the message that says the code snippet is evolving. You might also link to the thread in question that keeps you from posting hte complete code.

For those who aren't moderators, I'd say to organize the snippet so that it's modular enough to support additions through replies to the thread. Then as it evolves, add another "module". The message should also contain a note that the snippet is evolving and to refer to replies for pieces that weren't in the original code.

read that question and not able to answer it,that's y put my article here.

If it's a question out of a book, post that question in its entirety exactly as written. Paraphrasing is a good way to miss important details that will cause us to give you unproductive help.

I think he meant without pointer surgery, such as if you traverse and swap the data.

but what if question arise to reverse the link list without using pointers?

Is it still a singly linked list? Are you allowed to create another variable or data structure to hold the reversed data? Is this a hypothetical question? ;)

It depends on what you're looking for. The same question might be asked about string comparisons, or array comparisons, or binary search tree comparisons.

However, typically a comparison means comparing corresponding items. So you'd traverse both lists and compare the data in each node. When they don't match, you return the result of that comparison. If both lists match to the end, they're equal. If one list is shorter but the contents are otherwise equal, convention makes it "less than" the other list. The algorithm would be very similar to how you'd compare arrays or strings, just with pointer chasing rather than indexing:

struct node* a = list1->head;
struct node* b = list2->head;

// Check while both lists have valid nodes
while (a != NULL && b != NULL)
{
    // Check for a mismatch and return if there is one
    if (a->data != b->data)
    {
        return a->data < b->data ? -1 : +1;
    }

    // Move to the next node
    a = a->next;
    b = b->next;
}

// Check for complete equality (both lists were exhausted)
if (a == NULL && b == NULL)
{
    return 0;
}

// Use list length to determine the relation
return a == NULL ? -1 : +1;

func() must be a member function of the class type for xx and return an object or reference to itself so that the the same member function can be called on the result. One example might look like this:

#include <iostream>

using namespace std;

class Foo
{
    int _value;
public:
    Foo(): _value(0) { }

    int Value() { return _value; }

    Foo& func(int increment)
    {
        _value += increment;
        return *this;
    }
};

int main()
{
    Foo xx;

    xx.func(1).func(2).func(3);
    cout << xx.Value() << endl;
}

But the arrays that I creatd in textread() and patternread() are being returned.

Sorry, I missed that you're deleting them in main(). However, there's still a bug there, and those two lines should be:

delete[] text;
delete[] pattern;

You pair new with delete and new[] with delete[].

Since the match function is already returning the count, how do I return the array of indexes??

This is different. Dynamic memory and pointers are used for more than just extending the lifetime of the memory. In this case you simply cannot generate a real array with a runtime size because its size depends on a compile time constant. Even if you free the memory before returning, it's still necessary to allocate some dynamically.

int match(char *pattern, char *text, int text_file_size, int pattern_file_size)
{
    int i, j, k;
    int index = -1;
    int count = 0;
    int* arr = new int[text_file_size];

    ...

    delete[] arr;

    return count;               
}

It's just that simple.

Isn't that your opinion too, deceptikon?

As usual, it depends. In this thread we're bouncing around a lot between conceptual and concrete, and I'm not the only one guilty of switching at one's convenience.

Programmer A: You can traverse a linked list with recursion.
Programmer B: No you can't! Recursion is a stack!
Programmer A: But you're still traversing the linked list without any explicit storage.
Programmer B: Explicit shmexplicit, storage is storage.
Programmer A: But it's under the hood.
Programmer B: How does that matter?
Programmer A: Technically recursion doesn't need to be implemented with a stack.
Programmer B: Whatever, it's still not a traversal. Recursion is an elegant solution though.
Programmer A: Be careful, it's elegant but not robust because the stack can overflow.
Programmer B: Dafuq?

;)

I was told to read the file by using SEEK_SET in fseek to avoid opening the file again.But I don't know how to implement it.

Just read the file again. It's not gonna kill you, and it'll certainly keep your code simpler and less buggy. ;)

int arr[text_file_size];

This is your problem. As I explained, arrays in C++ must have a compile time constant size. If you want to have a "dynamic" array then you must either simulate it through pointers and dynamic memory (not recommended), or use one of the many standard library options such as std::vector (highly recommended).

By the look of things, you've so far chosen the former, and you clearly already know how to simulate an array because it's being done in both textread() and patternread(). Just duplicate that logic and you'll be sorted.

Note to nitpickers: I didn't mention pairing new with delete because I didn't want to avoid overwhelming the OP. It's not a long running program, and we all know that Windows reclaims dynamic memory when the process terminates.

Perhaps that's why many books consider passing an array as always being passed by reference.

Certainly not any good books. Like I said, there's a subtle but significant difference between a pointer and a true reference.

Another thing, arrays are by default passed by reference in C++.

Nope, they're passed as a pointer to the first element. This is a subtle but significant difference.

What if I want to go from char* to BYTE*? I'd use reinterpret_cast right?

Correct, assuming BYTE isn't defined as char.

From const char* to BYTE* I'd do: reinterpret_cast<BYTE*>(const_cast<char*>(InitialValue.c_str()))

That's terrifying. First, casting away the const for the result of c_str() is begging for trouble, especially if you or some function you call tries to modify it. Second, the lifetime of the string returned by c_str() is questionable. You'd be much better off making a copy first, if the result is to have any significant life span.

But static_cast doesn't do this sorta thing and neither does dynamic so I'm not sure whether to reinterpret_cast or use c-style casting.

You can think of C-style casts as a god mode cast, they're essentially unrestricted. The C++ casts are restricted to their specific uses. const_cast is an ideal example: it modifies const/volatile qualifiers and nothing else.

If you're using C++ casts, then the best approach would probably be to avoid C-style casts entirely.

//See this cast? reinterpret_cast<char*>(&lpMsgBuf)
//Why do I have to use reinterpret to cast from a pointer?

The documentation for FormatMessage() says that you need to cast to LPTSTR, not char*. This distinction is important because LPTSTR could be defined as char* or wchar_t* depending on your unicode settings.

In this case, the Windows API is evil. Based on the flags from the first argument, FormatMessage() will treat the fifth argument differently. In one case it's a simple caller provided buffer …

Um...what? What do you mean by "get name mangling". Name mangling is an internal method for compilers to differentiate between otherwise similarly named objects. It's not something you as the end programmer need to care about except as pertains to disabling it for C compatibility.

I saw the replies, and I stand by my former statement.

Then I'd ask you to explain your rationale for making a provably incorrect statement and then stubbornly sticking to it. I assume you'll go with the "recursion is just an implicit stack" route?

Deceptikon: While that argument in favor of iterative solutions has merit in general (much though it pains the Schemer in me to admit it), in this particular case, the recursion is used less as a way of performing a loop than for the purpose of building up a stack with which the information about the list elements' positions is held at run time. The alternatives, either using an explicit stack or creating a separate reversed list, involve additional explicit data structures which have to be manually manipulated by the coder. Thus, I would argue that the recursive solution is the more elegant approach in this instance.

Generally the elegance of linear algorithms is close to identical between recursion and iteration. And given the higher chances of stack overflow in a linear algorithm with recursion, iteration is far more robust. I'm a fan of recursion too, but it's important to recognize where it's not the best practical option.

By the way, my side note was in general, not for this specific case. It should go without saying that if you can't use an iterative approach in-place (as in the case of traversing a singly linked list in reverse) and don't want to explicitly …

But there is no way to traverse a singly linked list backwards.

Incorrect, and if you had read this thread more carefully you'd see at least two replies (one from mike_2000_17 describing the process and one from Schol-R-LEA with sample code) showing an easy way of doing what you say isn't possible.

Now, there's certainly a case for calling a recursive traversal reversing the linked list, but since the structure of the list isn't being altered and no extra storage is used, I'd say such an argument is dubious at best. ;)

On a side note, I'll say that I'm strongly against recursive solutions for linked lists most of the time because it's a linear process. In my opinion each recursive step should significantly shrink the problem set, and linear algorithms only shrink the set by 1. Thus they're better solved by loops.

test.txt is stored in the same directory as my XCode project.

But is that the current working directory for XCode (assuming you're running directly from the IDE)? Use perror() to get a more useful error message:

FILE* f = fopen("test.txt", "r");

if (f == NULL)
    std::perror("Error opening file");

I suspect the error will be something along the lines of "File not found", which suggests that XCode is looking in the wrong place. I'm not familiar with XCode, but there's probably a build or debug folder where the executable lives, and that's likely where text.txt should be placed.

typedef long static_cast<stringFromString>((int, char)) __cdecl;

This is completely nonsensical. Casting is a form of coercion of objects to another type. The bytes of the object are interpreted as the new type. A typedef is not an object.

SmartSetup((char*)World.c_str(), (char*)",f5", 765, 503,(char*)"");

//TO:

SmartSetup(static_cast<char*>(World.c_str()), static_cast<char*>(",f5"), 765, 503, static_cast<char*>(""));

c_str() already returns a pointer to const char, so the only use for a cast when calling SmartSetup() would be to remove the constness of the pointer if SmartSetup() is defined as:

T SmartSetup(char* a, char* b, int c, int d, char* e);

But even then, string literals have special rules that allow such a conversion without incident. It's deprecated, but still legal. ;) Anyway, since the point of the cast is to remove constness, you'd be better off using const_cast:

SmartSetup(const_cast<char*>(World.c_str()), 
        const_cast<char*>(",f5"), 
        765, 
        503, 
        const_cast<char*>(""));

memcpy(&INH, (void*)((DWORD)Buffer + IDH.e_lfanew), sizeof(INH));

TO:

memcpy(&INH, static_cast<void*>(static_cast<DWORD>(Buffer) + IDH.e_lfanew), sizeof(INH));

This looks hairy regardless of the cast. If Buffer is already a pointer then there's no need for any cast because all pointers have an implicit conversion to void*. If Buffer isn't a pointer then you might be doing something exceedingly risky. I'm not sure why Buffer is being cast to DWORD here, and there's no context for me to figure it out. So I'll just assume that Buffer is a pointer and all casts may be safely removed:

memcpy(&INH, Buffer + IDH.e_lfanew, sizeof(INH));

Parameter names aren't required in a function declaration, though it's generally viewed as poor style to take advantage of that (mis)feature. You can also omit the parameter name if you don't use the parameter, even if it's a definition, which can be useful every now and again to match interfaces:

// Match an expected interface of 3 arguments, but we don't use the 3rd
int add(int x, int y, int)
{
    return x + y;
}