Posts by Narue

>whether it's attributable the to size of the class or not I don't know
Only actual data (explicit data members, hidden data members, and padding) adds to the size of an object in memory. Member functions are stored elsewhere, and not duplicated for each object.

>At least that's how my reference explains it.
You might be misunderstanding your reference. There's an implicit conversion operator and a function call operator The function call operator is a general member function in terms of return value and parameters. The implicit conversion operator takes no parameters ( *this is implied) and the return value of of the type the operator defines. Non-explicit copy constructors and assignment operators give you an implicit conversion in the opposite direction (from whatever type to the type of the class):

#include <iostream>

class foo {
  double base;
public:
  // Implicit copy constructor (type T -> new type foo)
  foo ( double d )
    : base ( d )
  {}

  // Assignment operator (type T -> existing type foo)
  foo& operator= ( double d )
  {
    base = d;
    return *this;
  }

  // Function call operator (does whatever you might want)
  std::ostream& operator() ( const char *s )
  {
    return std::cout<< s <<'\n';
  }

  // Implicit conversion operator (existing type foo -> type T)
  operator double()
  {
    return base;
  }
};

int main()
{
  foo f = 123.456;

  std::cout<< std::boolalpha << !!f ( "This is a test ") <<'\n';
  std::cout<< f <<'\n';
  f = 987.654;
  std::cout<< f <<'\n';
}

Basically the function call operator gives you the option of making an object act like a function. Hence, the "functor" or function object that jencas mentioned.

>() isn't a operator.
Yes, it is. [] is an operator too, and , is an …

>How can one go about applying the same set of rules to the C and the Ruby forums?
My suggestion was to apply a language specific algorithm to the individual forums. At the very least we can cover the most active forums with a handful of cases and solve the majority of the problem. But I'm not the one writing the code to do this, Dani is. If she doesn't feel a solution is good enough, it won't get implemented, and there's a team of mods available to do the work manually.

As I understand the issue, Dani isn't against an automated solution as long as it's generalized. Every time we bring up the issue, she asks us for a good way to handle checking for code tags with every language that Daniweb has a forum for. A good suggestion has yet to be made, so the issue still stands.

