Posts by Narue

As much as we'd love to help you cheat (not really), piss off. We help people who are willing to put in some effort, not people looking for a quick and easy answer.

When the hoops you have to jump through to get this kind of behavior through the library are both advanced and somewhat obscure, one wonders what's so hard about manually writing to fout each time you write to cout (or calling a function that does it for you)...

Heh, if you think a riot is starting, you clearly haven't seen a real riot around these parts. ;)

>But what if we're such a curious bunch that we want the
>blunt truth, even if it comes with some hurt feelings?
Curious bunches thrive on rumor more than blunt truth. ;)

>You're not mean enough.
Rawr!

>When printing output to a terminal in C++, should i use "\n", or "endl"???
I recommend using '\n'. For the most part, the stream is flushed in the right places by default, so explicitly flushing it yourself is just an extra unnecessary step.

>Is one lighter, faster, or industry standard?
These two statements are directly equivalent:

cout<<"Hello, world!"<<endl;

cout<<"Hello, world!\n"<<flush;

endl prints a newline character and then forces a flush of the stream. So just printing '\n' is lighter and faster because the flush isn't performed.

>do you advice me to continue with K&R or get another book to continue with ?
If you can handle K&R, I'd recommend going with it as your first weapon. If you can't handle K&R, I always liked "Pointers on C" by Kenneth Reek. I believe it's out of print now, but I'm sure you can find it on Amazon.

>the O'Reilly Book "Practical C Programming" is
Not a very good book. While it's nice that some good coding practices like fgets are used, the overall quality of the code is extremely poor, and the rest of the content isn't valuable enough to suffer the bad code (as it is with, for example, "Algorithms in C").

>"Teach Yourself C in 21 Days"
The whole genre of "Teach yourself in N units of time" is generally weak, though not especially bad.

I think it's overall a better choice to work your way through K&R than to risk learning bad habits from a "for beginners by beginners" book.

On current implementations, you'll probably find that the stdio library is faster than the iostream library. The usual recommendation is to try both and use the one that's fastest on your setup, if all you care about is execution performance.

>If you don't know it by then, you're too late
Not true. All you need to do is find a bored hacker and you can acquire a program like this:

#include <cctype>
#include <cstdlib>
#include <ctime>
#include <fstream>
#include <iostream>
#include <map>
#include <string>
#include <vector>

namespace {
    typedef std::vector<std::string> leet_vec_t;
    typedef std::map<char, leet_vec_t> leet_map_t;

    const std::string config_file = "leet_config.txt";

    double random()
    {
        return std::rand() * ( 1.0 / ( RAND_MAX + 1.0 ) );
    }

    unsigned time_seed()
    {
        std::time_t now = time ( 0 );
        unsigned char *p = (unsigned char*)&now;
        unsigned seed = 0;
        std::size_t i;

        for ( i = 0; i < sizeof now; i++ )
            seed = seed * ( UCHAR_MAX + 2U ) + p[i];

        return seed;
    }

    leet_map_t load_configuration()
    {
        std::ifstream config ( config_file.c_str() );

        if ( !config )
            return leet_map_t();

        leet_map_t leet_map;
        char base;

        while ( config>> base ) {
            leet_vec_t variations;
            std::string leet_char;

            base = toupper ( (unsigned char)base );

            while ( config>> leet_char && leet_char[0] != base )
                variations.push_back ( leet_char );

            leet_map[base] = variations;
        }

        return leet_map;
    }
}

int main()
{
    leet_map_t map = load_configuration();

    std::cout<<"Enter a non-leet message: ";
    std::srand ( time_seed() );

    char ch;

    while ( std::cin.get ( ch ) ) {
        ch = toupper ( (unsigned char)ch );

        if ( map.find ( ch ) == map.end() || map[ch].size() == 0 )
            std::cout<< ch;
        else {
            leet_vec_t::size_type i = 
                (leet_vec_t::size_type)( random() * map[ch].size() );

            std::cout<< map[ch][i];
        }
    }
}

Plug in your favorite l33t config file …

I see two glaring problems with your code.

