That's not the fault of Microsoft.

But why think about it when you can just blame Microsoft for everything bad that happens in computing? ;)

You might be able to find something on, but for very specific tasks like this it's unreasonable to expect there to be a walkthrough. The most significant part of programming is solving problems with the tools you have and the creativity to put them together.

The trick with this program is defining what's meant by a "word". You can't just take whatever is separated by whitespace and call it good, because that will incorrectly include punctuation.

To properly do it would require some lookahead and lookbehind, and even then poorly formatted sentences could cause an issue. So to a certain extent the program would need to be tailored to the expected input rather than act as a universal sentence recognizer.

Once you have reasonable tokenization logic, it's straightforward to do the deed:

#include <ctype.h>
#include <stdio.h>

int is_word_char(char c)
    return isalnum(c) || c == '\'' || c == '-';

const char *next_word(const char *s, size_t *len)
    *len = 0;

    // Find the next word
    while (*s != '\0' && !is_word_char(*s))

    // Find the end of the word
    while (s[*len] != '\0' && is_word_char(s[*len]))

    return *s != '\0' ? s : NULL;

int main(void)
    char line[BUFSIZ];

    printf("Enter a sentence: ");

    if (fgets(line, sizeof line, stdin) != NULL)
        const char *p = line, *longest_word;
        size_t len, longest_len = 0;

        while ((p = next_word(p, &len)) != NULL)
            if (len > longest_len)
                longest_word = p;
                longest_len = len;

            p += len;

        printf("Longest word: %.*s\n", longest_len, longest_word);

    return 0;

Also note that your thread titles are very uninformative.

Yeah well nobody has bothered to reply and I guess someone has send you to comment on this as no one has even bothered to reply...!!!

I merely noticed that you bumped all of your questions as I was perusing the forum.

One side you're saying 6 days is a long time and on the other you said that I'm nagging for replies because I was not getting them fast enough (Are you even sure about what you are saying ???)

Quite sure. 6 days is a long time on an active forum, which means if you haven't gotten a reply in that time, chances are good nobody knows the answer or wants to reply. I fail to see how this is difficult to understand.

I never said that Daniweb offers any guarantee (3 years is a long time to understand that)

Your behavior suggests that you feel entitled to answers. Is it unreasonable for me to mention that Daniweb makes no guarantee?

So, is this the way we all should go over this community meant for supporting people in the areas where they've got their expertise and you would tend towards no longer expecting an answer ???

It seems that your anger is getting in the way of rational thought. You posted a question to a group of volunteers. Nobody volunteered to answer. Now you're getting pissed off when I suggest that you shouldn't expect an answer and to consider alternatives.

You already asked for help. Either nobody knows the answer or nobody who knows the answer has bothered to reply. Nagging for replies because you're not getting them fast enough is more likely to be counterproductive.

Daniweb offers no guarantee of help, so if you're not getting the help you need, I'd suggest looking for alternatives. 6 days is a very long time on an active forum like this one, so I'd tend toward no longer expecting an answer.

What it does is it freezes you entire main thread in your program for the length of the durration

No, it causes the current thread to go to sleep for the specified duration. The logical next step is to use a separate thread for your UI (or a BackgroundWorker), if you need to perform work while also signaling updates to the UI. Oddly enough, minimal research into Thread.Sleep and the problem of UI updates will produce exactly that information. So strange... :rolleyes:

Basically any cookie that is not required for the site to work needs confirmation first

Technically any cookie that the site uses is required for the site to "work", because lack of the cookie would be removing a "feature" of the site that would otherwise be provided. ;)

i am trying to google too but i cannot find any info on this.

You may have better luck if you search for "strdup implementation". Your copyString() function already has a de facto name of strdup. The implementation is dead easy, but you'll need to remember to call free() on the returned pointer when using that function.

Also note that strdup is not a good name as it invades the compiler's reserved name space.

The best pickup line in the universe ever is to be good looking and fit.