>In the c++/c section 'someone' could add a piece
>of PHP code that checks if the post contains main(
And if the post is a snippet without main? A good test is for an opening brace. If the text contains an opening brace, it's a pretty good assumption that the text is code in the C++, C, Java, and C# forums. However, that approach doesn't work well for pretty much any of the other forums, so it fails the generality test.

The only other option is to be excessively strict about code tags (ie. warn, infract, and ban with extreme prejudice), and that's counter-productive if the goal is keeping people around. :icon_rolleyes:

Now for the original request in this thread:

>Remove all mention of code tags from the site
That's a stupid idea, it's easy to figure out why, and the extremity of the suggestion leads me to believe that you're simply being melodramatic.

Removing all mention of code tags (ie. instructions and reminders) would destroy any positive effect that they have. It's silly to believe that the instructions and reminders are 100% ineffective, …

>Thats not a bad post.. (Nothing wrong with dates)
Assuming the bump is relevant, of course.

>Pass a function as an argument and call that.
By "good way", I meant something that's both easy to use and easy to follow, as well as works across the board without changes. Your suggestion only works for very specific cases and does not scale well.

>what programmers use it for in real-world programs such as system, applications, etc.
Recursive descent parsing comes to mind.

>Parse binary trees
Actually, my experience is that nearly every recursive algorithm when working with binary trees is better written iteratively. This improves the performance[1], footprint guarantees[2], reliability[3], and flexibility[4].

[1] Removal of recursion is one of the first steps in optimizing a recursive algorithm.
[2] It's harder to guess how much memory will be used when variable stack frames enter the picture.
[3] Unless the height of the tree is limited to below the remaining stack size at the point where recursion begins (imagine trying to guarantee this), the possibility of a stack overflow is always going to be present.
[4] A good example of this is re-entrant iteration. I have yet to see a good way to break off recursive iteration and then start it back at the same place (without coroutine support, of course), or change the direction in which you traverse the tree mid-traversal (at least, not without being painfully ugly). With an iterative approach, both of these (very useful) tasks are trivial.

>But where I worry about it the age of the book
No worries, the contents are still relevant.

>You're getting C++ errors. C++ is a lot stricter. Try using a C compiler.
So your advice is to ignore the warning and let the problem silently continue. Brilliant. :icon_rolleyes:

>"cannot convert from" is a C++ (and in general, OOP) only error afaik.
You get it in C as well if you do something stupid...just like C++.

Break the problem down into manageable pieces, then solve each one individually. That should minimize the smothering effect of a complicated problem and you'll end up with specific questions that we can answer and specific problems that we can help with.

Asking for "help right from the scratch" suggests that you want us to do the design grunt work for you, which doesn't teach you anything.

>I do not know if my code will be portable when I start learning it.
It won't be. Assembly languages are only portable to the processor family (and depending on the features you use, the family subset) they're implemented for.

>Do other Assembly languages conform to the same standards
The core concepts are the same across the board, and that's what you should be trying to learn. Don't focus so much on the difference in syntax because syntax is easy to learn. The hard part is learning how to program at such a low level.

>or is the Syntax incredibly different?
It depends. The difference between NASM and FASM is slight, the difference between FASM and GAS takes a bit of getting used to, and the difference between GAS and something like Terse is staggering. The most widely used assemblers implement similar enough syntax such that moving between them is relatively painless.

>Book recommendations would be great!
Since you're using HLA, The Art of Assembly by Randall Hyde would be helpful for the details of the language as well as the concepts of programming in assembly.

>I was just wondering, is it safe to do something like this?
No, an uninitialized pointer doesn't point to infinite usable memory.

>Basically, what if it is impossible to calculate the amount
>of space required to hold everything in the array?
Then you've done something wrong. You should always be able to calculate the size of your memory blocks to within a reasonable margin of waste, or you should be able to incrementally resize your blocks until all of the data is stored.

In your specific case, it's possible to calculate the necessary size for msg by taking the length of fname and adding it to the length of the format string. Alternatively you could use something like snprintf, which is generally better at giving you more information.

For things like streamed input where you simply cannot calculate the final length ahead of time, you're stuck with using a fixed-size block to read chunks and growing the result buffer until there aren't any more chunks.

>1. Pointers increase the efficiency of our programs
They also decrease the efficiency of programs.

>2. Pointers degrade reliability of C++ programs due to security issues
Only if used improperly, just like any other language feature.

I disagree, of course. Quality is paramount even when doing incremental releases. The increments refer to feature sets, not bug fixes.

>>It seems like quite a few people here jump to conclusions that people are looking for homework help.
Since we're quoting ourselves now:

We call it like we see it.

First and foremost, we're all human (except for Salem, who's a C bot). The lack of psychic abilities means we don't know if J. Random Newbie is just having trouble getting his message across, or if he's out to get freebies from nice people so he can pass his class. Because handouts can be so damaging to new programmers, we err on the side of caution and assume that if it looks like homework, it is homework. Very simple.

>Well from wot i no pseudocode isnt real code so how can i test it?
The same way you test real code without running it: trace the execution with paper and pencil using a small amount of sample data. Not only does this give you a better idea of what your code is doing, regular paper tests help you to think like a compiler when you're actually writing code.

>Homework and selfstudy can be completely different things.
In this case, "homework" means a personal project that you have a vested interest in completing, and we don't care about. It could be actual homework from a class, self-study from a textbook, or even something you imagined up. Regardless of how you got started with the project, if you show no effort, you get no help. I fail to see how this is a difficult concept.

>I would say they want to understand what, where and how
We call it like we see it. If you want to understand the nuts and bolts but manage to come off as a leech (usually through poor communication), you'll be treated as a leech until proven otherwise.

That usually happens to me when I forget to close the output window for a debug run.

>in the second implementation the MyException object
>is allocated on heap, but how about the first one?
It's unspecified:

3 A throw-expression initializes a temporary object, called the exception object, the type of which is determined by removing any top-level cv-qualifiers from the static type of the operand of throw and adjusting the type from “array of T” or “function returning T” to “pointer to T” or “pointer to function returning T”, respectively. [ Note: the temporary object created for a throw-expression that is a string literal is never of type char*, char16_t*, char32_t*, or wchar_t*; that is, the special conversions for string literals from the types “array of const char”, “array of const char16_t”, “array of const char32_t”, and “array of const wchar_t” to the types “pointer to char”, “pointer to char16_t”, “pointer to char32_t”, and “pointer to wchar_t”, respectively (4.2), are never applied to a throw-expression. —end note ] The temporary is an lvalue and is used to initialize the variable named in the matching handler (15.3). The type of the throw-expression shall not be an incomplete type, or a pointer to an incomplete type other than (possibly cv-qualified) void. Except for these restrictions and the restrictions on type matching mentioned in 15.3, the operand of throw is treated exactly as a function argument in a call (5.2.2) or the operand of a return statement.

4 The memory for the temporary copy of the exception being thrown is allocated in an unspecified way, except as noted …