First, it's very ASCII-centric. C only guarantees that the decimal digits will be adjacent in the character set, so while (c >= 0 && c <= '9') is required to work as expected, (c >= 'a' && c <= 'f') doesn't have to. And subtracting 'a' from the value could have wildly incorrect results on non-ASCII character sets, where non-alphabet characters could be mixed in with the alphabet.

Second, it's redundant. You don't have to duplicate the code for different casing. The standard library (<ctype.h>) offers both toupper and tolower which will convert a character to the upper and lower case formats, respectively, and do nothing with a character that has no such conversion.

Compare and contrast your code with mine:

#include <ctype.h>

int hex_value ( char ch )
{
    const char *digits = "0123456789ABCDEF";
    int i;

    for ( i = 0; digits[i] != '\0'; i++ ) {
        if ( toupper ( (unsigned char)ch ) == digits[i] )
            break;
    }

    return digits[i] != '\0' ? i : -1;
}

unsigned htoi ( const char *s )
{
    unsigned result = 0;

    while ( *s != '\0' )
        result = 16 * result + hex_value ( *s++ );

    return result;
}

Note that I left out error checking intentionally to clarify the logic. An invalid string won't give you sensical results.

>I'm sure tux4life was just trying to help.
I didn't imply otherwise. I said "unintentionally misleading you" because he probably hasn't yet learned these nuances, which is quite understandable and there's nothing wrong with that. Now you've both learned something. ;)

>What do you mean about 7-bit being portable
>and 8-bit upper range not portable?
When ASCII was designed, only the first seven bits were required to hold the characters the designers wanted. To save on transmission costs (we're talking about the 1960's here) the 8th bit was left out of the specification and used as an optional parity bit for error checking if desired.

Instead of using the 8th bit as a parity bit, a bunch of people independently decided to extend ASCII to suit their own needs with regional and special characters. The problem now is that while ASCII itself is widely used (to the point of being adopted into Unicode), there are umpteen different versions of extended ASCII.

When I say something isn't portable, I mean that the same code won't work the same way everywhere. In this case, your output when printing the upper range of extended ASCII will vary.

>i'm assuming that to support a 32-bit unicode character using
>a 16-bit byte, it uses 2 bytes for the unicode character.
Bingo. That's precisely how multi-byte character sets work (including Unicode[1]), except with 8-bit bytes being more common. You might find it fun to study how UTF-32, …

@OP:

I'm sorry to say it, but so far tux has been unintentionally misleading you. Allow me to clarify.

>I've read that the bits in a byte (in c++) are implementation or system dependent.
Yes.

>What does that mean?
It means that you can't rely on a byte always having eight bits.

>Does it mean implementation of c++ or the processor architecture or some other thing?
It's a processor architecture thing.

>And I've read that you should use sizeof to determine the size of a byte?
The size of a byte in C++ is guaranteed to be 1. This can be confusing to some people because the number of bits in a byte can vary, so the actual size of a byte on different systems can be different but the size reported by sizeof will always be 1. You can get the number of bits in a byte by including <climits> and using the CHAR_BIT macro:

#include <climits>
#include <iostream>

int main()
{
    // "byte" and "char" are equivalent terms in C++
    std::cout<<"sizeof char: "<< sizeof ( char ) <<'\n';
    std::cout<<"CHAR_BIT:    "<< CHAR_BIT <<'\n';
}

The output will be 1 and the size of a byte on your system (usually 8).

@tux:

>A byte is just always eight bits
Incorrect. "Byte" is an abstract term for the smallest addressable unit for your system. While more and more systems are gravitating toward the octet (eight bits, for the …

>this time, Narue gets a free solved thread
Thank you, serkan. You've helped me to fully realize that I'm neither wanted nor needed on Daniweb anymore.

string assemblyPath = Assembly.GetExecutingAssembly().Location;
string assemblyDir = Path.GetDirectoryName ( assemblyPath );
string soundsPath = Path.Combine ( assemblyDir, "Sounds" );

>i,ROBOT
>Will Smith fights a robot conspiracy to break the
>"a robot can't harm a human" union rules.
Read Asimov's short stories under the same name. You'll be even more impressed than some cheesy action knockoff could offer. I, Robot and I am Legend are two good examples of the movie totally ruining a good story.

>Enlighten me how?
Step 1: Fill the array using rand.
Step 2: Check for zero and if not present, add it to the end.
Step 3: Randomly shuffle the array.

Apparently you have an extremely limited idea of what a step is.

>in two or more statements?
I can do it in one statement, seeing as how a loop is a compound statement and the shuffle can be done with a single loop. See? I can play games with terminology too. ;)