That's not a pickup line, it's a set of physical traits. The idea behind pickup lines is that for some reason or another (eg. you're fishing out of your league, your target is overconfident in their attractiveness) you need to build a case to woo them. Good looking alpha males don't need pickup lines because they naturally attract and are pursued by women.

it doesn't matter how nice, genuine or confident you are

Nice and genuine, agreed. Confident, not so much because confidence is an attribute of the alpha male, which would contribute to a woman's attraction to a man. See below for details on the theory.

women are just as shallow, if not more so than guys.

I'd say equally shallow, but in different ways if you consider the gender roles that have prevailed through our societal evolution (ie. the most successful familial structure).

Studies and experiments have shown that attractiveness to a woman is heavily influenced by signs and signals of wealth and status (the so-called "Alpha Male"). This makes sense when you consider the biological imperative of seeking out a mate who can successfully handle the protector/provider role for her and her children.

On the male side, the biological imperative targets signs and signals of fertility as being attractive. Men who would be dumped into the decidedly disadvantageous protector/provider role needed to be reasonably sure that their mate would ...

We require proof of effort when helping with homework questions. What have you done so far? Do you know how to calculate the average of N numbers manually? Do you know how to create and populate an array?

Is there something I'm missing here?

Unfortunately, I'm not familiar with Objective-C, so your best bet would be to post your current code to the Objective-C forum so that the experts there can help out.

This looks promising.

That's a problem because your code will not compile as C, and if you ask questions in the C forum, the first thing you'll be told is one of the following (depending on how helpful and familiar with Objective-C the person is):

  1. Your code is not C and is wrong.
  2. Your code is Objective-C and you're in the wrong place.

If you want to learn C, learn C, not some bastardization of C and Objective-C that may not compile as either.

It looks like you're mixing standard C and Objective-C. Note that this is the C forum, did you mean to post in the Objective-C forum?

my code is totally correct ...because i compile and then post here!

Then your compiler is broken, because it's accepting nonexistent headers.

So, it's not a very good time to be clinging to orthodoxies.

Make no mistake, I'm very open to new concepts and ways of making things better. For example, I have used both Boost.Program-Options and Boost.Parameter because they're good ideas and neat implementations. I've rejected them from a position of experience, it's not just some knee jerk reaction to all things new. In the pursuit of better methods we can't forget that what's worked in the past has worked for a reason.

More like a laboratory, which is just to say that it's a playground with expert supervision.

It seems we see it the same way. Sadly, we're in the minority. Just about everyone I talk to thinks Boost is essentially C++'s version of CPAN.

And jrd::Menu menu("A) Option A;A|a;B) Option B;B|b;Q) Quit;Q|q"); is beautiful?

I'd argue that flat file formats (of which that format string is derived) are well understood to the point where it's not excessively krufty. Further, the kruft is limited to the string and doesn't involve what I'd consider to be an unconventional coding style as in the chain of addOption() calls.

But I guess that won't satisfy you esthetic requirements either. ;)

Actually, it looks more conventional, but it's even worse because the macros lie about what's happening. You're not executing an if chain, you're building a menu inside an object. Given the choice of the original code and the macros, I'd pick the original because it's more clear what the intended behavior is.

I know that was a joke, but a serious response may help elaborate on my reasoning. ;)

this pattern of creating the object by several calls like the addOption() function above is a bit weird-looking, but it is very useful.

I don't disagree that it can be useful, but weird looking code should be limited to places where it's genuinely a very superior option because it's weird looking. I'm a strong proponent of transparency at a glance. If I can just look at a piece of code and have a good idea of how execution flows, it's transparent. If I have to linger and mentally parse what's happening then it's not transparent.

That's actually my beef with modern C++ (template metaprogramming being a ...

