Posts by deceptikon - Page 26

Why dont we use '&' in the case of strings in function scanf ??

e.g. :-

scanf("%s",date);

here date is a character arraymeans string.

Because date is already a pointer in this case. There's no need to add another level of indirection with the address-of operator.

@Deceptikon: Back in the days of Turbo C, I remember folks saying never put an array in the arguments, and instead use its pointer AND the same thing about struct's.

While it's true for struct instances, arrays have always been passed "by pointer", even in the prehistory of C. When you pass an array to a function, a pointer to the first element is created and sent by value, so the only thing that gets copied is an address. Note also that these three declarations of the parameter are completely identical in every functional way:

void foo(int *a);
void bar(int a[]);
void baz(int a[N]);

The latter two declarations are a convenience and under the hood will be treated as if they were the first. In the last declaration, the size of the first dimension is allowed syntactically, but ignored semantically. You can verify this with a simple program that would give at least a warning if the size were meaningful:

void foo(int a[10]) { }

int main(void)
{
    int arg[5];

    foo(arg); /* Size mismatch? */

    return 0;
}

The folks who were saying that an array parameter could be passed by value were mistaken.

I'm tempted to say that if you pass an array of specific size to a function expecting a specific size, it will pass by value, but I don't know.

That's quite impossible if we're talking about a conforming C compiler because passing by value would break the guaranteed …

Q1. Languagess are system software or application software?

Neither. Languages aren't software at all, they're abstractions designed to simplify the task of humans giving instructions to a computer. A programming language is nothing more than a set of grammatical rules that, when consumed by a compiler or interpreter, represent a consistent set of machine instructions.

Q2. In which software the languages are written? for example in which software the c++ language is written?

The answer to the previous question makes this question nonsensical.

set_union() assumes that the output iterator points to a collection with enough existing space to hold all of the results. If you're planning on using an empty vector or have set_union() grow the vector then you'll want to do it through a back inserter.

aren't you confusing them all the time when coding once in one language, and then in another ?

Only rarely, and only with languages I don't use on a regular basis.

Isn't it better to be splendid in 1 language than to be mediocre in 5 ?

There are some benefits to fluency, but they're vastly overwhelmed by the quality of the programmer. A good programmer doesn't become mediocre by using an unfamiliar language, and a mediocre programmer will still be mediocre regardless of fluency in a language.

I think it's more important to learn multiple languages for two reasons:

1. A programmer who can hit the ground running (ie. already knows the implementation language) is far more marketable.
2. Learning wildly different language families (Algol derivatives versus LISP variants, for example) gives you valuable insight by forcing you to change the way you think. In practice, I've found that the ability to think squiggly is mighty handy, and experience with different ways of going about the same thing is the best way to practice that skill.

The syntax for PHP is derived from the C family of languages, Ruby isn't. You'd feel more comfortable with PHP, but it's generally a good idea for programmers to have some familiarity with different language families.

Is it possible to overload one operator more than once?

Yes, but only if the parameter types are unique. Operator overloading is no different from regular function overloading in that the signature (not including the return type) must be different for overload resolution to be unambiguous.

That was a serious question given that it came from left field and struck me as the ravings of a belligerent drunk, but I apologize if you were offended.

Since we're asking for apologies in name calling I'd ask you to apologize to Vernon for calling him an idiot, but I'll be satisfied if you create a new thread with your specific grievances so that this thread is no longer derailed.

Of course, you're still welcome to offer constructive suggestions as requested by Dani in the first post.

I'm going to go into pedantic mode for a bit. Apologies if either of you are offended in the process.

#include <conio.h>

C is a widely portable language, which means it's possible to take code and compile it on a multitude of operating systems and compilers without any changes. But that doesn't mean code is always portable; it's the job of the programmer to make sure that code is as portable as possible while still doing what needs to be done.

Now, that said, conio.h is not a portable library. Even if a compiler supports it, the functions that are supported within can vary greatly. One excellent example is the clrscr() function which is only supported (to the best of my knowledge) by Borland compilers, yet it's very commonly--and unnecessarily--included as a first step in many example programs:

#include <stdio.h>
#include <conio.h>