>I think it is something to do with srand( time(NULL);
Nope, your logic is just wrong if you want game to end at exactly 1001. Notice how you don't check that condition every time game is incremented. You only check the condition after the inner loop has terminated. game could be incremented several times in the inner loop.

>But what I can't seem to access is the constructor.
This is where the C memory functions fall flat, they don't work well with constructors and destructors. I recommend ditching calloc and using new[]:

CObject *group = new CObject[N];

Or better yet, use the vector container class if you plan on resizing the collection:

#include <vector>

...

std::vector<CObject> group ( 1 ); // Start off with 1 element

It means you probably wrote to memory you don't own, perhaps by overrunning a buffer, freeing memory more than once, or forgetting to initialize a pointer before using it.

Your question is vague enough that if you have special needs, a direct answer isn't going to be what you want (especially since the most direct answer is "What have you tried?"). So how about you tell us exactly what you're doing so we can offer more appropriate advice.

>Anyone got any idea how to enable support in GCC or where is the actual problem ?
What you want (to a point) is some kind of extended character set for your compiler. Unicode is widely supported by compilers these days, so for example you can already change "Hello" to "안녕" and x to ㅂ if your compiler supports Unicode.

What you can't do is replace if with 만약 because that changes the code points, and thus, the meaning of the keyword. Regardless of the native language you want to program in, the English keywords of C++ will remain English unless you write some kind of preprocessor to convert your native language translations of the keywords to valid C++.

>I have little chance of actually getting anywhere in the game development
>industry - because I am not getting a degree that is specifically game related.
I'd say your friend is full of it. Ability trumps education every time, and the gaming industry is especially well-known for turning basement coders into millionaires. A degree in CS won't hurt you (it'll probably help more than the specialized degree, but I'll get to that in a moment), and a good portfolio will go much further than a degree from a "game programming college".

Now, the reality is this: game development is very competitive. You'll be going up against some extremely talented people, so unless you're one of them, it's likely that you won't end up with your dream job for a while. In that case, a general CS degree can benefit you more than a game programming degree as you work your way into the field.

>So obviously I am missing a fundamental part of the logical not operator.
Let's break it down, starting with the if statement:

if ( ... ) {
  ...
}

If the condition is true, execute the block. Simple, right? Now let's add a boolean test:

if ( x < y ) {
  ...
}

If the result of x < y is true, execute the block. Or in more typical terms, if x < y, execute the block. Still simple, no? What about if we put the result of that boolean test in a boolean variable?

bool test = x < y;

if ( test ) {
  ...
}

If the condition evaluates to true, execute the block. The condition is an expression containing only a boolean variable whose value is the result of the test x < y. The current value of the variable acts as the condition. If the variable is true (ie. x < y), the block will be executed, otherwise it won't. Still simple, right? Now let's start negating:

bool test = x < y;

if ( !test ) {
  ...
}

If the condition evaluates to true, execute the block. The condition is still an expression containing only a boolean variable whose value is the result of the test x < y. But now we've negated that value, so if x < y, the block won't be executed because x < y is true, and negated it becomes false. In …

>template <class T>
>Element* Btree<T>::recins( T& obj, Element* cpoz )
Element is a dependent type, so you need to be very specific about what it is:

template <class T>
typename Btree<T>::Element* Btree<T>::recins( T& obj, Element* cpoz )

>Element *p = new Element( T );
T is a type, you probably meant to use the default value for T like this:

Element *p = new Element( T() );

Also, recins needs to return a value for all execution paths, and you need to include a header (I recommend <cstddef>) that defines the NULL macro.

>Hire is the code.
Giving away homework answers is still frowned upon here. :icon_rolleyes:

>#include <sstream>
>#include <string>
You don't use either of these, so remove them.

>using namespace std;
If you must use this, keep its scope limited as much as possible. In case you didn't know, you can use this in a block and its effect will only apply to that function:

#include <iostream>

void foo();

int main()
{
  using namespace std;

  cout<<"Hello, world!\n";
  foo();
}

void foo()
{
  // std:: is required because "using namespace std"
  // only applies to the main function
  std::cout<<"foo\n";
}

>int array[arrayLength];
While this may work for you, it's not going to work everywhere. Standard C++ requires that array sizes must be a compile-time constant. Arrays with a runtime size are only allowed as a compiler extension, so your code is not portable. If you really want this feature, use a vector instead.

>//Here you could assing the 'int' highest value even though I've read that depends on OS
>32b 64 and I am not sure if I've read that also depends on the compiler. But maybe there
>is a funtion that give you the value at run time.(I'm new to C++)
I assume you mean initializing the variable to the largest possible value. You can do that several ways, but all of them are pointless in this case as this doesn't make the code any clearer. It's better simply …

>here is code for ur problem
Giving away homework answers is frowned upon here.

>#include<iostream.h>
We're well beyond the point where this will fail to compile on many modern compilers. I recommend you get with the times.

>int array[1000000]
This is a terrible waste of memory and it's also a broken design. You don't take into account that n could contain a value greater than 999999, which is a blatant security risk and certainly doesn't make for a robust program.

>if(a[i+1]>a)
Let's say that n is 1000000 and i is at the end of the loop with 999999. What happens when you index a?

>puts<<"the highest number in array is"<<high;
I'd say you should stick to C, but your program is broken in either language.

>Kindly tell me in brief that " impct of OO paradigm on software development (programming)"
The positive impact is that people are now (more or less) unwittingly using good design practices where those same practices were largely ignored by the masses before OO became all the rage. The negative impact is that OO has become a magic word that drives people crazy.

>im findin it hard to get topics to work on ?
We get about ten threads every few days asking for suggestions. Why don't you use one of those?

You formed the string incorrectly ItemFile.open((string)(ItemID+".asw").c_str());

The result of operator+ for std::string is always going to be a new std::string of the same type, so your cast is redundant. This is cleaner:

ItemFile.open((ItemID + ".asw").c_str());

Or offer the option to turn that feature off in one's control panel. I personally would use it because I always preview before posting anyway.

You're printing a pointer, of course the result will be an address. Try dereferencing brd:

cout << *brd;

>im still overlooking question 4
n1 is 10 because the loop is never executed, 10 is greater than 5, after all. n2 is 11 because the condition is checked after the loop executes once. This analysis falls right out of a direct description of how the while and do..while loops work.

>i worked this out to n1 = 0 as once and expression is tested if(n1>11)
>is false you move on to execute the next statment.
This is correct.

>Therefore n1>2 is true and n1=0
This is not correct. n1 is still 10 because the test fails and nothing happens. Here's the same code with reasonable formatting:

int n1 = 10;

if (n1 > 11)
{ 
  if (n1 > 2)
  {
    n1 = 0;
  }
  else
  { 
    n1 = 1;
  }
}

>and take it easy on the code, I am varry new to CPP. I am at the hello world level.
Since you've specified mutually exclusive requirements (relatively non-trivial tasks and code at the hello world level), I'll simply suggest you learn more C++ before trying to do this.

>1) im still lost on, i know the three types of loop but not
>the method to discover which one to use and when.
You use the loop best suited to the problem. For example, if you always execute the body of the loop at least once, a do..while loop may be better suited. If you're looking an exact number of times, a for loop may be better suited.

>2) the function returns a char, takes an int and a reference as float.
>int is unchanged and exits but the float is modified?
Looks good to me, though the float might not be modified. This is the case where a good const guideline makes reading declarations easier.