>My question is, is F# a really good language, and whether it is useful to learn.
It's a decent enough language, and I always advocate learning new languages when you can. F# is useful, to answer your question, but it's not a replacement for C#.

>Is it used for software/application development?
I'm sure it is, but currently I'd wager only with the trailblazers. F# is still a new language and lacks a certain maturity that breeds confidence in choosing it for real projects.

It's pseudocode. It doesn't need to be perfect, it just needs to express your logic accurately. Oh, and do your own damn homework.

>Who says using brackets is better?
A lot of people. It's recommended in all coding guidelines I've seen and required in the majority of them. The rationale is that if you add statements to a block without braces and forget to add the braces, you've introduced a difficult to find logic error. I follow the careful coding guideline[1] so it's not an issue which you choose as far as I'm concerned, but you'll find that braces around every compound statement is considered a best practice.

[1] Careful Coding Guideline: Turn your brain on before starting and keep it on while writing code.

>why does anyone use system("PAUSE"); ??
Because it gives you a pretty message? Because teachers teach it? Because beginners don't, and shouldn't be expected to, know the pitfalls of it?

>I surrender. you are right. I am wrong.
I'm not trying to be right, I'm trying to figure out what the hell your problem is. If you're going to act like a five year old, I'll be happy to treat you like one.

DarthPJB, it's a good idea to not take iamthwee seriously, in pretty much every case from what I've seen.

The state of the stream and the contents of the buffer are separate. Even though you reset the buffer to a new string, the stream is still in an end-of-file state from the previous read.

You'll notice that out_offset is correctly set to 3 because the stream starts off in a good state when you create it. But the first time you read to the end of the initial buffer, the eofbit is set and changing the contents of the buffer won't make a difference.

Do a buf.clear(); to reset the stream state.

>I am new to Daniweb, and I didn't want to search for other people's answers.
Translation: "I'm too lazy to search for something that's sure to exist already."
Alternative Translation: "Even though the questions and answers are exactly the same, they're not mine, and I'm special so I deserve customized personal help."

>I wanted to call someone and get a new interview, and I got that.
How much do you want to bet that you got exactly the same answers a search would have produced?

>What gives you the right to put people down?
I'm a naturally cruel person, it's what I do.

>Does it make you feel better?
Well, now I'm less bored, so the answer to that question would have to be "yes".

>You have no idea what kind of programmer I will be and you shouldn't judge me.
You strike me as the kind of programmer who relies on others to get things done. With any luck my harsh judgment will encourage you to exceed my expectations. If you manage that I'll be thrilled.

>This will be the last time I use this forum.
Guess what? Nobody cares! :) I often wonder why people insist on publicly declaring that they'll never return. It's childish, petty, and really serves no purpose other than to attract attention with the equivalent of "Look at me! I'm stomping off in a huff!".

>Don't kill me! I'm sorry!
Rawr! ;)

Split to a new thread.

>how i can convert string to int in c++ gui mode
"GUI mode" is irrelevant. The process is the same. Have you tried a stringstream?

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

int main()
{
    std::istringstream in ( "10" );
    int i;

    in>> i;
    std::cout<< i * i <<'\n';
}

>Another solution is to make a bundle of the array and its capacity.
Let's consider some of the decisions you have to make:

