Posts by Narue

>if you dont want to help then dont make such comments.
I'd love to help you. But I'm not going to waste my time on a lost cause. If you can prove that you're not a lost cause, you'll find me to be an excellent resource. However, posting your assignment without any kind of attempt or specific question strongly suggests that you're yet another lazy cheater (we get a lot of them around here) looking for a free ride.

>in future, you also might need some help in something and i hope at that time,
>if you get the same reply as you said now to me, you will remember me then..
I remember people like you every time I help myself or teach myself something new. Would it interest you to know that I taught myself C through trial and error? I didn't discover all of the wonderful resources on the web until long after I had overcome the difficulties you're experiencing now, so your "I'm just a beginner wah wah wah" defense is falling on deaf ears.

>which is a dead link by the way
It's not my fault you can't navigate Boost's web site. I have no trouble reaching the documentation page.

I could speculate, but not being privy to the thought process of the designer makes answering your question difficult.

Those are neither doubts nor questions. I doubt your intentions are anything but those of a cheater looking for free code to get through assignments without any effort. I also doubt that helping you would be anything but a waste of my time because you'll do one of two things:

1. Run off with any code that's given to you, never to be seen again.
2. Bitch and moan about being helpless and stupid if I try to teach you how to write code yourself.

Can you alleviate those doubts? No? Then go cheat somewhere else.

>Why is there not a <heap> just as is there is a <set>, etc?
<priority_queue>, perhaps?

What compiler are you using?

I take it you've already exhausted the tutorials and documentation on the Boost site?

Provided the items are separated by whitespace, you can use the simplest form of stringstream I/O to break it apart:

#include <iostream>
#include <sstream>
#include <string>

int main()
{
    std::stringstream split("v 0.200006 -0.093641 0.584690");
    std::string token;

    while (split>> token)
        std::cout<< token <<'\n';
}

cin's >> operator is type specific. If you give it an int, it will try to parse an integer, and fail if the conversion can't be made. So you would need to check for errors during the input request itself. A not uncommon pattern is an input loop that continues while cin fails, clears the stream state, and discards the buffer before prompting again:

while (prompt(), !(cin>> x)) {
  cerr<<"Input error\n";
  cin.clear();
  cin.ignore(1024, '\n'); // Arbitrary "large" value
}

There are more complex solutions that involve strings and manual tests, but those are only necessary if the above pattern doesn't fit your needs.

>Namespaces are a relatively new C++ feature just now starting to appear in C++ compiler
If by "just now" you mean "almost two decades ago", you'd be correct. They're not new, and all decent compilers have a mature implementation in place.

In the interests of getting the OP in trouble with his teacher for plagiarism:

#include <cctype>
#include <cstdlib>
#include <cstring>
#include <ctime>
#include <iostream>
#include <string>

namespace {
    const int MONTHS = 12;
    const int MONTH_NAME_MAX = 9;

    static const char *whitespace = " \t";
    static const char *separators = ".-/";

    static const char *months_full[] = {
        "january"  , "february", "march"   , "april",
        "may"      , "june"    , "july"    , "august",
        "september", "october" , "november", "december"
    };

    static const char *months_abbr[] = {
        "jan", "feb", "mar", "apr",
        "may", "jun", "jul", "aug",
        "sep", "oct", "nov", "dec"
    };

    int compare_insensitive(const char *a, const char *b)
    {
        int x, y;

        do {
            x = std::tolower((unsigned char)*a++);
            y = std::tolower((unsigned char)*b++);
        } while (x != '\0' && x == y);

        return (unsigned char)x - (unsigned char)y;
    }

    const char *skip_leading(const char *s, const char *match)
    {
        while (std::strchr(match, *s) != NULL) 
            ++s;

        return s;
    }

    const char *extract_name(const char *s, char *name, size_t limit)
    {
        /* Assume limit includes space for a null character */
        while (--limit > 0 && std::isalpha((unsigned char)*s)) 
            *name++ = (char)std::tolower((unsigned char)*s++);

        *name = '\0';

        return s;
    }

    bool extract_numeric(const char*& s, long& result)
    {
        char *end;

        if (!std::isdigit((unsigned char)*s)) 
            return false;

        errno = 0;
        result = std::strtol(s, &end, 10);

        if (errno) 
            return false;

        s = end;

        return true;
    }