>3) Is it through public member functions that private data can be accessed.
>They can return and modify data outside of the class ?
That's one correct answer, yes. Basically the public and protected interface of the class can make private data accessible. The interface includes friends.

>4) When i follow through the code i see it as both n1 and n2 = 10.
Please see the do..while example for answer 1 to see why you're not correct.

Can you post main.cpp as well?

>This caused serious problems
This I don't agree with. Yes, OOP shines when it comes to organizing large projects, but if structured design caused serious problems, it's because the designer messed up. Your description seems to assume that anything non-OO is inherently flawed, which is not the case.

>Adding new features to systems was also quite a task, because you had to add the feature
>to every function and add a specialized case for that feature if it was specialized.
As opposed to inheriting a new class and implementing the new feature. Of course this is assuming that the hierarchy was properly generalized in the first place, otherwise you're stuck with adding the feature to every function and adding a specialized case for that feature if it's specialized. ;) Also keep in mind that a well designed system will allow for adding new features with minimal work, regardless of the methodology your design uses.

One reason OO has been hyped so much is because people insist on comparing the best case scenario using OO with the worst possible designs using other paradigms.

>they create and initialize everything under main function as one source code program.
How far into the book are you? Beginner books generally keep it simple at first and ease into full blown OO techniques. Also, don't forget that C++ is not an object oriented language, it's a multi-paradigm language and one of those paradigms is OO.

>So i was curious are there C++ standards or rules on
>the way to create object-oriented programs properly?
Ask ten different people how to write object oriented programs properly and you'll get ten different answers. So yes, there are standards and rules. Lots of them. Many of them contradict each other too.