• Type (generic or non-generic): If you want a generic array, you have a problem because C doesn't support parametric types. You have to hack your way around it using pointers to void, or nasty preprocessor tricks. The former is unsafe, the latter is insanity.
• Memory (dynamic or non-dynamic): If you want to use a real array, you have to figure out how to generate the size of the array without restricting your flexibility of the bundle. Naturally, the bundle itself would be a structure, and for structures to be used across functions, they need to be defined at file scope. If you want to simulate an array using dynamic memory, you need to consider the performance hit of allocation and release.

A reasonable implementation using generic pointers and dynamic memory might look like this:

#include <stdio.h>
#include <string.h>

struct array {
    size_t size;
    void *data;
};

void foo ( struct array *a )
{
    memset ( a->data, 'A', a->size );
}

int main ( void )
{
    struct array a = {10};

    a.data = calloc ( a.size + 1, 1 );
    foo ( &a );
    puts ( a.data );
    free ( a.data );

    return 0;
}

That doesn't really buy you anything over passing the size as a second argument. In fact, it's worse because now you have to deal with an …

>No!...i am using Windows XP!....i have also tried this code on Visual Studio C++ 2008.
Are you really that dense? It doesn't matter one whit what your setup looks like. If your solution doesn't work on the OP's setup, you've been no help at all. Standard C++ supports random numbers. Are you too good for std::rand?

>and why do you think suggesting a c++/CLI solution aint a good idea?....
Because I think the OP may be using a non-Windows operating system and the only compiler available for C++/CLI is Visual Studio, a Windows program.

>i have tried it in visual studio 2003
From the OP's use of <unistd.h>, which strongly suggests that he's on a POSIX system such as Linux or Unix, I don't think suggesting a C++/CLI solution (a language currently unique to Windows and .NET) is such a hot idea.

[psychic debugging]
You probably forgot to terminate your class definition with a semicolon and the constructor definition immediately follows it. The following code should produce a similar error:

class foo {
public:
  foo();
}

foo::foo() {}

The error is saying that the constructor for foo is trying to use the type foo (specified by a class definition) as the return type for the constructor. However, a constructor doesn't have a return type, so the compiler issues a diagnostic.
[/psychic debugging]

>Can I tell now that my friend exists?
I think a more interesting question is how many people will question your sanity if you have a friend that you aren't sure exists? :)

>My example does probably what the OP requires in simpler terms.
Not really, seeing as how the OP was specifically asking for the usage of std::find in the case of composite data, not a replacement for std::find that does the same thing.

>(*hPtr).style = "abc";
You don't copy arrays like this. You also don't compare arrays with the relational operators either. Further, at this point hPtr doesn't point to anything. You need to point it to an address that you own:

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

int main()
{
    struct house
    {
        char style[40];
        int rooms;
        float price;
    } h, *hPtr;

    hPtr = &h;
    strcpy ( (*hPtr).style, "abc" );
    (*hPtr).rooms = 4;
    (*hPtr).price = 10.0; /*values were used so that printf is possible*/
    printf("%s %d %f\n", (*hPtr).style, (*hPtr).rooms, (*hPtr).price);
    return 0;
}

>given a function, how do you tell the size of the array that is passed?
Given a function where the only parameter is a pointer to the first element of said array, you don't. There's no portable method, which is why the usual advice is a second parameter with the size:

void myfunction(char * pointerToString, size_t size)

Excellent! But that still leaves us at an impasse as you still haven't provided enough information for anybody to help you. Please describe your "open hash with B1 buckets" and the desired "one with B2 buckets".

I like to think I'm well versed in hashing and hash tables, but I'm having trouble deciphering what you want.

>you're probably going to explain in great detail why this isn't strange at all right?
Just to be unpredictable, I might not.

>But VS will compile it without warning on warning level 4
>and G++ will also compile it with -Wall (no warning shown).
>That's kinda strange isn't?
Not really. I can see three immediate reasons why a compiler would neglect to implement that constraint.

1. Cost vs. Benefit: Given how often main is called recursively in code (that is, not very), I'd say it's hard to justify adding an edge case feature. You can see that in a bunch of edge cases and gray areas. The vendor simply doesn't allocate enough resources to do it 100% because there's no pressing need.

   One huge example (where both CL and GCC are equally guilty) is export . This is a big complex feature that nobody who understands it seems to want. Both GCC and CL probably have significant code issues where export is concerned and the cost for adding it is prohibitive when taking demand into account.