    bool is_abbr_name(const char *name, bool validated)
    {
        bool result = validated;

        /* May is the only month the same abbreviated as not */
        if (compare_insensitive(name, "may") == 0) 
            return false; …

What did you try? While it's straightforward, the exact method depends on the result you want.

>you were so sure that you were right
I am right. You're just too stubborn to imagine that you're wrong. Drop the ego for a moment and consider that someone else might just know something you don't.

>it was impossible to get you to see some very subtle but important flaws in your logic
Just because you don't understand doesn't mean my logic is flawed.

>If NULL were 0xdeadbeef or even ((void *)0xdeadbeef), the compiler does NOT care, its a frickin' macro.
Let's pretend that the NULL macro doesn't exist, because it's just confusing the issue. The problem exists whether you use NULL or not, it's the difference between a null pointer and a pointer with all bits set to zero that matters. Now go read my posts again.

>mktime ( timeinfo );
I suspect you want this:

rawtime = mktime(timeinfo);

Likewise with rawtime2. Otherwise both will be close enough to the same time (the running time of the program) to compare as 0 seconds.

How to search google. :icon_rolleyes:

>Is it correct?
Yes and no, there's confusion about the NULL macro. The definition of NULL is irrelevant[1]. If a null pointer is not represented by all bits zero, you open a can of worms by initializing a pointer to all bits zero. calloc essentially uses memset to initialize the block, and memset fills the data with all bits zero, so using memset on a pointer and expecting it to compare equal to a null pointer is wrong:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    struct foo { int *data; } *p = calloc(1, sizeof *p);

    if (p != NULL)
        puts(p->data == 0 ? "null" : "not null");

    return 0;
}

The above program is not required to print "null", because calloc need not initialize the pointer member to a null pointer.

[1] It's irrelevant because NULL is nothing more than a convenient symbol for a null pointer constant. A null pointer constant is absolutely guaranteed to be some variant of a constant expression evaluating to 0. This constant is then converted to the internal pointer representation when used. So, once again assuming the internal representation is 0xdeadbeef, when the compiler sees this:

int *p = 0;

It converts it to the equivalent of this:

int *p = (int*)0xdeadbeef;

Null pointer constants are thus portable regardless of the underlying representation of a pointer. The existence of the NULL macro is really just a convenience that makes your intentions clear. If you use 0, …

>Umm... well I guess I'll just agree with you and let it be.
...I see I wasted my time trying to teach you. Next time I'll just say you're wrong and not bother explaining why unless someone who's willing to learn asks.

>not willing to use external libraries
You're already using the pow function, right? Just include <cerrno> for errno and ERANGE. HUGE_VAL is defined in <cmath>, which you're already including for pow. All of these are standard libraries. Technically, you could just check for HUGE_VAL and not have to use any extra headers:

result = pow(a, b);

if (result == HUGE_VAL || result == -HUGE_VAL) {
  // Out of range
}

>(given i don't know how to)
That's a stupid reason. If you avoid things you don't know about because you don't know about them, you'll never progress beyond your current ability.

>There is no way to be sure that the input you received is in integer format.
No standard way, at least if you want to force integer input at the keystroke level. If you can get raw input, you can force the user to enter whatever you want. In this case, the digits can be parsed on the fly as they're typed:

#include <cctype>
#include <climits>
#include <cstdio>
#include <cstdlib>
#include <conio.h>

int get_int()
{
    const int base = 10;

    int c = getch();
    int result = 0;
    bool sign = 0;

    if (c == '-' || c == '+') {
        putch(c);
        sign = c == '-';
        c = getch();
    }

    int limit = std::abs((sign ? INT_MIN : INT_MAX) / base);
    int top_digit = std::abs((sign ? INT_MIN : INT_MAX) % base);

    while (std::isdigit(c)) {
        int digit = c - '0';

        if (result > limit || (result == limit && digit > top_digit))
            break;

        putch(c);
        result = result * base + digit;
        c = getch();
    }

    return sign ? -result : result;
}

#include <iostream>

int main()
{
    std::cout<<"\nValue read: "<< get_int() <<'\n';
}

But that's tedious and non-portable. It's much easier to read a string, parse it, and prompt for valid input if the input doesn't meet the program's needs.

>In other words b will have no limit will just break when a^b is too large.
Then it still has a limit. You can use an arbitrary length math package like GMP to get around the limitation. Alternatively, pow checks for out of range requests for you, sets errno appropriately, and returns HUGE_VAL:

errno = 0;
result = pow(a, b);

if (errno == ERANGE || result == HUGE_VAL || result == -HUGE_VAL) {
  // Out of range!
}

You really don't see the problem, do you? I don't care that you redefine NULL. That's not the problem. I find it strange, but if it floats your boat, whatever. The problem is you're advocating the horribly unsafe practice of letting calloc initialize pointers to null, which is not guaranteed to work.

>Please correct me if i'm wrong with my thought process here.
As long as you recognize that your argument boils down to "I like it this way because it makes more sense to me", it's all good. It's not my place to dictate personal styles, provided you're aware of the alternatives and make an educated choice.

>I just don't think it can always correctly interpret my meaning if I chose the path
>of assumptions and ambiguity for the sake of saving a few extra characters of code.
The problem here is that there's no ambiguity. If you find a compiler that incorrectly interprets your meaning without casting malloc, I'll show you a severely broken compiler.

>Not sure what your trying to prove and who your trying to prove it to with this statement.
It's a compliment (you strike me as a skilled programmer). Would you rather I said your statement was the kind of stupid thing beginners believe and left it at that?

>I do this in my core header
Hopefully because you want to use NULL, but don't want all of the extra stuff in the headers where it's defined. That's really the only good excuse for defining your own NULL exactly the way the implementation would.

>Does the compiler or system typically do anything with position zero of the local process memory?
It's typically reserved for system level stuff. Oddly enough, catching null pointer dereferences is not uncommon. ;)

>If calloc() is used in a structure containing a pointer, doesn't the pointer automatically point to (void*)0 ?
Let's look at this from a low level perspective:

int **p = calloc(1, sizeof *p);

You know that calloc is logically nothing more than a paired call to malloc and then memset:

int **p = malloc(1 * sizeof *p);

memset(p, 0, 1 * sizeof *p);

And memset is pretty stupid in that all it does is copy the value into each byte:

int **p = malloc(1 * sizeof *p);
char *dst = (char*)p;

while (dst < (char*)p + (1 * sizeof *p))
    *dst++ = 0;

Now *p is set to all bits zero: 0x00000000. But what if the implementation uses 0xdeadbeef as the internal representation of a null pointer? The compiler can easily recognize that *p = 0 or *p = (void*)0 is assigning a null pointer constant and automatically convert that constant to the internal value of 0xdeadbeef before assignment, but it can't do that …

>Is that a strong enough reason not to cast your malloc results to your target?
No, but I find not needing to type out a redundant cast and not needing to mention the target data type at all somewhat compelling:

p = malloc(N * sizeof *p);

>I always cast results so the compiler knows my destination size.
That's the kind of statement I expect to see from someone who doesn't understand how pointers to void work. I'm kind of surprised, to be honest. You seem like you know what you're doing.

>It may not always be necessary
The only time it's necessary to cast malloc in standard C is when writing code that needs to be compilable as both C and C++, and that's a rather small niche.

>Sometimes the compiler can be stupid.
Not that stupid. Many bad practices have been propagated far longer than necessary in the name of "helping" the compiler when the compiler doesn't need any help. One of my pet peeves is programmers who think compiler writers are incompetent.

>Thats true, so all places which use NULL should be changed to 0 to take advantage of calloc().
Um, no. For the sake of this concept, you should think of NULL and 0 as being exactly the same thing[1]. There's confusion because a literal 0 in pointer context means a null pointer, but that doesn't mean the underlying bit representation of a null pointer is all zeros[2].

calloc initializes the allocated memory to zero bytes, and because a null pointer may not be represented internally by all zero bytes, you can't assume that pointers are initialized properly to NULL (or 0).

>Personally I redefine NULL in my applications since -1 or any other interpretation is not very useful compared to 0.
What? Why in the world would you want to redefine the macro for a null pointer constant? That sounds like a fantastic way to introduce bugs.

[1] NULL can be correctly implemented as #define NULL 0 , though traditionally in C it's been #define NULL ((void*)0) .
[2] Described another way, a null pointer doesn't have to point to address 0.

>instead of using malloc(), use calloc() and you don't have to do (*ptr)->link=NULL;
I wouldn't recommend relying on that. calloc zero fills the bytes, and a null pointer isn't required to be represented by all bits zero.

>Anyways, as for why its not working, beats me.
It is working, he just doesn't understand why p points to the head of the list and not the tail after calling addatend.

>Static functions are those functions which do not have the access to
>"this" pointer of the class and it can not be declared as virtual.
You need to learn the difference between C and C++ before resurrecting a three year old thread with completely incorrect and unhelpful information.

>I suppose I can buy a program, as long as it's not really expensive
Commercial compilers are generally expensive.

>As for my skill, do you think it's enough to start on basic programs
>and games or should I learn about certain areas of c++ more?
You could probably use more experience with C++ before throwing complex graphical libraries into the mix, but that's just a gut feeling rather than any detailed review of the skills you so vaguely mentioned. The worst that could happen is you'll be confused, so don't feel like you can't try, if graphical programs are what you really want to write.

Borland 4.5 is very old. I'd recommend upgrading to a modern compiler such as Visual C++ Express or Code::Blocks (assuming you want a free option). Presumably you'll be working on a Windows platform, so a quick foundation in the Win32 API will get you started toward writing GUIs.

>Need some examples for non Ansi C Stanadard.
When someone says something like "Non-ANSI", they usually mean pre-standard C (often the K&R variant). If you want to be picky, the current C standard is non-ANSI because ANSI no longer controls the C standard, ISO does.

If you want examples, this is a good read. The problem with such examples is prior to standardization (and the primary reason for standardization), each compiler implemented a slightly different dialect. Further, many of the common practices were kept in the standard, which means you can pull out examples of pre-standard C that compile and run perfectly on a C90 compiler. For example:

#include <stdio.h>

main(argc, argv)
    int argc;
    char **argv;
{
    char **p = argv;

    while (*p != NULL)
        puts(*p++);

    return 0;
}

K&R function definitions are the most noticeable difference between standard and pre-standard C (even though they still work up to C99).

>How can I make the first line of the text as the filename of the text??
The filename is just a string:

ifstream in("filenames");
string line;

if (getline(in, line)) {
    in.close();
    in.clear();
    in.open(line.c_str());

    // ...
}

You can reuse an ifstream object, but take note that opening and closing files does not affect the stream state. If you open a file, read to EOF, close the file, then open another file, the eofbit will still be set. So do something like this:

ifstream in("first file");

// Read first file

in.close();
in.clear();
in.open("second file");

// Read second file

>for (count = 0; !FILE_READER.eof(); count++)
On a side note, the eof member function generally shouldn't be used as a loop condition because it may introduce a fencepost bug. You can use the result of getline instead, and the bug goes away:

count = 0;

while (getline(FILE_READER, tempArray[count], '\n'))
  ++count;

To properly use eof as a loop condition, you still need to perform subsequent tests to explicitly avoid processing the last record twice:

for (count = 0; !FILE_READER.eof(); count++) {
  if (!getline(FILE_READER, tempArray[count], '\n'))
    break;
}

Probably a brain fart. AD should have included <iostream>, not <string>. Here's a more concise way of writing your code:

#include <iostream>

int main()
{
    int i = 0;
loop:
    if (++i > 10)
        goto end;

    std::cout<< i <<'\n';
    goto loop;
end:
    return 0;
}

Though manually building loops like that is borderline stupid in C++. Presumably you're only doing it to learn how goto works.

When you don't pass any arguments to ignore, it reads and discards the next character. In your case, that would be the newline character ('\n'). There's a sticky that explains the issues involved (translation: I don't want to write it all again).

>I never said it was breaking any rules
"Effective moderation" was the phrase you used, and you clearly stated that the post should be deleted. However, on Daniweb moderators aren't allowed to use their powers except to enforce the rules. If no rule is broken, no action can be taken, so the only way to implement your solution is to introduce a rule that would have been broken in this case.

While you didn't explicitly say it was breaking any rules, the only interpretation is that you believe it should be treated as such.

>Effective moderation could be the solution, assuming that is possible on this forum.
Resurrecting a thread is a community faux pas, not a broken rule. Changing the rules to exclude frivolous resurrection while still allowing legitimate continuations of a thread introduces subjectivity where none presently exists. Subjectivity isn't a good thing when it comes to enforcing rules because then members have no clue what's expected of them.

s is a null pointer. Your code is actually pretty horrible, but the null pointer dereference is your immediate problem.

>error message is seen on the goto statement. did I miss library ?
goto is a part of the core language, not a library feature. If you're getting an error, you used it wrong. Looking at your code, you clearly don't understand the concept of goto, so I'd suggest going rereading your book/tutorial/reference.

>Was a post answered in 2005 bumped to 2010 asking the exact same question as the
>original poster in the same exact words even though the post was already clearly answered?
Yes.

>Does this happen often on this forum?
Sadly, yes. The quality of Daniweb has been steadily decreasing over the years because new members like that are becoming the norm and driving away clueful members.

>Try to use _getch();
Bumping a three year old thread with bad advice. Awesome first post! :icon_rolleyes:

>whats the function Cmd_ExecuteString() doing?
That's largely irrelevant, I think. Pretend that it's a placeholder for any function accepting a string argument. Hell, you can pretend that it's a macro for puts:

#define Cmd_ExecuteString puts

> for pch to equal the next token in sting after each call to strtokwhen they're separated by ';'
pch does equal the next token in the string after each call to strtok. But you're processing the string variable, not the pch variable. I already mentioned this, you're calling Cmd_ExecuteString(string) in the tokenization loop, not Cmd_ExecuteString(pch) .

What do you want?

Three things:

1. You call Cmd_ExecuteString(string) in the tokenization loop. Shouldn't it be Cmd_ExecuteString(pch)?
2. Which variable are we talking about here? I'm assuming string , because it coincides with your description of the problem.
3. strtok modifies the source string by adding null characters at the separator. This is how you get a nice happy token as the return value without any dynamic allocation. If you start with "developer;developer 0;developer" and change it to "developer\0developer 0;developer", any operation on a string (including printing) will stop at the null character.

>does strcat modify the source paramater at all?
No, it's a pointer to const char. This strikes me more as a fencepost error with your loop index, where it starts at CON_LINES rather than CON_LINES-1.

>Is there anyway I can optimize the first one to something that could make my program faster?
Your program is slow because your code sucks. Don't make it suck more by trying to micro-optimize.

Those aren't questions, they're coding assignments. You also didn't ask any questions about those assignments, so we're generally going to assume you want someone to do it for you. That's cheating, cheating is not encouraged on Daniweb, and if it's what you want, you're welcome to piss off.

Otherwise, here's a very basic stack implementation. It should get you started without giving you the solution to any of the problems:

#include <stdio.h>
#include <stdlib.h>

typedef struct node node;

struct node {
    int value;
    node *next;
};

static int push(node **top, int value)
{
    node *new_top = malloc(sizeof *new_top);

    if (new_top != NULL) {
        new_top->value = value;
        new_top->next = *top;
        *top = new_top;
    }

    return new_top != NULL;
}

static int pop(node **top, int *value)
{
    node *save = *top;

    if (save != NULL) {
        *value = save->value;
        *top = save->next;
    }

    return save != NULL;
}

int main(void)
{
    node *top = NULL;
    int value;
    int i;

    for (i = 0; i < 10; i++) {
        printf("Pushing %d\n", i);

        if (!push(&top, i))
            perror("Unable to push value into stack");
    }

    while (pop(&top, &value))
        printf("Popped %d\n", value);

    return 0;
}

Not only is it possible, it's recommended that you use the std::string class instead of C-style strings. I imagine you've tried this already and gotten an error, which prompted you to ask an overly generic question when posting your code and asking a specific question will get your problem solved faster.

Well, for starters you used the wrong constructor. Change the definition of wanted_string to this:

string wanted_string(original_string, 0, 7);

If that still doesn't work, post a complete program so we can test it.

As far as it likely matters to you, they're equally fast.