int main(void)
{
    clrscr(); /* Not needed and not portable! */

    printf("Hello, world!\n");

    return 0;
}

On a side note, I'll be happy to explain the issues with clrscr() in another reply if you're interested. The result is that these example programs are only compilable without change on the same compiler used to test them (assuming they were even tested). The closing getch() is another example shown in this thread:

#include <stdio.h>
#include <conio.h>

int main(void)
{
    printf("Hello, world!\n");

    printf("Press any key to continue . . .");
    fflush(stdout);
    getch(); /* Not portable and only conditionally needed! */

    return 0;
}

Using getch() …

The short answer is you can't. The long answer is you can if you aren't pedantic about it.

An array can be copied by value by wrapping the array in a structure and then passing an instance of that structure. When the structure instance is copied, the array goes with it as a data member. Technically you're not passing the array by value, you're passing the structure instance by value, but the effect is the same:

#include <stdio.h>

struct foo { int a[10]; };

void bar(struct foo arg)
{
    /* Notice how the sizeof trick works */
    for (int i = 0; i < sizeof arg.a / sizeof *arg.a; i++)
    {
        printf("%d ", arg.a[i]);
        ++arg.a[i]; /* Won't affect the original array in main() */
    }
}

int main(void)
{
    struct foo x =
    {
        {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
    };

    bar(x);
    putchar('\n');

    for (int i = 0; i < sizeof x.a / sizeof *x.a; i++)
    {
        printf("%d ", x.a[i]);
    }

    putchar('\n');

    return 0;
}

Well, you could take advantage of the way the numbers are patterned. Notice how your triangle fits perfectly if you replace everything less than or equal to N with asterisks, where N starts at 6:

int j;
int x = 6;

for (int i = 1; i < 6; i++, x--)
{
    for(j = 1; j < 5; j++)
    {
        if (j >= x)
        {
            System.out.print("*");
        }
        else
        {
            System.out.print(j);
        }
    }

    for(int k = j; k > 0; k--)
    {
        if (k >= x)
        {
            System.out.print("*");
        }
        else
        {
            System.out.print(k);
        }           
    }

    System.out.println();
}

Obviously this won't work without the incrementing and decrementing number pattern.

Shouldn't the boolean "isDuplicate" go before the integer "getScores", so there aren't initialization errors?

The only requirement is that it's declared before use. The given code was only a snippet, which suggests that something along the lines of the following was assumed:

bool isDuplicate(int* student_ids, int head_count, int id);
int getScores(int* student_ids, int* scores, int max_students);

...

int getScores(int* student_ids, int* scores, int max_students)
{
    ...
}

bool isDuplicate(int* student_ids, int head_count, int id)
{
    ...
}

I read its bad to use conio.h, and i use getch() from that header. If i have a new project that needs such function, is it good i to write it on my own? What would the mass of programmers do?

getch() is "bad" because it's non-portable. Whether it's actually bad in a practical sense depends on why you use it. For example, one of the classic clueless programmer red flags is using getch() to pause the program:

#include <iostream>
#include <conio.h>

int main()
{
    std::cout << "Hello, world!\n";
    getch();
}

On top of being only conditionally necessary[1], this destroys portability by limiting the code to compilers that support both conio.h and getch(). It's generally seen as stupid by clueful people to decrease portability without good reason. Another fine example of unnecessary loss of portability (and also conveniently another clueless programmer red flag) is the supremely arrogant and idiotic concept of starting a program with clrscr():

#include <iostream>
#include <conio.h>

int main()
{
    clrscr();
    std::cout << "Hello, world!\n";
}

However, if you're using getch() to legitimately accept raw input where the functionality of the program depends on not buffering said input and cannot be suitably replaced with a portable solution, that's fine. One example would be a password input function where you replace each typed character with an asterisk. There's no way to portably create that effect, so when you have no choice but to use a non-portable solution, the portability criticism goes away.

I'm not sure I understand the requirement. It looks like start and finish are related, in which case sorting by finish time would be more meaningful like this:

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

struct ElapsedTime
{
    int start, finish;
};

int compare_elapsed(void const* a, void const* b)
{
    struct ElapsedTime const* pa = a;
    struct ElapsedTime const* pb = b;

    return pa->finish - pb->finish;
}

int main(void)
{
    struct ElapsedTime times[] = 
    {
        {1, 5},
        {5, 11},
        {3, 4},
        {1, 2},
        {5, 9},
    };
    int n = sizeof times / sizeof *times;

    qsort(times, n, sizeof(times[0]), compare_elapsed);

    for (int i = 0; i < n; ++i)
    {
        printf("%d, %d\n", times[i].start, times[i].finish);
    }

    return 0;
}

The difference being that it's an array of structs where each struct has only a single pair of times, then the array is sorted according to the finish time. This design strikes me as more reasonable, but I am making an assumption based on experience rather than what your actual requirements are.

Don't post working answers.

No worries, bakabozza didn't post a working answer. There are a number of problems with the posted Init() function such that it's completely unusable without fixing some fundamental errors. And this is excluding the required addition of scaffolding to make it compile.

Vertical tab and form feed are exactly what you'd think, and they really only apply to things like line printers or ancient hardcopy terminals. Note that those were part of the language way back in the 60s where such things were far more common than now. You're not likely to use either of them in modern code.

Concerning vertical tab, the standard says that the following is unspecified:

The behavior of the display device if a vertical tab character is written when the active position is at or past the last defined vertical tabulation position (5.2.2).

However, and this is important to recognize: horizontal tab has the same unspecified behavior:

The behavior of the display device if a horizontal tab character is written when the active position is at or past the last defined horizontal tabulation position (5.2.2).

Notice how the wording is identical with the only difference being an exchange of "vertical" with "horizontal". Essentially the same wording is used for printing any character at the end of a line, backspace, horizontal tab, and vertical tab. Ultimately this implies that the behavior is unspecified if you produce any output at all. :D In other words, don't worry about it.

some one correct my program and let me continue my execution .............

I did take a look at the code, and you're clearly dereferencing null pointers. Here's one example:

a=a->next;
a=malloc(sizeof(struct node));      
a->name=c;
a->next=NULL;

The first a = a->next makes a a null pointer. Why? Because a is equivalent to g from main(), and while g is a valid node object, g->next is NULL. So what you need to do is allocate memory to a->next, then move to the new node.

But this still doesn't fix the problem because you're basically throwing away all references to the objects you're creating by modifying a directly and then returning it to be assigned to g.

The following gins() at least allows the program to run to completion for a very simple test.

struct node* gins(struct node* a)
{
    struct node* p = a;
    char c;

    do
    {     
        printf("\n enter  vertex else a space\n");     
        scanf("%c", &c);         
        fflush(stdin);

        if (c != ' ')
        {
            p->next = malloc(sizeof(struct node));      
            p = p->next;
            p->name = c;
            p->next = NULL;
        }
    }
    while(c != ' ');

    return a;
}

Learn to do that yourself. It's very important, and I'm not going to do it for you a second time. You strike me as exceptionally lazy and helpless, and your presumptuous attitude about deserving freebies is irritating as well.

According to the documentation, the first parameter represents the previous result of the function. In the case of the first call, you'd seed it to "null":

unsigned long checksum = /* Saved checksum */
FILE* fp = fopen("file.txt", "r");

if (fp)
{
    unsigned long sum = adler32(0, 0, 0);
    char buf[BUFSIZ];

    while (fgets(buf, sizeof buf, fp))
    {
        sum = adler32(sum, buf, strlen(buf));
    }

    fclose(fp);

    if (sum != checksum)
    {
        panic("Invalid checksum");
    }
}

void foo(string & s = "default");

Make it a const reference:

void foo(string const& s = "default");

It's really no different from just calling a function taking a reference with a string literal:

#include <string>

using namespace std;

void foo(string&) {}

int main()
{
    foo("test"); // Error, "test" is an rvalue
}

data.read(reinterpret_cast<char*>(corpData), sizeof(corpData));

This is an exceptionally bad idea because the Division type (of which corpData is an array) contains non-POD object types, std::string to be precise. You can't safely treat non-POD types as sequences of bytes for two very importan reasons:

1. The structure of the object is dependent on many things, and internal "dead space", or padding, can create trap representations that will likely crash your program.

2. Classes that manage dynamic memory internally won't be able to reproduce their structure or data simply by xcopying bytes from a file into an object that's not specifically prepared for the data. This is the most likely cause of your current crash.

I strongly recommend that you take a step back and do I/O in a simpler manner. Instead of trying to pun your data into a sequence of bytes, write and read each element of the array in a precise manner, field by field. It might be more tedious because you can't use a one-liner like read() or write(), but it's much safer.

An alternative is to support a serialize() and deserialize() process in your Division objects. This would produce a sequence of characters that can be safely read and written using the binary one-liners of read() and write().

So to summarize, these two lines are broken and need to be replaced with a different solution entirely. There's no way to make them safe as-is:

data.write(reinterpret_cast<char>(corp), sizeof(corp));
data.read(reinterpret_cast<char>(corpData), sizeof(corpData));

No offense, but while I could do your debugging for you and tell you exactly what the problem is and how to fix it, you wouldn't learn jack from that. Given that this is the first of many, many, many access violations you're sure to encounter, you'd benefit greatly from learning how to troubleshoot the problem on your own in a very simple program.

Aha! so is it completely fine to drop "iterator" and template <typename Iterator> ?

Yes, but only if you replace any use of Iterator with the appropriate corresponding type. In your example, int isn't the correct type; it would be int* because that's the correct "iterator" type for an array of int. It's important to recognize that the template parameter is just a fancy cut and paste. It figures out what type you're actually using and replaces the template with a concrete definition using that type. Note that we're working with addresses here, not data values, so the correct conversion (and what the template system would do automagically) results in this:

#include <iostream>
#include <algorithm>
void heap_sort(int* begin, int* end)
{
    std::make_heap(begin, end);
    std::sort_heap(begin, end);
}
int main ()
{
    int a[ ] = {1, 2, 3, 4, 5, 6, 7};
    const int n = 7;
    heap_sort( &a[0], &a[n]);
    return 0;
}

You must have a valid iterator, even if the concrete form of the iterator is a pointer, because that's just how make_heap() and sort_heap() are written. If you're writing your own heap sort algorithm you can do what you want and make it work by passing two indices, but when using a library you have no choice but to conform to its design.

The error you're getting typically means there's an access violation. Access violations are typically caused by invalid pointers, so your first line of attack should be to step through your code in a debugger and keep a close watch on your pointers to make sure that they're valid at any given time.

The thing is, I don't know what's the "Iterator" doing exactly and what's begin/end, how can I use arrays with the former piece of code?

"Iterator" in this case is a generic term for the location of the first item in the collection and one past the last item in the collection. You can translate it directly to arrays like so:

int a[] = {1, 2, 3, 4, 5, 6, 7};
const int n = 7;

heap_sort(&a[0], &a[n]);

&a[0] is the address of the first item, and because arrays are indexed 0 to n-1, &a[n] is the address of one past the last valid item. Note that this is perfectly valid. The C++ standard explicitly allows you to take the address of one past the last valid index, and as long as you don't try to read the valid there, it's completely safe.

That's all fine and dandy but it does NOT explain the fact that my strings change their values for no apparent reason.

Yes, it does. Let's do a little visualization:

 a   b
---------
| | | | |
---------

Copy "12\0" to a (note how a isn't big enough, so it overflows into b):

 a   b
---------
|1|2|0| |
---------

Copy "x\0" to b (note how the \0 from a is overwritten):

 a   b
---------
|1|2|x|0|
---------

Print a, and the output is everything up to \0: "12x"

You're a victim of buffer overflow.

toupper() both accepts and returns an int to account for EOF. You need to assign that result to a char or cast it before printing:

writefile << (char)toupper(ch);

If all you're doing is excluding the 'b's then it's as simple as this:

for (i = 0; i < length; i++)
{
    if (writtenStuff.charAt(i) != 'b')
    {
        Console.out.print(writtenStuff.charAt(i));
    }
}

1. If the search string is "abcdefg" and the search key is "xyz", there's no point searching beyond 'e' because a shorter search string than the key is guaranteed to not match.

2. test is an abritrary label for the break statement. If it doesn't exist, the continue and break statements won't know where to jump to. Read up on the goto statement, it's a better way to get introduced to unconditional jumps.

3. Step through the code in a debugger and you'll find it easier to wrap your head around exactly what's going on. I'm not sure anyone will be willing to hold your hand through the entire algorithm, simple as it is.

and the .h is depreciated in the C++ language nowdays.

You mean deprecated, and that's still not correct. Deprecated is a term used for standard C++ features that have been superseded by another feature and are no longer recommended for use because they may be removed from the standard in a future revision. <iostream.h> was never a standard header, it was morphed into
<iostream> during development of the first release of ISO C++, so deprecation status is impossible.

<iostream.h> is simply non-standard.

I quote each on in a single post, in the order that they appeared.

You can quote one of three ways:

1. Select the text you want to quote and click inside the reply box. The text will be pasted and quoted automagically.
2. Manually paste the text with a Markdown quote tag.
3. Use the quote button on the reply editor.

The easiest is the auto-quote, but it's kind of quirky right now. It takes some getting used to. ;)

Perhaps point 2 answers that question?

That would be my guess. But that information is also incredibly useful in dealing with spammers and other less savory types. I can't imagine how difficult those spam attacks under vBulletin would have been without that feature.

I work for a consulting firm rather than freelance, but technically the work is still contract. So....

1. We charge the same base hourly rate across the board, with business and after hours charges for support.
2. Work is work. As long as you can show a steady stream of contracts as opposed to sporadic contracts, I wouldn't look down on a span of contract work.
3. This is outside of my experience, but I wouldn't imagine that being a sole proprietor would be terribly risky as long as you have a lawyer draw up or review your contracts. The important part of liability is knowing when to take the reigns/make decisions and when to step back and allow others to take the risks.
4. Prospective employers should understand that there may be a poor fit in the mix. The real red flag is a lot of short term permanent jobs on your resume. This suggests a job hopper who's more of a drain on the company's resources.

Makes a change from when it was all the C/C++ people :)

I'm curious to see what kind of attitude shift will result from this. The C/C++ folks can be a nasty and unrelenting bunch (*cough*Narue*cough*). ;)

I just asked for a link for these so-called federal guidelines.

That's fine, and to ensure that you get exactly what you asked for, I'm leaving the answer to the person who has all of the specifics.

I also asked for something reasonable: an explanation of exactly what bothers you so much about our policy.

Well.. m sorry to go against what u just said zeroliken, but it isnt undefined... Its how the prefix and postfix operators work..

Nope, it's definitely undefined because i is modified more than once between sequence points. The commas in a function call don't count as sequence points.

Try this and this should give u the output as 1,2,3.

Undefined behavior includes doing what you expect, so empirical "it works for me" evidence is completely worthless. In the case of undefined behavior, we must refer to what the language standard says.

Try calling perror() after fopen(). I notice you're not checking to see if the file was successfully opened before trying to read from it.

how do you prefer your code ?

I'm a code aestheticist, so beauty comes a close second to function. Typically I favor transparent code rather than comments because comments tend to make the code uglier unless you do it well. I like consistency (such as indentation and general code style stuff) and balance (one long line in a file full of short lines chafes, for example).

Honestly, I think that if you're worried about the structure of your code, being consistent and balanced is a fantastic start toward writing "pretty" (aka. readable) code.

You're getting that error because pointers aren't magic. If you want a pointer to point to N bytes of memory, you must ensure yourself that the memory exists and assign the base address of that memory to the pointer.

The specific problem here is that you're using uninitialized pointers as the destination objects for scanf(). scanf() expects there to be sufficient memory (which in and of itself is problematic with the %s specifier and no field width) when no such memory exists.

erik's suggestion will work, though it will certainly lead to that problem I mentioned briefly concerning %s without a field width. Alternatively you can allocate memory to the pointers with malloc(). However, I think a better solution would be using "large" buffers to hold each string and then allocate just enough on a case by case basis:

char login[1024];
char pwd[1024];

while (fscanf(fp, "%1023s[^=]=%1023s\n", login, pwd) == 2) {
    user[u].login = strdup(login);
    user[u].pwd = strdup(pwd);
    ++u;
}

I made a few changes:

1. Each %s is now given a field width to ensure that buffer overflow doesn't occur.
2. Instead of testing for EOF, I test for 2 (the number of expected matches) to account for formatting errors in the file.
3. Two input buffers are used instead of the destinations at user[u]. Then user[u] is filled in using the non-standard strdup().
4. A minor nit: while it's unlikely to make a difference, prefix increment is conceptually faster and more intuitive.

Since strdup() is a non-standard function, here's an …

And now for the obligatory question: why do you think you need to clear the screen? There are only a handful of reasons where it makes sense outside of a GUI environment, and quite a few reasons why it's a bad idea in a textual environment (the kind of environment where clrscr() accomplishes anything meaningful).

Here are a couple of good ones:

1. Clearing the screen also clears the output from previous programs. The implcit assumption that your program owns the output window is not safe. Nothing kills a user's interest in a program you wrote like anti-social behavior.

2. Clearing the screen is inherently non-portable. If you can get away with an interface that doesn't require a non-portable solution, the task of porting your code can be simplified. And there's a side benefit of not having to hear purists (such as yours truly) rail on about lack of portability when you discuss your code in places like Daniweb. ;)