2. Backward Compatibility: For compilers that existed before C++ was standardized, I have no doubt that they see this constraint as a breaking change. C, of course, supports recursive calls to main, so it's easy to imagine how pre-standard C++ compilers would assume that to remain the case in C++.
3. Additive Risk: When making any change, there's the risk of introducing bugs. This adds greatly to the cost of the …

If you have an actual array, you can use the sizeof trick regardless of the type of the array:

int Rows = sizeof arrString / sizeof *arrString;

This divides the size of the array in bytes by the size of the first element of the array in bytes. Since std::string uses dynamic memory for the string contents, the size of each string object will be consistent, just as if you used an array of pointers to char instead of arrays of char for the first example:

const char *arrChar[] = {
  "Anagram",
  "Book",
  "Computer",
  "Dimension",
  "Epic",
  "Fail",
  "Gyroscope",
  "Hemingway",
  "Irish"
};

int Rows = sizeof arrChar / sizeof *arrayChar;

The actual strings have different lengths, but the size of a pointer to char is constant, so the sizeof trick works.

Now, if you're passing the array to a function, this trick no longer works because inside the function the array is no longer an array; it's a pointer. The ideal solution is to pass the size of the array as a second argument. That's a great deal safer and more efficient than the leading alternative, which is to place a sentinel at the end of the array:

const char *arrChar[] = {
  "Anagram",
  "Book",
  "Computer",
  "Dimension",
  "Epic",
  "Fail",
  "Gyroscope",
  "Hemingway",
  "Irish",
  0 // Sentinel
};

int sentinel_size ( const char **array )
{
  int i;

  for ( i = 0; array[i] != 0; i++ )
    ;

  return i;
}

[psychic debugging]
This describes your problem and shows ways to get around it without changing your input logic.
[/psychic debugging]

>-How did this type of work interest you and how did you get started?
I think I'm well suited to my job, and it interests me greatly. As for how I got started, I did it to win a bet.

>-How did you get your job? What jobs and experiences have led you to your present position?
I got my present job by being very good at what I do, and what I do is be awesome. :cool:

>-Can you suggest some ways a student could obtain this necessary experience?
Open source projects are a good way to get experience without having to convince someone to pay you. I've also found forums like Daniweb to be very instructive. You can solidify your own understanding and give back to the community at the same time.

>-What are the most important personal satisfactions and dissatisfactions connected with your occupation?
When I stop learning, I'll switch jobs. The most important "satisfaction" to me is learning new things.

>-Why did you decide to work for this company?
It didn't require me to relocate.

>-What do you like most about this company?
I get to do what I enjoy and what I'm good at. :)

>-Do you find your job boring or exciting? Why?
It depends on the day. Sometimes I'm having a hackergasm with new and interesting code, sometimes I'm writing documentation. You can guess which of those I find exciting. …

>but it seems that this generator isn´t really random
Any deterministic method for generating random numbers won't be "really" random. That's why they're called pseudorandom numbers. They're sufficiently patternless to appear random for many purposes. "Real" random numbers only come from truly random real world sources, such as the decay of a radioactive material or atmospheric noise.

>because it seems to generate the same "Random"
>sequence chain every time I restart the application
That's a good thing. Imagine trying to debug your program when you can't reproduce the same sequence, ever. The seed for rand defaults to 1, and you can call srand to change it. Here's a demo of seeding based on the current time:

#include <climits>
#include <cstdlib>
#include <ctime>
#include <iomanip>
#include <iostream>

namespace JSW {
    using namespace std;

    // Replaces the conventional but non-portable
    //    (unsigned)time(NULL)
    // as a seed for srand with a portable and
    // equivalent quality seed generator based 
    // on the current time
    unsigned time_seed()
    {
        time_t now = time ( 0 );
        unsigned char *p = (unsigned char *)&now;
        unsigned seed = 0;

        for ( size_t i = 0; i < sizeof now; i++ )
            seed = seed * ( UCHAR_MAX + 2U ) + p[i];

        return seed;
    }