menu.addOption( "A) Option A", "A|a", []() {...

Elegant and nifty, but it's kind of ugly, no? ;)

I'd love to see implementations of these pattern based solutions. I'm still not seeing any benefit.

I am wondering if the Builder pattern would be a candidate for being applied here?

Maybe you're thinking of doing it in a cool way (if so, please share!), but I can't think of any benefit to the Builder pattern that would justify the added complexity. Of course, I'm not a fan of design patterns in the first place, so I'm a little biased. ;)

I am planning write a push_back interface for the Dynamic Array(as in the std::vector in C++).

I actually included that functionality at first, where there was both a size and capacity member in the darray. But there was an intended usage problem. With an automatically growing dynamic array you basically have to take full control over the size and disallow direct element access. Everything has to go through the add/remove interface, otherwise the actual size and reported size may not match.

The intention of the darray is to simplify resizing rather than give up full control over the array, so I cut out the size and left the capacity. Now the library is basically little more than a C array where the size can change at runtime. So rather than a true vector (a la C++), it's a slightly more flexible array.

I think adding vector-like behavior to darray would be best implemented as a wrapper around the library, and possibly even as an opaque type so that direct access to the darray isn't allowed:

struct vector {
    darray base;
    size_t size;

extern void push_back(vector *p, void *item);
extern void insert(vector *p, size_t pos, void *item);
extern void erase(vector *p, size_t pos);

I actually had planned on writing a sort tonight. Well, i'll think of something else to add.

How about a stable sort? :)

So that the additions and suggestions aren't lost to github, here are two more public functions and one private helper. The first is a generic swap, since the storage for the darray may be confusing and awkward to work with directly. The second is a heapsort implementation:

static bool do_heap(darray *p, size_t i, size_t n, int (*cmp)(const void*, const void*));

        Swaps two elements in the darray pointed to by p. If the
        swap could not be completed, false is returned. Otherwise
        true is returned.
extern bool darray_swap(darray *p, size_t pos1, size_t pos2)
    if (pos1 >= p->capacity || pos2 >= p->capacity)
        return false; /* Out of range index */
    else {
#if __STDC_VERSION__ >= 199901L

            VLAs can be risky due to the runtime size not under programmer
            control. So if the size is greater than a threshold, use
            dynamic allocation. That should rarely happen here, if ever, 
            because the item_size is assumed to be the number of bytes 
            in an object.
#define VLA_LIMIT 1024
        unsigned char temp_base[p->item_size < VLA_LIMIT ? p->item_size : 1];
        bool dynamic_temp = false;
        void *temp = temp_base;

        if (p->item_size >= VLA_LIMIT) {
            temp = malloc(p->item_size);
            dynamic_temp = true;
#undef VLA_LIMIT

#else /* __STDC_VERSION__ */

            Prior to C99 we can't take advantage of a stack-based
            array with a runtime size. At least we can't without using
            something nonportable like alloca(). To keep the library
            portable, malloc() is used, despite slowness.
        void *temp = malloc(p->item_size);
        bool dynamic_temp = false;

#endif ...

I know it is just text. but registers are not text.

You asked about cx, bx, etc. Those are assembly language representations of the different registers. So yes, they are text. ;) It should also be fairly obvious that I'm just messing with you.

And yes, physical registers are real memory locations burned into the CPU.

This is obviously allways defined, so I assume the purpose is to comment out or remove the define if done debugging.

Yes. This isn't modularized as a library, though that would be relatively simply by adding a header, it's just a single file for exhibition purposes. The whole TEST_DRIVER preprocessor stuff is really just there to highlight that it's a sample driver with some simple test data.

it will hardly take 10 min to you to get the concept

I think you overestimate my ability. I find this data structure neither interesting nor important to learn to the point where I'm qualified to teach about it, so I have no intention of spending my free time doing so. Sorry.

I_m_rude commented: :'( +0

ancient dragon will you please tell me that what is that problem of '\n' with fgets. i am not getting it from your answer. will you please explain it more . isn't scanf appends '\n' to the end ? please clearify me.

Try it and see. You can't always rely on someone else to explain things to you, often a little test program is sufficient to answer your own questions.

Nevermind, I'm wrong. The const applies to the whole of the typedef, so this:

const hello ptr1, ptr2;

Is equivalent to this:

char * const ptr1;
char * const ptr2;

Sorry for the misleading information, I'll blame it on rarely using constant pointers and never wrapping pointers in a typedef. ;)