Since the OP found the problem but didn't explain what happened for readers of this thread, allow me:

int total[SIZE];
printf("%d",total);

The %d specifier expects an integer value, yet an unadorned total is equivalent to &total[0]. Thus the argument tied to %d is a pointer to int rather than an int, and the compiler is warning that it's probably not what the programmer wanted.

The total array was also not initialized, so trying to print any of it's elements is undefined behavior. Perhaps the OP wanted scanf() instead of printf(), but that's not a safe bet due to the use of fflush(stdout).

All in all, I'm not sure what the purpose of this function is, and that information is necessary to truly fix the problems.

There are many here who can help you when you ask a specific question, but nobody will do your project for you.

Besides the article choice, the editor is possible the worst Ive seen in my life, including old school boards.

The editor and preview are a primary focus for improvement, but it's not going to appeal to everyone. That just goes with the territory. ;) We welcome any and all suggestions for improvements and new features, but if all of your suggestions amount to "let's go back to the old way", you're probably going to be disappointed.

The default back-end for std::queue is std::deque, which grows and shrinks dynamically. std::queue is actually a form of adapter that sits on top of a data structure to provide a convenient interface. std::stack is the same way.

std::deque is implemented in a somewhat confusing way, so you might consider studying how std::vector works intead (it's basically a dynamic array). It grows dynamically as well, but in a much more intuitive manner. That should get you rolling on answering the question: "how have they created something like that?". :)

IT SHWS BGI ERROR :GRAPHICS NOT INITIALISED (USE 'INITGRAPH')

Click here for a solution to your problem.

Do you have a question?

thanks. but how about the in variable before "%s %s". how can you write it in c++?

Whoops, I see you're reading from a file (most likely). You'd need to open an fstream much the same way you open a FILE pointer using fopen():

ifstream in("myfile");

if (in)
{
    ...

    in >> student[x].name >> std::ws >> student[x].num;

    ...
}

Um, triumphost...fscanf() is for input, cout is for output. You probably mean cin:

std::cin >> student[x].name >> std::ws >> student[x].num;

Unfortunately, cin doesn't try to match literal data, but literal whitespace in the *scanf() format string is a special case. It means "extract and ignore any amount or type of whitespace". Conveniently enough, the ws modifier works the same way when used with cin.

Include <climits> for PATH_MAX,and MAXPATHLEN is in <sys/param.h>.

how does fprintf() get know - when the list of parameters is ended ?

It relies on the format string for this information. That's why nothing bad happens if you provide more arguments than the format string uses, but it's undefined behavior if you provide fewer.

Does try { } catch make program slower?

No. There's a performance hit to actually throwing an exception, but if you don't catch it, it'll just propagate up and potentially be unhandled. In the case of exceptions you have no control over such as the standard or third party libraries, there's really no option but to catch it somewhere. For exceptions you yourself throw, that's where the guidelines of only throwing an exception where it's truly appropriate come in (because there's a performance cost when you throw). ;)