>Deitel surely force C++ rules heavily throughout this book compare to Primer.
To be honest, I was never a fan of Deitel books. They're huge, expensive, cover unrelated topics, and every time I've flipped through one, the code has made use of unconventional idioms.

>Should I then just remove or modify the tests, too?
That makes sense. You should also modify the tests that rely on that class as well, which (depending on your level of coupling) could mean changes in other classes and other tests.

>So, at this point, pnA still contains the old address where there is now no data?
pnA still contains the old address, but you don't own that memory anymore. Which means it could already be in use by another process.

>So if we did a third delete, we would get an error
It doesn't matter how many deletes you do, if it's more than one without an intervening reassignment, it's too late. And you might not get an error even if you do twenty deletes, you could just silently corrupt the results of another process.

>Can we avoid this problem by adding a <pointer name> = NULL
>statement after every delete?
That's actually a common guideline, but I don't believe strongly in it in this case because if your problem is multiple deletion, you're just covering up the real problem. Your code is doing something wrong, fix that.

>int* pnBad;//bad pointer?
Yup.

>How would that happen?
If you allocate 10 bytes then copy 15 bytes to the pointer, you may overwrite private data used by the memory manager for handling dynamic memory.

>int* pnA = NULL;
>delete pnA;//okay? still a null pointer? a bad pointer?
Deleting a null pointer is always a no-op. It doesn't hurt anything.

>pnA = new int;
>*pnA = 5;
>delete pnA;//okay? still a null pointer? a bad pointer?
Fine here, but the only thing you can do with pnA at this point is reseat it to another address.

>delete pnA;//is it a bad pointer now?
Yes, now you've done some damage.

>So, what is the difference between NULL pointers and bad pointers
Null pointers have a predictable value while bad pointers do not.

>why do the delete statements fail with the bad pointers?
"Bad pointers" happen when you fail to initialize a pointer, manage to corrupt your memory, or try to free a pointer more than once. Step through your code and see if you can find where the change happens.

>For some case such as break multiple-level of loops, goto is inevitable.
I wouldn't say inevitable, but goto can be the cleanest solution if you have deep nesting and can't refactor it. The alternative is to use flags and check them at each level, which is a "pure" structured solution, but it's almost always ugly as sin.

>but I did't said anything about attacking .
You strongly implied it.

I wouldn't say that we've entered the realm of issuing infractions quite yet, but it's getting closer. kv79, I'd suggest you refrain from even implying that you intend to spam or engage in DoS attacks in the future.

>Now the idea is if b is equal to 5 then it breaks out of
>the if loop, the for loop c, the for loop b, the for loop a.
Nope. You can write as many breaks as you want, but only the first one will have any effect, and it'll break you out of the inner-most loop (the c loop).

>If not can someoone please correct me?
You have options here, but the best option is not to get into such a situation to begin with. If you need to break out of a nested loop, it's usually best (if you can manage it) to refactor the nested loops into a function and then use the return value to break:

for ( int a = 0; a < 10; a++ ) {
  if ( !some_function() )
    break;
}

...

bool some_function()
{
  for ( int b = 0; b < 10; b++ ) {
    for ( int c = 0; c < 10; c++ ) {
      if ( b == 5 )
        return false;
    }
  }

  return true;
}

>Sorry I forget the word 'serious'
Ah, so you think Mono is some kind of joke then. Well, that's your opinion, and as such doesn't count as an objective argument in favor of your claims.

>And if you haven't notice the indistinctive use of 'C#', 'Visual C#', 'C#.NET',
>'Visual C#.NET'. then I think that we haven't been posting in the same thread ;-).
All I've noticed is that the terms are used interchangeably in two situations:

1) It's obvious where and how C# is being used, so the compiler/IDE can be safely assumed and there's no need to be specific about the implementation. That doesn't mean C# and C#.NET are always the same thing. :icon_rolleyes:

2) The person talking (eg. you) is so terribly confused as to be unable to make a distinction.

#include <iostream>
#include <map>
#include <string>

std::string foo() { return "Foo"; }
std::string bar() { return "Bar"; }

int main()
{
  std::map<std::string, std::string (*)()> m;

  // Map the functions to the names
  m["foo"] = &foo;
  m["bar"] = &bar;

  // Display all of the mapped functions
  std::map<std::string, std::string (*)()>::const_iterator it = m.begin();
  std::map<std::string, std::string (*)()>::const_iterator end = m.end();

  while ( it != end ) {
    std::cout<< it->first <<"\t\""
      << (it->second)() <<"\"\n";
    ++it;
  }
}