Newbies don't learn C++

Discussion in 'C++' started by Paul, Jan 11, 2011.

  1. Paul

    Paul Guest

    I was programming Windows COM Objects 10 years ago , and I'm not interested
    in that anymore.Its old tech.
    It appears to me that "the C++ community" has become very confused, since I
    last visisted the world of C++.

    10 years ago C++ was usefull because of the rapid growth of microsoft
    windows, but thats old tech and its all been done. Who cares about MS
    windows as long as they can watch you-tube and blog with their mates.
    XBOX and IPOD is the current fashion, the latest thing being IPOD APPS. Java
    is much more portable across the constantly changing hardware fashions that
    is the world we live in today.


    WHy should anyone try to learn a programming language that is unneccessarily
    overly complicated by unclear confused and undefined standards. C++ seems
    caught up in a chiken-egg scenario with the C++ standard/s and they are
    still arguing about the same shit they were 10 years ago.
    Some people refuse to accept the term object as it is widely used in
    computer programming today.

    In C++ a member function belongs to an object, end of story, there is no
    argument about this its a FACT.
    I have been totally shunned by the 'C++ community' and dismissed as complete
    nonsense by *supposed* experts. But its not complete nonsense it's a dead
    sure fact.

    In 10 years time C++ will be useless knowledge, as fortran or basic is
    today. It seems like even the people who are writing the standards now think
    a member function belongs to a class. And it seems nowadays that the
    standards are defining the implementation of the language, and not a
    definiton of the language(as they should be).

    My second-hand book shop now has two C++ books for sale at 30p each, thanks
    to my donation. I will not be replacing them.

    If after 10 years the current standard is such confused bollocks then it's
    certainly not going to be any better in C++ 0x . There is a high probably it
    will introduce more confusion into the minds of these people who are doing
    nothing more than killing what used to be a very well defined and respected
    programming language.

    C++.............................Your fired!
    http://www.youtube.com/watch?v=xGrT...y&list=PL4AC9052EB37ADBBA&index=43&playnext=2

    Stuart also thought he was a professional and expert.
    Paul, Jan 11, 2011
    #1
    1. Advertising

  2. Paul

    Ian Collins Guest

    On 01/12/11 01:04 PM, Leigh Johnston wrote:

    [nonsense snipped]

    > I thought you had unsubscribed from this newsgroup?


    Please don't feed the troll!

    Fully quoting its nonsense is a great way to bypass message filters...

    --
    Ian Collins
    Ian Collins, Jan 12, 2011
    #2
    1. Advertising

  3. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 11/01/2011 23:37, Paul wrote:
    >> I was programming Windows COM Objects 10 years ago , and I'm not
    >> interested
    >> in that anymore.Its old tech.
    >> It appears to me that "the C++ community" has become very confused, since
    >> I
    >> last visisted the world of C++.
    >>
    >> 10 years ago C++ was usefull because of the rapid growth of microsoft
    >> windows, but thats old tech and its all been done. Who cares about MS
    >> windows as long as they can watch you-tube and blog with their mates.
    >> XBOX and IPOD is the current fashion, the latest thing being IPOD APPS.
    >> Java
    >> is much more portable across the constantly changing hardware fashions
    >> that
    >> is the world we live in today.
    >>
    >>
    >> WHy should anyone try to learn a programming language that is
    >> unneccessarily
    >> overly complicated by unclear confused and undefined standards. C++ seems
    >> caught up in a chiken-egg scenario with the C++ standard/s and they are
    >> still arguing about the same shit they were 10 years ago.
    >> Some people refuse to accept the term object as it is widely used in
    >> computer programming today.
    >>
    >> In C++ a member function belongs to an object, end of story, there is no
    >> argument about this its a FACT.
    >> I have been totally shunned by the 'C++ community' and dismissed as
    >> complete
    >> nonsense by *supposed* experts. But its not complete nonsense it's a dead
    >> sure fact.
    >>
    >> In 10 years time C++ will be useless knowledge, as fortran or basic is
    >> today. It seems like even the people who are writing the standards now
    >> think
    >> a member function belongs to a class. And it seems nowadays that the
    >> standards are defining the implementation of the language, and not a
    >> definiton of the language(as they should be).
    >>
    >> My second-hand book shop now has two C++ books for sale at 30p each,
    >> thanks
    >> to my donation. I will not be replacing them.
    >>
    >> If after 10 years the current standard is such confused bollocks then
    >> it's
    >> certainly not going to be any better in C++ 0x . There is a high
    >> probably it
    >> will introduce more confusion into the minds of these people who are
    >> doing
    >> nothing more than killing what used to be a very well defined and
    >> respected
    >> programming language.
    >>
    >> C++.............................Your fired!
    >> http://www.youtube.com/watch?v=xGrT...y&list=PL4AC9052EB37ADBBA&index=43&playnext=2
    >>
    >>
    >> Stuart also thought he was a professional and expert.
    >>

    >
    > I thought you had unsubscribed from this newsgroup?
    >
    > In C++ a member function is a part of a class not part of an object.


    When a member function is invoked for an object, the class is of no
    relevance. A class is only necessary to create an object, after an object
    has been created the class does not even need to exist. Only the function
    definiton is required.

    An object is bound to a member function dependant on the calling mechanism.
    Whether it be a pointer within the object or an pointer in a register, or
    whatever calling mechanism is used. The same cannot be said for a class.

    A member function cannot be invoked if there is no object present, therefore
    it follows that a member function cannot exist unless an object exists.The
    same cannot be said for a class.
    I know a non virtual member function can be invoked directly with a pointer
    but this is probably not legal as it break scope rules.

    The general concept of objects, in an OOP context, is that a member function
    is encapsualted within an object. And C++ is a language that supports OOP,
    therefore C++ supports this concept.

    All of the above are perfectly good arguments to suggest that a member
    function belongs to an object, unless you can prove otherwise.


    You have not given one single argument to suggest a member function belongs
    to a class. The only argument you have is to switch the context from runtime
    to a precompile time class. And even with this very weak argument it only
    proves the function is 'declared' in a class.
    The very fact that a function is declared in a class suggests a member
    function does belong to an object. As a class is the definition of an
    object(or an objects type if you want to get pedantic).

    Oh you also gave the argument that 'we' all think so therefore 'we' must be
    correct.

    What happens if you create a singleton object then overwrite its typdef?
    Where does this class of yours exist, other than some source file.?
    Paul, Jan 12, 2011
    #3
  4. Paul

    Paul Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 01/12/11 01:04 PM, Leigh Johnston wrote:
    >
    > [nonsense snipped]
    >
    >> I thought you had unsubscribed from this newsgroup?

    >
    > Please don't feed the troll!
    >
    > Fully quoting its nonsense is a great way to bypass message filters...
    >
    > --
    > Ian Collins
    >


    I would like to remind Ian that he was very recently proved wrong in
    learn.c-c++ .
    re: Ian Collins wrote..

    :)
    Paul, Jan 12, 2011
    #4
  5. On Jan 11, 5:05 pm, "Paul" <> wrote:
    > Oh you also gave the argument that 'we' all think so therefore 'we' must be
    > correct.


    Over matters of definition and terminology, yes.
    Joshua Maurice, Jan 12, 2011
    #5
  6. Paul

    Rui Maciel Guest

    Leigh Johnston wrote:

    > If you disagree with me try looking at the assembler generated during
    > compilation. I suspect you don't know how to program in assembler
    > because if you did you wouldn't have started any of these bullshit
    > threads of yours (assuming you are not a troll).


    I don't believe that by now there is any doubt that this Paul is a troll.
    All the personal attacks, the name calling and the insistence to reiterate
    nonsense no matter how many times people point out his misconceptions and
    mistakes are a clear indication that this character's purpose is to troll
    a hand full of newsgroups.


    Rui Maciel
    Rui Maciel, Jan 12, 2011
    #6
  7. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 12/01/2011 01:05, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>
    >> You have not given one single argument to suggest a member function
    >> belongs to a class. The only argument you have is to switch the context
    >> from runtime to a precompile time class. And even with this very weak
    >> argument it only proves the function is 'declared' in a class.
    >> The very fact that a function is declared in a class suggests a member
    >> function does belong to an object. As a class is the definition of an
    >> object(or an objects type if you want to get pedantic).

    >
    > Member functions only exist as separate entities during compilation where
    > they are part of classes.


    Leigh the very first line of your post makes no sense and that is not having
    a go at you.
    MF's only exists as seperatae entites to what?......or are you saying
    members and functions are the two entities to be seperated ?
    As it stands I need to guess at what you are trying to say, perhaps english
    is not your first language(seriously) so I will not be cheeky about it.
    No I read it 10 times and i simply cannot work out what that sentence above
    is suppose to mean, please rephrase it

    > After compilation/linking member functions live in the code segment
    > alongside non-member functions and like classes cease to exist as separate
    > entities.


    C++ is not restricted to the IBM PC program format, but I accept it if you
    choose to use this program format as an example to explain.
    Functions don't *live* in the code section, you are thinking of the set of
    instruction that are the "function definition". The function proper doesn't
    live until it's been invoked.
    But I also accept that this function definition can be, and usually is,
    referred to as simply 'the function'.

    I do not understand the last part of your above para re: "and like classes
    cease to exist as separate entities.".
    If something is seperate is must be seperate from something else, it can't
    just be defined to be a 'seperate entity' on its own.


    > How can something that no longer exists as a separate entity be part of
    > an object?


    What no longer exists and as a seperate entity and from what other entity
    has it been seperated?

    >
    > The compiler provided passing of an object's "this" pointer to what was a
    > member function during compilation is no different to the passing of any
    > other function argument modulo the possible use of a register rather than
    > the stack.


    What does the compiler have to do with the invokation of a member function?
    The compiler doesn't pass any pointers , this is all processed by the CPU.
    It's an instruction pointer, and CPU stack and registers blah blah, I don't
    even want to go there for any given implementation.

    >
    > If you disagree with me try looking at the assembler generated during
    > compilation. I suspect you don't know how to program in assembler because
    > if you did you wouldn't have started any of these bullshit threads of
    > yours (assuming you are not a troll).


    I don't claim to be any expert on x86 assembly , but you seem to think you
    are. Classes with inheretance in ASM is very advanced stuff and if you can
    understand exactly how that works on a modern IBM PC by simply reading the
    ASM code from a linker output then you possess a talent most human beings do
    not have.

    >
    > Of course one can talk about a theoretical C++ implementation (e.g. an
    > interpreter) which contradicts what I have said above but most of us live
    > in the real world using traditional C++ implementations.
    >

    But we're not talking aobut a theoretical implementation , we're talking
    about real implementations.
    On a typical windows system for example, when you create a C++ program the
    class is compiled/linked to a typedef in program code. The class is then
    discarded and no longer exists.
    You suggest you know assembly so surely you know how you create a class type
    in ASM. You simply typedef the construct in whatever segment you choose.
    >>
    >> Oh you also gave the argument that 'we' all think so therefore 'we' must
    >> be correct.

    >
    > "we" are correct yes; "you" are wrong.
    >

    You have given no reasonable argument to prove this. Additionally the onus
    is on you to provide evidence, as you are the one claiming me to be wrong.

    >> What happens if you create a singleton object then overwrite its typdef?
    >> Where does this class of yours exist, other than some source file.?

    >
    > I have no idea what you are trying to say here.
    >
    > /Leigh
    >

    Ok create a program with an object typedeffed at text seg offsett 0xFF.
    1)The program creates an object on the heap
    2) The program loads EAX with the address of the member function ( say code
    seg offset 0xFE)
    3) The program invokes the objects member function by calling JMP EAX
    4) The code that resides at code seg offset 0xFE( the functions
    instructions) executes the following MOV [CS reg]+0xFF, 00000000

    This is a very basic example of how an object can overwrite its own typdef,
    there is no connection to the class AT ALL at this point.
    This is an extreme example that would very rarely be done unless the memory
    availabe was very limited.
    It is intended to disprove your suggestion that a function is stored inside
    a *class* at pogram code level. A class is a compile time entity unless you
    are referring to class members(statics).


    You seem to be applying pre-compile time jargon in the context of code
    segments etc.

    Wouldn't be surprised if you try to say template parameters are defined in
    obj files next. :)
    Paul, Jan 12, 2011
    #7
  8. In comp.lang.c++ Paul <> wrote:
    > 10 years ago C++ was usefull because of the rapid growth of microsoft
    > windows, but thats old tech and its all been done. Who cares about MS
    > windows as long as they can watch you-tube and blog with their mates.
    > XBOX and IPOD is the current fashion, the latest thing being IPOD APPS. Java
    > is much more portable across the constantly changing hardware fashions that
    > is the world we live in today.


    You once again brilliantly demonstrate your complete ignorance.

    Neither the "XBOX" (by which I assume you mean the Xbox 360) nor the
    "IPOD" (by which I assume you mean the iPhone family of devices, including
    the iPhone, the iPod Touch and the iPad) are programmed in Java.

    iPhone apps are made in either Objective-C or Objective-C++ (which is
    a mix between Objective-C and C++).

    Xbox 360 games are written principally in whatever language the game
    houses want to use, but it's often C++ (because the major game engines
    are usually written in C++), and whatever scripting language the particular
    game engine supports. Users can write so-called "arcade games" in C#.
    Juha Nieminen, Jan 12, 2011
    #8
  9. Paul

    ptyxs Guest

    The content of this thread as well as the content of other threads by
    the same author Paul, shows clearly that this guy just opens pure
    trolls : please, don't feed the troll and let him discuss with
    himself.
    All that is a mere waste of time and energy.
    ptyxs, Jan 12, 2011
    #9
  10. Paul

    Paul Guest

    "Juha Nieminen" <> wrote in message
    news:4d2ddaa9$0$32156$...
    > In comp.lang.c++ Paul <> wrote:
    >> 10 years ago C++ was usefull because of the rapid growth of microsoft
    >> windows, but thats old tech and its all been done. Who cares about MS
    >> windows as long as they can watch you-tube and blog with their mates.
    >> XBOX and IPOD is the current fashion, the latest thing being IPOD APPS.
    >> Java
    >> is much more portable across the constantly changing hardware fashions
    >> that
    >> is the world we live in today.

    >
    > You once again brilliantly demonstrate your complete ignorance.


    You are the ignorant one.
    >
    > Neither the "XBOX" (by which I assume you mean the Xbox 360) nor the
    > "IPOD" (by which I assume you mean the iPhone family of devices, including
    > the iPhone, the iPod Touch and the iPad) are programmed in Java.


    I never said an xbox game or OS was programmed in java, and I nevers said
    what language any apple i-turds were programmed in either.
    >
    > iPhone apps are made in either Objective-C or Objective-C++ (which is
    > a mix between Objective-C and C++).
    >
    > Xbox 360 games are written principally in whatever language the game
    > houses want to use, but it's often C++ (because the major game engines
    > are usually written in C++), and whatever scripting language the
    > particular
    > game engine supports. Users can write so-called "arcade games" in C#.
    >

    I doubt you will be coding any XBOX titles in your lifetime.


    The only reference i made to Java was to suggest it is much more portable
    across ALL of the new devices that are the current fashion.
    i.e: mobile phones, since you obviously need an example to explain this.
    Paul, Jan 12, 2011
    #10
  11. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 12/01/2011 16:41, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 12/01/2011 01:05, Paul wrote:
    >>>>
    >>>> "Leigh Johnston" <> wrote in message
    >>>> news:...
    >>>>
    >>>> You have not given one single argument to suggest a member function
    >>>> belongs to a class. The only argument you have is to switch the context
    >>>> from runtime to a precompile time class. And even with this very weak
    >>>> argument it only proves the function is 'declared' in a class.
    >>>> The very fact that a function is declared in a class suggests a member
    >>>> function does belong to an object. As a class is the definition of an
    >>>> object(or an objects type if you want to get pedantic).
    >>>
    >>> Member functions only exist as separate entities during compilation
    >>> where they are part of classes.

    >>
    >> Leigh the very first line of your post makes no sense and that is not
    >> having a go at you.
    >> MF's only exists as seperatae entites to what?......or are you saying
    >> members and functions are the two entities to be seperated ?
    >> As it stands I need to guess at what you are trying to say, perhaps
    >> english is not your first language(seriously) so I will not be cheeky
    >> about it.

    >
    > English is my first language; I have doubts that it is yours due to your
    > inability to understand simple logic expressed with it.
    >
    >> No I read it 10 times and i simply cannot work out what that sentence
    >> above is suppose to mean, please rephrase it

    >
    > During compilation a member function is a separate entity even though it
    > is part of something else (a class); this is no different to saying that a
    > window is a separate entity even though it is part of a house. Perhaps I
    > should have used the word "distinct" instead of "separate".
    >

    How can it be seperate although part of something?
    And what to you mean during compilation, You cant make a definiton of its
    state in the middle of the compilation process , lets be clear do you mean
    before or after compilation?



    >>
    >>> After compilation/linking member functions live in the code segment
    >>> alongside non-member functions and like classes cease to exist as
    >>> separate entities.

    >>
    >> C++ is not restricted to the IBM PC program format, but I accept it if
    >> you choose to use this program format as an example to explain.

    >
    > I have made no reference to the IBM PC program format; "code (text)
    > segment" is a computer science term; not an IBM PC program format term.


    Does the computer in my car have this format of program?
    I disagree that this is a general computer program format. I think it is a
    specific program format you speak of. The only knowledge I have of this type
    of format is from dabbling in asm many years ago.

    >
    >> Functions don't *live* in the code section, you are thinking of the set
    >> of instruction that are the "function definition". The function proper
    >> doesn't live until it's been invoked.
    >> But I also accept that this function definition can be, and usually is,
    >> referred to as simply 'the function'.

    >
    > The terms "function" and "function invocation" are distinct; in other
    > words a "function invocation" is not a "function". Functions live in the
    > text segment.


    A function invocation begins execution of a function , that is the start of
    its lifespan. Don't state a function is not a function -invocation as if I
    have said it was.
    If any definiton of a function "living" it is not its storage in memory. It
    is time from its invocation till return.
    >
    >>
    >> I do not understand the last part of your above para re: "and like
    >> classes cease to exist as separate entities.".
    >> If something is seperate is must be seperate from something else, it
    >> can't just be defined to be a 'seperate entity' on its own.
    >>

    >
    > Member functions (and non-member functions) only exist as separate
    > entities during compilation; after compilation/linking they all live side
    > by side in the text segment.

    They all live side by side does not mean they exists as the same entity.
    Here you seem to imply that after compilation they all live side by side but
    somehow as the same entity.
    Please clarify what you are trying to say here.

    >The compiler/linker will emit the
    > start addresses of functions into calling code and vtables but a start
    > address is not enough to fully delineate functions within the text segment
    > definition of an executable.

    This looks a sure copy and paste paragraph Im not sure what you are trying
    to say here.
    >
    > You haven't even considered inlined functions which plainly contradicts
    > your claim that a function can be part of an object during invocation; if
    > the function is inlined then it only exists in the calling function
    > (assuming that the calling function is not also inlined).
    >

    Don't try to confuse things by introducing inline functions.
    >>
    >>> How can something that no longer exists as a separate entity be part
    >>> of an object?

    >>
    >> What no longer exists and as a seperate entity and from what other
    >> entity has it been seperated?

    >
    > Objects only exist at runtime; member functions only exist at compile
    > time; how can something that only exists at compile time but part of
    > something that only exists at runtime? Text segments.


    member functions only exist at compile time? What kind of nonsense is that
    to state?.
    >
    >>
    >>>
    >>> The compiler provided passing of an object's "this" pointer to what
    >>> was a member function during compilation is no different to the
    >>> passing of any other function argument modulo the possible use of a
    >>> register rather than the stack.

    >>
    >> What does the compiler have to do with the invokation of a member
    >> function?
    >> The compiler doesn't pass any pointers , this is all processed by the
    >> CPU. It's an instruction pointer, and CPU stack and registers blah blah,
    >> I don't even want to go there for any given implementation.

    >
    > I never said the compiler passes pointers; I said the "compiler *provided*
    > passing" which to anyone with half a brain would understand that I was
    > referring to the code the compiler emits which passes the argument.


    So you admit that the code that calls a member function passes a pointer to
    an object?

    >
    >>
    >>>
    >>> If you disagree with me try looking at the assembler generated during
    >>> compilation. I suspect you don't know how to program in assembler
    >>> because if you did you wouldn't have started any of these bullshit
    >>> threads of yours (assuming you are not a troll).

    >>
    >> I don't claim to be any expert on x86 assembly , but you seem to think
    >> you are. Classes with inheretance in ASM is very advanced stuff and if
    >> you can understand exactly how that works on a modern IBM PC by simply
    >> reading the ASM code from a linker output then you possess a talent most
    >> human beings do not have.

    >
    > Apart from yourself who mentioned x86 assembly or IBM PCs?
    >
    >>
    >>>
    >>> Of course one can talk about a theoretical C++ implementation (e.g. an
    >>> interpreter) which contradicts what I have said above but most of us
    >>> live in the real world using traditional C++ implementations.
    >>>

    >> But we're not talking aobut a theoretical implementation , we're talking
    >> about real implementations.
    >> On a typical windows system for example, when you create a C++ program
    >> the class is compiled/linked to a typedef in program code. The class is
    >> then discarded and no longer exists.
    >> You suggest you know assembly so surely you know how you create a class
    >> type in ASM. You simply typedef the construct in whatever segment you
    >> choose.

    >
    > What the f**k are you talking about?

    You are the one who raised theoretical implementations. I could say the same
    to you.

    >
    >> >>
    >>>> Oh you also gave the argument that 'we' all think so therefore 'we'
    >>>> must
    >>>> be correct.
    >>>
    >>> "we" are correct yes; "you" are wrong.
    >>>

    >> You have given no reasonable argument to prove this. Additionally the
    >> onus is on you to provide evidence, as you are the one claiming me to be
    >> wrong.

    >
    > Proof that "we" are correct and "you" are wrong? One only has to look at
    > all the replies in the threads started by you.
    >

    What like this reply? Is this your proof?
    >>
    >>>> What happens if you create a singleton object then overwrite its
    >>>> typdef?
    >>>> Where does this class of yours exist, other than some source file.?
    >>>
    >>> I have no idea what you are trying to say here.
    >>>
    >>> /Leigh
    >>>

    >> Ok create a program with an object typedeffed at text seg offsett 0xFF.
    >> 1)The program creates an object on the heap
    >> 2) The program loads EAX with the address of the member function ( say
    >> code seg offset 0xFE)
    >> 3) The program invokes the objects member function by calling JMP EAX
    >> 4) The code that resides at code seg offset 0xFE( the functions
    >> instructions) executes the following MOV [CS reg]+0xFF, 00000000
    >>
    >> This is a very basic example of how an object can overwrite its own
    >> typdef, there is no connection to the class AT ALL at this point.
    >> This is an extreme example that would very rarely be done unless the
    >> memory availabe was very limited.
    >> It is intended to disprove your suggestion that a function is stored
    >> inside a *class* at pogram code level. A class is a compile time entity
    >> unless you are referring to class members(statics).
    >>

    >
    > Utter guff; one word: "clueless".
    >

    Um ok I bolloxed that up with my segments as I say Im no expert .
    See if you can understand now:

    Ok create a program with an object typedeffed at data seg offsett 0xFF.
    1)The program creates an object on the heap of the tpye typedeffed at
    DS+0xFF
    2) The program loads EAX with the address of the member function ( say code
    seg offset 0xFE)
    3) The program invokes the objects member function by calling JMP EAX
    4) The code that resides at code seg offset 0xFE( the functions
    instructions) executes the following MOV [DS]+0xFF, 00000000

    As I am trying to explain a concept that you have not understood , perhaps I
    am not explaining clearly enough. And I attempt to explain it in a manner
    you seem to be knowledgable in. Please state what you do not understand or
    what you believe to be incorrect.

    >>
    >> You seem to be applying pre-compile time jargon in the context of code
    >> segments etc.
    >>
    >> Wouldn't be surprised if you try to say template parameters are defined
    >> in obj files next. :)

    >
    > Perhaps it is time for you to "unsubscribe" again.
    >
    > /Leigh
    Paul, Jan 12, 2011
    #11
  12. On Jan 11, 7:06 pm, Ian Collins <> wrote:
    > On 01/12/11 01:04 PM, Leigh Johnston wrote:
    >
    > [nonsense snipped]
    >
    > > I thought you had unsubscribed from this newsgroup?

    >
    > Please don't feed the troll!
    >
    > Fully quoting its nonsense is a great way to bypass message filters...


    Indeed. I keep hoping that as Paul says:

    On Jan 11, 6:37 pm, "Paul" <> wrote:
    > I have been totally shunned by the 'C++ community' and dismissed as complete
    > nonsense by *supposed* experts. But its not complete nonsense it's a  dead
    > sure fact.


    Leigh, Joshua, Juha, and others will soon join the 'C++ community'
    and 'totally shun' paul. Ie I hope they will start ignoring him soon.

    KHD
    Keith H Duggar, Jan 12, 2011
    #12
  13. Paul

    Balog Pal Guest

    "Keith H Duggar" <>
    >Leigh, Joshua, Juha, and others will soon join the 'C++ community'
    >and 'totally shun' paul. Ie I hope they will start ignoring him soon.


    Just plonked that trioa few minutes ago. Troll feeders are no better than
    pimary trolls, the nonsense does not show an end, but at least can be
    reached through extended killfiles on the client end.
    Balog Pal, Jan 12, 2011
    #13
  14. Paul

    Paul Guest

    "Keith H Duggar" <> wrote in message
    news:...
    On Jan 11, 7:06 pm, Ian Collins <> wrote:
    > On 01/12/11 01:04 PM, Leigh Johnston wrote:
    >
    > [nonsense snipped]
    >
    > > I thought you had unsubscribed from this newsgroup?

    >
    > Please don't feed the troll!
    >
    > Fully quoting its nonsense is a great way to bypass message filters...


    Indeed. I keep hoping that as Paul says:

    On Jan 11, 6:37 pm, "Paul" <> wrote:
    > I have been totally shunned by the 'C++ community' and dismissed as
    > complete
    > nonsense by *supposed* experts. But its not complete nonsense it's a dead
    > sure fact.


    Leigh, Joshua, Juha, and others will soon join the 'C++ community'
    and 'totally shun' paul. Ie I hope they will start ignoring him soon.

    KHD

    3 words for this moron:

    BIG GAY FOLLOWING
    Paul, Jan 12, 2011
    #14
  15. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 12/01/2011 18:47, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 12/01/2011 16:41, Paul wrote:
    >>>>
    >>>> "Leigh Johnston" <> wrote in message
    >>>> news:...
    >>>>> On 12/01/2011 01:05, Paul wrote:
    >>>>>>
    >>>>>> "Leigh Johnston" <> wrote in message
    >>>>>> news:...
    >>>>>>
    >>>>>> You have not given one single argument to suggest a member function
    >>>>>> belongs to a class. The only argument you have is to switch the
    >>>>>> context
    >>>>>> from runtime to a precompile time class. And even with this very weak
    >>>>>> argument it only proves the function is 'declared' in a class.
    >>>>>> The very fact that a function is declared in a class suggests a
    >>>>>> member
    >>>>>> function does belong to an object. As a class is the definition of an
    >>>>>> object(or an objects type if you want to get pedantic).
    >>>>>
    >>>>> Member functions only exist as separate entities during compilation
    >>>>> where they are part of classes.
    >>>>
    >>>> Leigh the very first line of your post makes no sense and that is not
    >>>> having a go at you.
    >>>> MF's only exists as seperatae entites to what?......or are you saying
    >>>> members and functions are the two entities to be seperated ?
    >>>> As it stands I need to guess at what you are trying to say, perhaps
    >>>> english is not your first language(seriously) so I will not be cheeky
    >>>> about it.
    >>>
    >>> English is my first language; I have doubts that it is yours due to
    >>> your inability to understand simple logic expressed with it.
    >>>
    >>>> No I read it 10 times and i simply cannot work out what that sentence
    >>>> above is suppose to mean, please rephrase it
    >>>
    >>> During compilation a member function is a separate entity even though
    >>> it is part of something else (a class); this is no different to saying
    >>> that a window is a separate entity even though it is part of a house.
    >>> Perhaps I should have used the word "distinct" instead of "separate".
    >>>

    >> How can it be seperate although part of something?
    >> And what to you mean during compilation, You cant make a definiton of
    >> its state in the middle of the compilation process , lets be clear do
    >> you mean before or after compilation?

    >
    > A member function is treated by the compiler as a separate entity during
    > compilation even though it is part of a class; why do you find this so
    > hard to grasp? The fact that a compiler can inline a member function
    > should be sufficient evidence to illustrate what I am saying is fact. The
    > compiler converts a non-inlined member function into machine code the
    > beginning of which is the function's unique start address which is used
    > during linking. After linking all that exists is a binary executable
    > which contains among other things a text segment which contains all the
    > machine code for all the function definitions; member functions cease to
    > exist as entities which means they can not be part of objects in the C++
    > sense.
    >

    So you now refuse to accept that a member function even exists after compile
    time?

    You are in complete disagreement with Bjare Stroustrup re:
    "An object of a C++ class is represented by a contiguous region of memory. A
    pointer to an object of a class points to the first byte of that region of
    memory. The compiler turns a call of a member function into an ''ordinary''
    function call with an ''extra'' argument; that ''extra'' argument is a
    pointer to the object for which the member function is called. "

    Ole Bjarne here seems to think different to you. So who is right and who is
    wrong?

    >>>>> After compilation/linking member functions live in the code segment
    >>>>> alongside non-member functions and like classes cease to exist as
    >>>>> separate entities.
    >>>>
    >>>> C++ is not restricted to the IBM PC program format, but I accept it if
    >>>> you choose to use this program format as an example to explain.
    >>>
    >>> I have made no reference to the IBM PC program format; "code (text)
    >>> segment" is a computer science term; not an IBM PC program format term.

    >>
    >> Does the computer in my car have this format of program?
    >> I disagree that this is a general computer program format. I think it is
    >> a specific program format you speak of. The only knowledge I have of
    >> this type of format is from dabbling in asm many years ago.

    >
    > I said that text segment is a computer science term not specific to any
    > particular platform program format.
    >
    >>
    >>>
    >>>> Functions don't *live* in the code section, you are thinking of the set
    >>>> of instruction that are the "function definition". The function proper
    >>>> doesn't live until it's been invoked.
    >>>> But I also accept that this function definition can be, and usually is,
    >>>> referred to as simply 'the function'.
    >>>
    >>> The terms "function" and "function invocation" are distinct; in other
    >>> words a "function invocation" is not a "function". Functions live in
    >>> the text segment.

    >>
    >> A function invocation begins execution of a function , that is the start
    >> of its lifespan. Don't state a function is not a function -invocation as
    >> if I have said it was.
    >> If any definiton of a function "living" it is not its storage in memory.
    >> It is time from its invocation till return.

    >
    > No; a function lives in the text segment; the text segment exists in
    > memory (or paged into memory on demand) whilst the program exist in memory
    > for some definition of "memory".


    Its not necessarily the case that a function exists in a text segment.
    The point here is that you are saying it 'lives' there and that isn't really
    a proper technical term in computer programming so I will not argue , it can
    'live' wherever you want it to 'live', its your term.
    >
    >>>
    >>>>
    >>>> I do not understand the last part of your above para re: "and like
    >>>> classes cease to exist as separate entities.".
    >>>> If something is seperate is must be seperate from something else, it
    >>>> can't just be defined to be a 'seperate entity' on its own.
    >>>>
    >>>
    >>> Member functions (and non-member functions) only exist as separate
    >>> entities during compilation; after compilation/linking they all live
    >>> side by side in the text segment.

    >> They all live side by side does not mean they exists as the same entity.
    >> Here you seem to imply that after compilation they all live side by side
    >> but somehow as the same entity.

    >
    > They all live side by side in the text segment. There is no difference
    > between a member function and a non-member function as far as the text
    > segment is concerned


    There is a difference in the calling mechanism. As Bjarne clearly states.
    >
    >> Please clarify what you are trying to say here.
    >>
    >> >The compiler/linker will emit the
    >>> start addresses of functions into calling code and vtables but a start
    >>> address is not enough to fully delineate functions within the text
    >>> segment definition of an executable.

    >> This looks a sure copy and paste paragraph Im not sure what you are
    >> trying to say here.
    >>>
    >>> You haven't even considered inlined functions which plainly
    >>> contradicts your claim that a function can be part of an object during
    >>> invocation; if the function is inlined then it only exists in the
    >>> calling function (assuming that the calling function is not also
    >>> inlined).
    >>>

    >> Don't try to confuse things by introducing inline functions.

    >
    > Confuse things? More like I have given you a shining example of why what
    > you are claiming is bullshit.


    What you say is in complete disagreement with Bjarne Stroustrup , is this
    not enough to suggest it's probably *your* claims that are complete
    bullshit?
    >
    >>>>
    >>>>> How can something that no longer exists as a separate entity be part
    >>>>> of an object?
    >>>>
    >>>> What no longer exists and as a seperate entity and from what other
    >>>> entity has it been seperated?
    >>>
    >>> Objects only exist at runtime; member functions only exist at compile
    >>> time; how can something that only exists at compile time but part of
    >>> something that only exists at runtime? Text segments.

    >>
    >> member functions only exist at compile time? What kind of nonsense is
    >> that to state?.

    >
    > Yes; member functions only exist at compile time. After compiling/linking
    > all that remains of them is machine code in the text segment.
    >

    See above quote from Bjarne Stroustrup.
    If you need anyomore I have hundreds of quotes lined up waiting to prove you
    are wrong about this.

    >>>
    >>>>
    >>>>>
    >>>>> The compiler provided passing of an object's "this" pointer to what
    >>>>> was a member function during compilation is no different to the
    >>>>> passing of any other function argument modulo the possible use of a
    >>>>> register rather than the stack.
    >>>>
    >>>> What does the compiler have to do with the invokation of a member
    >>>> function?
    >>>> The compiler doesn't pass any pointers , this is all processed by the
    >>>> CPU. It's an instruction pointer, and CPU stack and registers blah
    >>>> blah,
    >>>> I don't even want to go there for any given implementation.
    >>>
    >>> I never said the compiler passes pointers; I said the "compiler
    >>> *provided* passing" which to anyone with half a brain would understand
    >>> that I was referring to the code the compiler emits which passes the
    >>> argument.

    >>
    >> So you admit that the code that calls a member function passes a pointer
    >> to an object?

    >
    > The compiler emits code that allows an object's "this" pointer to be used
    > by the machine code representing what used to be a member function. Again
    > this is all just machine code in the text segment. Nothing is "passed to
    > an object" as an object is just a region of storage in C++; how can you
    > pass something to a region of storage? You can't as that makes no sense.
    >

    Please dont confuse the term..passing a pointer-to-an-object with passing a
    pointer into an object.
    An object is not a function remember, you cannot pass arguments to a region
    of storage. Your misinterpretation does not make sense.

    Anyway it is not neccessary for you to confirm this point as Bjarne
    Stroustrup has confirmed it above.
    >>
    >>>
    >>>>
    >>>>>
    >>>>> If you disagree with me try looking at the assembler generated during
    >>>>> compilation. I suspect you don't know how to program in assembler
    >>>>> because if you did you wouldn't have started any of these bullshit
    >>>>> threads of yours (assuming you are not a troll).
    >>>>
    >>>> I don't claim to be any expert on x86 assembly , but you seem to think
    >>>> you are. Classes with inheretance in ASM is very advanced stuff and if
    >>>> you can understand exactly how that works on a modern IBM PC by simply
    >>>> reading the ASM code from a linker output then you possess a talent
    >>>> most
    >>>> human beings do not have.
    >>>
    >>> Apart from yourself who mentioned x86 assembly or IBM PCs?
    >>>
    >>>>
    >>>>>
    >>>>> Of course one can talk about a theoretical C++ implementation (e.g. an
    >>>>> interpreter) which contradicts what I have said above but most of us
    >>>>> live in the real world using traditional C++ implementations.
    >>>>>
    >>>> But we're not talking aobut a theoretical implementation , we're
    >>>> talking
    >>>> about real implementations.
    >>>> On a typical windows system for example, when you create a C++ program
    >>>> the class is compiled/linked to a typedef in program code. The class is
    >>>> then discarded and no longer exists.
    >>>> You suggest you know assembly so surely you know how you create a class
    >>>> type in ASM. You simply typedef the construct in whatever segment you
    >>>> choose.
    >>>
    >>> What the f**k are you talking about?

    >> You are the one who raised theoretical implementations. I could say the
    >> same to you.
    >>
    >>>
    >>>> >>
    >>>>>> Oh you also gave the argument that 'we' all think so therefore 'we'
    >>>>>> must
    >>>>>> be correct.
    >>>>>
    >>>>> "we" are correct yes; "you" are wrong.
    >>>>>
    >>>> You have given no reasonable argument to prove this. Additionally the
    >>>> onus is on you to provide evidence, as you are the one claiming me to
    >>>> be
    >>>> wrong.
    >>>
    >>> Proof that "we" are correct and "you" are wrong? One only has to look
    >>> at all the replies in the threads started by you.
    >>>

    >> What like this reply? Is this your proof?
    >>>>
    >>>>>> What happens if you create a singleton object then overwrite its
    >>>>>> typdef?
    >>>>>> Where does this class of yours exist, other than some source file.?
    >>>>>
    >>>>> I have no idea what you are trying to say here.
    >>>>>
    >>>>> /Leigh
    >>>>>
    >>>> Ok create a program with an object typedeffed at text seg offsett 0xFF.
    >>>> 1)The program creates an object on the heap
    >>>> 2) The program loads EAX with the address of the member function ( say
    >>>> code seg offset 0xFE)
    >>>> 3) The program invokes the objects member function by calling JMP EAX
    >>>> 4) The code that resides at code seg offset 0xFE( the functions
    >>>> instructions) executes the following MOV [CS reg]+0xFF, 00000000
    >>>>
    >>>> This is a very basic example of how an object can overwrite its own
    >>>> typdef, there is no connection to the class AT ALL at this point.
    >>>> This is an extreme example that would very rarely be done unless the
    >>>> memory availabe was very limited.
    >>>> It is intended to disprove your suggestion that a function is stored
    >>>> inside a *class* at pogram code level. A class is a compile time entity
    >>>> unless you are referring to class members(statics).
    >>>>
    >>>
    >>> Utter guff; one word: "clueless".
    >>>

    >> Um ok I bolloxed that up with my segments as I say Im no expert .
    >> See if you can understand now:
    >>
    >> Ok create a program with an object typedeffed at data seg offsett 0xFF.
    >> 1)The program creates an object on the heap of the tpye typedeffed at
    >> DS+0xFF
    >> 2) The program loads EAX with the address of the member function ( say
    >> code seg offset 0xFE)
    >> 3) The program invokes the objects member function by calling JMP EAX
    >> 4) The code that resides at code seg offset 0xFE( the functions
    >> instructions) executes the following MOV [DS]+0xFF, 00000000
    >>
    >> As I am trying to explain a concept that you have not understood ,
    >> perhaps I am not explaining clearly enough. And I attempt to explain it
    >> in a manner you seem to be knowledgable in. Please state what you do not
    >> understand or what you believe to be incorrect.

    >
    > Again this is just clueless guff; how is anybody supposed to *understand*
    > clueless guff.
    >

    This is very basic asm psuedo code.
    What part of it don't you understand exactly?

    In C++
    Create a program and typedef a class:
    typedef struct{unsigned x; unsigned y;}myType;
    1) myType x = new(myType);
    2) overwrite();
    3)//incorporated in 2
    4)//function executes code

    void overwrite(){do some shit that overwrites the typedef in the data seg;}



    object x is still there, but the typedef is erased. No more object s of
    myType can be made.
    Pretty simple, what don't you understand about this?
    Paul, Jan 12, 2011
    #15
  16. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:D...
    > On 12/01/2011 20:50, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 12/01/2011 18:47, Paul wrote:
    >>>>
    >>>> "Leigh Johnston" <> wrote in message
    >>>> news:...
    >>>>> On 12/01/2011 16:41, Paul wrote:
    >>>>>>
    >>>>>> "Leigh Johnston" <> wrote in message
    >>>>>> news:...
    >>>>>>> On 12/01/2011 01:05, Paul wrote:
    >>>>>>>>
    >>>>>>>> "Leigh Johnston" <> wrote in message
    >>>>>>>> news:...
    >>>>>>>>
    >>>>>>>> You have not given one single argument to suggest a member function
    >>>>>>>> belongs to a class. The only argument you have is to switch the
    >>>>>>>> context
    >>>>>>>> from runtime to a precompile time class. And even with this very
    >>>>>>>> weak
    >>>>>>>> argument it only proves the function is 'declared' in a class.
    >>>>>>>> The very fact that a function is declared in a class suggests a
    >>>>>>>> member
    >>>>>>>> function does belong to an object. As a class is the definition
    >>>>>>>> of an
    >>>>>>>> object(or an objects type if you want to get pedantic).
    >>>>>>>
    >>>>>>> Member functions only exist as separate entities during compilation
    >>>>>>> where they are part of classes.
    >>>>>>
    >>>>>> Leigh the very first line of your post makes no sense and that is not
    >>>>>> having a go at you.
    >>>>>> MF's only exists as seperatae entites to what?......or are you saying
    >>>>>> members and functions are the two entities to be seperated ?
    >>>>>> As it stands I need to guess at what you are trying to say, perhaps
    >>>>>> english is not your first language(seriously) so I will not be cheeky
    >>>>>> about it.
    >>>>>
    >>>>> English is my first language; I have doubts that it is yours due to
    >>>>> your inability to understand simple logic expressed with it.
    >>>>>
    >>>>>> No I read it 10 times and i simply cannot work out what that sentence
    >>>>>> above is suppose to mean, please rephrase it
    >>>>>
    >>>>> During compilation a member function is a separate entity even though
    >>>>> it is part of something else (a class); this is no different to saying
    >>>>> that a window is a separate entity even though it is part of a house.
    >>>>> Perhaps I should have used the word "distinct" instead of "separate".
    >>>>>
    >>>> How can it be seperate although part of something?
    >>>> And what to you mean during compilation, You cant make a definiton of
    >>>> its state in the middle of the compilation process , lets be clear do
    >>>> you mean before or after compilation?
    >>>
    >>> A member function is treated by the compiler as a separate entity
    >>> during compilation even though it is part of a class; why do you find
    >>> this so hard to grasp? The fact that a compiler can inline a member
    >>> function should be sufficient evidence to illustrate what I am saying
    >>> is fact. The compiler converts a non-inlined member function into
    >>> machine code the beginning of which is the function's unique start
    >>> address which is used during linking. After linking all that exists is
    >>> a binary executable which contains among other things a text segment
    >>> which contains all the machine code for all the function definitions;
    >>> member functions cease to exist as entities which means they can not
    >>> be part of objects in the C++ sense.
    >>>

    >> So you now refuse to accept that a member function even exists after
    >> compile time?
    >>
    >> You are in complete disagreement with Bjare Stroustrup re:
    >> "An object of a C++ class is represented by a contiguous region of
    >> memory. A pointer to an object of a class points to the first byte of
    >> that region of memory. The compiler turns a call of a member function
    >> into an ''ordinary'' function call with an ''extra'' argument; that
    >> ''extra'' argument is a pointer to the object for which the member
    >> function is called. "

    >
    > Your appeal to authority is wrong on two counts:
    >
    > 1) Appealing to authority is usually invalid
    > 2) Your actual appeal strengthens my position not yours.
    >


    I'm not APPEALING to anyone , I am posting a quote from Bjarne Stroustrup ,
    the man who invented C++, and what he says is evidence to support my
    argument. And it's also proof that what you are saying is complete nonsnese.

    You seem to have collapsed and I feel sorry for you now. Please don't get me
    wrong I am not trying to put you down I am simply sticking up for technical
    correctness. it was after all you who first claimed I was wrong.

    You obviously seem to be right into your standards and all that and I
    respect you for that and for trying to be correct. But you have to sometimes
    accept you are wrong.
    Paul, Jan 12, 2011
    #16
  17. Paul

    Paul Guest


    >>>> So you now refuse to accept that a member function even exists after
    >>>> compile time?
    >>>>
    >>>> You are in complete disagreement with Bjare Stroustrup re:
    >>>> "An object of a C++ class is represented by a contiguous region of
    >>>> memory. A pointer to an object of a class points to the first byte of
    >>>> that region of memory. The compiler turns a call of a member function
    >>>> into an ''ordinary'' function call with an ''extra'' argument; that
    >>>> ''extra'' argument is a pointer to the object for which the member
    >>>> function is called. "
    >>>
    >>> Your appeal to authority is wrong on two counts:
    >>>
    >>> 1) Appealing to authority is usually invalid
    >>> 2) Your actual appeal strengthens my position not yours.
    >>>

    >>
    >> I'm not APPEALING to anyone , I am posting a quote from Bjarne
    >> Stroustrup , the man who invented C++, and what he says is evidence to
    >> support my argument. And it's also proof that what you are saying is
    >> complete nonsnese.
    >>
    >> You seem to have collapsed and I feel sorry for you now. Please don't
    >> get me wrong I am not trying to put you down I am simply sticking up for
    >> technical correctness. it was after all you who first claimed I was
    >> wrong.
    >>
    >> You obviously seem to be right into your standards and all that and I
    >> respect you for that and for trying to be correct. But you have to
    >> sometimes accept you are wrong.
    >>

    >
    > Accepting that you are wrong is something *you* are unable to do; that
    > much is obvious.
    >

    If you allow people to bully you into being wrong then you are weak.
    If you have no brain of your own and simply go with the flow then you are
    weak.
    I'd rather be strong and correct, than weak and wrong.
    <shrug>
    Paul, Jan 12, 2011
    #17
  18. Paul

    Paul Guest


    >>>> So you now refuse to accept that a member function even exists after
    >>>> compile time?
    >>>>
    >>>> You are in complete disagreement with Bjare Stroustrup re:
    >>>> "An object of a C++ class is represented by a contiguous region of
    >>>> memory. A pointer to an object of a class points to the first byte of
    >>>> that region of memory. The compiler turns a call of a member function
    >>>> into an ''ordinary'' function call with an ''extra'' argument; that
    >>>> ''extra'' argument is a pointer to the object for which the member
    >>>> function is called. "
    >>>
    >>> Your appeal to authority is wrong on two counts:
    >>>
    >>> 1) Appealing to authority is usually invalid
    >>> 2) Your actual appeal strengthens my position not yours.
    >>>

    >>
    >> I'm not APPEALING to anyone , I am posting a quote from Bjarne
    >> Stroustrup , the man who invented C++, and what he says is evidence to
    >> support my argument. And it's also proof that what you are saying is
    >> complete nonsnese.
    >>
    >> You seem to have collapsed and I feel sorry for you now. Please don't
    >> get me wrong I am not trying to put you down I am simply sticking up for
    >> technical correctness. it was after all you who first claimed I was
    >> wrong.
    >>
    >> You obviously seem to be right into your standards and all that and I
    >> respect you for that and for trying to be correct. But you have to
    >> sometimes accept you are wrong.
    >>

    >
    > Accepting that you are wrong is something *you* are unable to do; that
    > much is obvious.
    >

    If you allow people to bully you into being wrong then you are weak.
    If you have no brain of your own and simply go with the flow then you are
    weak.
    I'd rather be strong and correct, than weak and wrong.
    <shrug>
    Paul, Jan 12, 2011
    #18
  19. On Jan 12, 9:42 am, "Paul" <> wrote:
    > The only reference i made to Java was to suggest it is much more portable
    > across ALL of the new devices that are the current fashion.
    >  i.e: mobile phones, since you obviously need an example to explain this.


    Depends on your technical definition of portable. While there might be
    less porting work when taking java from implementation A to
    implementation B, I'm pretty sure that C is supported on much more
    hardware than Java.
    Joshua Maurice, Jan 12, 2011
    #19
  20. Leigh Johnston <> writes:
    [...]
    > Accepting that you are wrong is something *you* are unable to do; that
    > much is obvious.


    The rest of us figured that out days ago.

    If you can't resist the tempation to respond, at least don't re-quote
    everything he writes.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jan 12, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Porky Pig Jr
    Replies:
    3
    Views:
    1,015
    Fuzzyman
    May 12, 2004
  2. ZOLTAN
    Replies:
    60
    Views:
    1,250
    Thomas G. Marshall
    Oct 18, 2006
  3. Chris Uppal
    Replies:
    0
    Views:
    291
    Chris Uppal
    Jul 28, 2006
  4. CoreyWhite
    Replies:
    1
    Views:
    639
    JohnQ
    Mar 31, 2007
  5. Alf P. Steinbach

    How we recognize newbies as newbies

    Alf P. Steinbach, Aug 13, 2007, in forum: C++
    Replies:
    31
    Views:
    1,049
    Diego Martins
    Aug 21, 2007
Loading...

Share This Page