    // Just for output formatting
    size_t digits ( int value )
    {
        if ( value == 0 )
            return 1;

        size_t n = 0;

        for ( n = 0; value != 0; n++ )
            value /= 10; …

Narue,
Because fgets() reads a line up to the \n and loads everything up to the RETURN, isn't it simply a matter of testing the last character in the buffer with \n and if it isn't, they entered more than the requested data? Simple use of strlen() and a test?

Yes, what's your point? If all you want to do is determine if a partial line was read, then looking for a newline is trivial. Ideally one would write code that can handle both cases where fgets reads a newline and where it doesn't. For example:

#include <stdio.h>

int main ( void )
{
    char buffer[5]; // Arbitrary small size
    char *s = NULL;
    size_t n = 0;

    while ( fgets ( buffer, sizeof buffer, stdin ) != NULL ) {
        size_t len = strlen ( buffer );
        char *save = realloc ( s, n + len + 1 );

        if ( save == NULL ) {
            perror ( "Insufficient memory" );
            break;
        }

        strcpy ( save + n, buffer );
        s = save;
        n += len;

        if ( buffer[len - 1] == '\n' ) {
            s[n - 1] = '\0';
            break;
        }
    }

    printf ( ">%s<\n", s != NULL ? s : "(null)" );
    free ( s );

    return 0;
}

But if you're not worrying about long lines, you still need to consider the case where a newline may not be present, which is what I was talking about with the usual naive strlen solution:

>its showing only first one
Then you shouldn't be breaking from the loop after the first match. :icon_rolleyes:

>How can i give the values programatically and not by user selection?
That's even easier. Just replace scanf with an assignment to nv of whatever expression you want:

nv = 5;

/* allocate memory for the adjacency memory */
adj_matrix = (int**)malloc(sizeof(int*) * nv);

>are you understand me??
I are understand you just fine. :icon_rolleyes: You want me to give you code to add matrices, which isn't going to happen because you haven't given us any proof of effort yet. In fact, the only code in this thread was posted by me.

So is it that you don't understand how adding matrices works? Or are you just too lazy to turn it into code?

>do you really want to go back? well lets go back to punch cards and paper tape, then
You lose. Though I do find it humorous that you chose to attack me even after I agreed that your idea is a good one. What exactly are you trying to accomplish?

>Java's error codes are so much more intuative.
Three words: null pointer exception. ;) Anywhoo, you don't have the right to complain about non-intuitive error messages until you've had the pleasure of deciphering about twenty of these guys all at once:

error C2664: 'class std::_Tree<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,int>,struct std::multimap<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,int,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<int> >::_Kfn,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<int> >::iterator __thiscall std::multimap<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,int,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<int> >::insert(const struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,int> &)' : cannot convert parameter 1 from 'const int' to 'const struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,int> &' Reason: cannot convert from 'const int' to 'const struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,int>' No constructor could take the source type, or constructor overload resolution was ambiguous

Three cheers for not having to use Visual Studio 6 anymore. Woohoo! ;)

The error is saying that you declared the FlightManager constructor ( FlightManager(); ) but never defined it. You must give a body to any functions before you can call them.

>hmm, what do you mean do the same thing?
I'm beginning to suspect that you're not suited to the mental rigors of programming. :icon_rolleyes:

Remember when I showed you how to change the BackColor of the panel? Here, I'll show you again in case you forgot:

panel1.BackColor = Color.Yellow;

Instead of panel1, type button2 and see what happens. All of these things are derived from a base class called Control, and Control is where the BackColor property comes from. What that means is you can set the BackColor property for any object derived from Control and it will magically do the "same thing".

Good, god. Haven't you ever heard of proofreading?

And to answer your question, jealousy is fine as long as you use it productively.

>Will a-'0';
>be true for all the constants.in different character map sets?
Digits are required by the C++ standard to be contiguous, but if you need to convert to hexadecimal, you can't portably use that trick. Try an array instead, using the index as your value:

const char digits[] = "0123456789ABCDEF";