Cracking DES with C++ is faster than Java?

Discussion in 'C++' started by Julie, Apr 25, 2004.

  1. First off, you are trying to redefine the subsetting issue.
    Something that exists in both languages but has different
    meaning also demonstrates the lack of subsetting.
    Secondly, sizeof'a'>1 "exists" in nearly all conforming
    implementations of C but not in C++. Or maybe you would
    prefer extern void f();f(42); which "exists" in C but not
    in C++. There are numerous other examples.
    I already explained some ways in which that happens.
    I didn't say "always", but *on average* that is true for
    the speed of comparable applications implemented in the
    various languages by skilled programmers. There are
    other aspects to programming besides execution speed,
    however, and anybody who thinks that just one of those
    languages should be used for every application is naive.
     
    Douglas A. Gwyn, Apr 28, 2004
    #41
    1. Advertisements

  2. It is *possible* to write code that will compile
    correctly and have the same semantics in both
    languages. Presumably you have learned how to
    code within this common subset of the two.
    However, there is a *lot* of existing C code
    that will not compile using a C++ compiler, and
    more dangerously there is some existing C code
    that will compile using C++ but will produce
    different results when executed. People who
    are completely unaware of the issues are of
    course most likely to fall into that trap.
     
    Douglas A. Gwyn, Apr 28, 2004
    #42
    1. Advertisements

  3. Actually optimizer technology really is substantially better
    these days. Any such comparison needs to keep in mind that
    Fortran has properties that allow tighter optimization than
    is feasible for C on many platforms; for example, C pointer
    parameters can alias whereas Fortran array parameters cannot
    (acording to the language spec), which permits vectorization
    that is not safe for C code. (We have addressed that in C99
    by introducing "restrict" qualification.)
    Also, hardware has changed in many ways. RISC architectures
    are usually harder to program optimally without machine
    assistance in allocating registers, for example.
     
    Douglas A. Gwyn, Apr 28, 2004
    #43
  4. In C, it's not necessary to cast a (void*) into (any_data*). In C, you can
    name a variable 'new', 'class', or any other C++-reserved word.
     
    Erwann ABALEA, Apr 28, 2004
    #44
  5. Just like XML is a superset of HTML, and SGML is a superset of XML, but in
    fact, XML is a subset of SGML, since SGML was 'invented' before XML.

    Here, the C++ language has been 'invented' after C.
     
    Erwann ABALEA, Apr 28, 2004
    #45
  6. Julie

    Mark Wooding Guest

    I can't speak for Doug, but presumably by reading the language standards.
    The language standards. You might want to read them before being
    further ill-informed pronouncements.
    A number of old C features which C++ dropped, such as K&R-style function
    declarations. Also some more significant differences:

    * C allows implicit cast from `void *' to other pointer types (e.g.,
    result of `malloc'); C++ requires an explicit cast for some stupid
    reason. This is probably the most significant difference, and it's
    why most of my C programs aren't C++.

    * C's character constants have type `int'; C++'s have type `char'.

    * C's structure tags have a separate namespace; C++ puts them in the
    main identifier namespace.

    * C++ reserves a number of new keywords, most heinously `import', but
    also `template', `class', etc.; these are normal identifiers in C.
    Also, `wchar_t' is a built-in type in C++, but not in C.

    -- [mdw]
     
    Mark Wooding, Apr 28, 2004
    #46
  7. [snip]
    Computers can access fixed locations in memory
    faster that relative locations. Recursion requires
    local variables to be stored on the stack, i.e. to
    be accessed using relative locations. Data structures
    on the heap are even more complicated to access.

    Dynamic storage is very bad, you can see the computer
    stop for several thousand million clock cycles whilst the
    garbage collector tries to find some more memory.

    Andrew Swallow
     
    Andrew Swallow, Apr 28, 2004
    #47
  8. Julie

    Ernst Lippe Guest

    I assume that with "fixed location" you mean addresses that are known at link
    time, when the executable is produced.

    I don't think that your statement is true in general, it all depends on the
    circumstances. One of the disadvantages of using absolute memory addresses is
    that the size of instruction must always be larger than the number of bits in
    the address space. Many CPU's have built-in support for addressing
    small-sized offsets to a stack-pointer and in general the size of these
    instructions is smaller than the size of the instructions that use absolute
    addresses. When the instruction is longer, either it will take more time to
    fetch it from memory, or it will decrease the effective number of instructions
    that can be held in the instruction cache.

    Even on CPU architectures where both types of instructions have the same size,
    there may not be any difference in execution speed. For most modern CPU's
    memory access is the main bottle-neck. Simple arithmetic operations to
    registers, such as adding a small offset, are so fast relative to the time it
    takes to fetch/store the contents of some address in memory, that there is no
    difference. Also, virtually all modern computers have memory caches, and the
    performance depends heavily on whether the contents are available in the
    cache. But for the memory cache there is no difference between a fixed address
    and an address that has been computed dynamically, the only thing that is
    important if that address has been used recently.

    The overhead of allowing recursion (if any) is minimal on modern
    CPU's. Anyhow, all modern programming languages (even Fortran) allow it, so
    apparently language designers believe that the benefits are sufficiently
    important.
    In most cases this statement is false, in most computers data structures on
    the heap are simply identified by their address which is not more complicated
    than using absolute addresses or locations on the stack. I have the feeling
    that you believe that heaps only occur in languages, that have a relocating
    garbage collector (see below), but it is standard usage to refer to the memory
    area from which dynamically sized memory is allocated as "the heap". For
    example, the malloc in C uses a heap.

    What do you mean by dynamic storage? The standard meaning of the term is
    storage where the actual memory size of an object is not known at compile
    time. This is pretty common in most computer languages, and in most cases this
    is not at all a performance problem.

    You are probably referring to relocating garbage collectors that can change
    the actual memory addresses where objects are located. Traditionally, these
    used to have the problems that you describe, but there have been important
    improvements (generation scavenging, multi-threading) and most of these
    problems have disappeared.

    Anyhow, I don't think that your argument that fixed addresses are
    faster is very relevant. Virtually all computer programs are written
    with procedures that can accept varying arguments (that was already
    the case for these old Fortran programs). So there are hardly any instances
    where computers actually use fixed addresses, because most code
    relies on variables that have been passed as arguments instead of
    global variables.

    Ernst Lippe
     
    Ernst Lippe, Apr 28, 2004
    #48
  9. Julie

    Julie Guest

    Julie, Apr 28, 2004
    #49
  10. Julie

    Julie Guest

    I'm asking the PP to post substantive references to HIS COMMENTS. It isn't my
    responsibility to justify others comments, it is theirs. My responsibility is
    to justify my comments.

    Do you have any references to the standards that explicitly state that C++ is
    *NOT* essentially a superset of C?
    It seems that most of the respondents have soon forgotten what we are talking
    about. Doug said that there isn't a sub/super set relationship between C and
    C++, and I questioned him on that.

    Take this for example:
    *EXACTLY* -- C++ contains C, and then extends it -- hence, a SUPERSET. Your
    examples only justify that C++ is a superset of C.

    Excepting the few syntactic differences here and there, mostly for type safety,
    C++ is definitely a superset of C, and that is by design.

    Read section B2 of the Appendix of TC++PL:

    http://www.filibeto.org/sun/lib/development/c++_iiird/appB.pdf
     
    Julie, Apr 28, 2004
    #50
  11. Julie

    Julie Guest

    Julie, Apr 28, 2004
    #51
  12. But what has 'precedence' to do with correctness of one
    statement with respect to a logically 'equivalent' one?
    Should one also consider that only one of the following
    sentences is 'allowed' in view of 'precedence'?

    Elisabeth is the daughter of Mary.

    Mary is the mother of Elisabeth.

    Note that there is well one 'precedence' relation between
    these two persons.

    M. K. Shen
     
    Mok-Kong Shen, Apr 28, 2004
    #52
  13. Julie

    Tom St Denis Guest

    Um I just read that PDF. The PDF seems to agree that there are valid
    [albeit of questionable usage] C statements that are not valid in C++
    [and vice versa].

    I don't see how that contradicts what Douglas said.

    Tom
     
    Tom St Denis, Apr 28, 2004
    #53
  14. Do not forget the time it required to load the pointers.
    Fortran IV did not support recursion. It was even designed
    so that its compilers did not need to use recursion. One of
    the reason that only simple calculations were permitted in
    array subscripts.
    As a user of programs written in C I have noticed. It does
    not matter if the runtime garbage collector is in the program
    or the operating system, both its time delays and probability
    of failure are still there. A construct that is definitely not
    suitable for use in realtime or safety critical programs.
    Only yesterday did I saw my PC crash because of a stack
    overflow.
    One of the speed optimisations Fortran programmers made
    was to pass global variables around in the common blocks
    rather that as parameters.
    Andrew Swallow
     
    Andrew Swallow, Apr 28, 2004
    #54
  15. Julie

    Julie Guest

    Step by step, then:

    Douglas A. Gwyn wrote:

    (Since the languages [C and C++] do not have a
    subset/superset relationship, in general compiling a
    C source program with a C++ compiler is not safe.)

    TC++PL, Bjarne Stroustrup, Appendix
    B.2 C/C++ Compatibility
    With minor exceptions, C++ is a superset of C. Most
    differences stem from C++'s greater emphasis on type
    checking. Well-written C programs tend to be C++
    programs as well. All differences between C++ and C
    can be diagnosed by a compiler.

    Even simpler yet:

    Doug: "do not have a subset/superset relationship"

    Bjarne: "C++ is a superset of C"

    Doug: "in general compiling a C source program with a
    C++ compiler is not safe"

    Bjarne: "Well-written C programs tend to be C++
    programs as well"

    Simplest:

    They contradict.
     
    Julie, Apr 28, 2004
    #55
  16. Julie

    Tom St Denis Guest

    They don't.
    "With Minor exceptions pi is equal to 3".
    From a cryptographers point of view.
    No. You're misreporting Bjarne.

    Tom
     
    Tom St Denis, Apr 28, 2004
    #56
  17. All of Appendix B of ISO/IEC 14882:2003 (the standard) is dedicated to
    differences between C and C++. It cites many differences. Here's just one among
    many:

    /* valid in C, but NOT in C++ */
    int i;
    int i; // second definition violates C++'s ODR, but is OK in C

    The appendix cites many more, but it only takes one to cause C++ to not be a
    superset of C.
    It's not enough for C++ to be compatible with MOST C code to name it a superset.
    It has to be compatible with ALL valid C code. "All women" is not a superset of
    "three women and one man".
    WRONG! Read Appendix B and Chapter 1 of the standard. It's clearly stated that
    C++ is BASED ON C, not that it contains C as a subset.
    You're either being argumentative for the sake of arguing or you don't understand
    the meaning of "superset". There is no "mostly" in set theory. Either it's a
    superset, or it's not. There is a very large intersection between C and C++, but
    there is NO containment relationship. NONE. NADA. You don't get to have a
    "personal opinion" or your own "perspective" on mathematical axioms.

    Claudio Puviani
     
    Claudio Puviani, Apr 28, 2004
    #57
  18. Julie

    Jerry Coffin Guest

    [ ... ]
    IMO, basing any decision about DES on this paper is a mistake.

    First of all, the conclusions that it draws are mostly based on an 80%
    confidence level. In most cases, a 95% confidence level is the
    minimum that's considered meaningful, and in more demanding
    situations, a 99% confidence level may be required. To look at things
    from the opposite direction, there's roughly a 20% chance that any
    conclusion you see in this paper is based on pure chance.

    Second, some of the data was collected in ways that render it highly
    suspect to start with (a fact acknoledged, but IMO insufficiently
    emphasized in the paper).

    Finally, and probably most importantly, this examines solutions to
    only one problem -- and a problem with little relationship to DES at
    that. As such, even if the data had been collected more carefully,
    and enough more data had been collected to support conclusions, those
    conclusions would still mean little or nothing about the task at hand
    anyway.

    Now, don't get me wrong: I'm not, at any point, saying that its
    conclusions are necessarily wrong -- only that we have insufficient
    evidence to believe they're right, and even if they were it would be
    inapplicable to the question at hand.
     
    Jerry Coffin, Apr 28, 2004
    #58
  19. Julie

    Julie Guest

    True in absolute terms. I was talking in figurative (looser) terms.
    Fine, I shall read it (later).
    I understand set theory just fine. I wasn't talking in explicit mathematical
    terms, but approximate figurative terms. Further, I was essentially
    regurgitating Bjarne in TC++PL, Appendix, B2:

    "With minor exceptions, C++ is a superset of C."

    Honestly, I'm not interested in arguing about the minutiae of the various
    comments relating to what is and what isn't a superset/subset. Conceptually,
    C++ is a superset of C, explicitly (in pure mathematic set theory terms), it is
    not. If you or anyone disagrees, feel free to take it up w/ Bjarne.
     
    Julie, Apr 28, 2004
    #59
  20. Julie

    Julie Guest

    How can I be 'misreporting' Bjarne when I provided the *explicit* context in
    which he made the statements?

    If you feel further disagreement on the topic, feel free to discuss it w/
    Bjarne, as I have no interest in battling over the explicit minutiae of pure
    set theory. FWIW, my comments are based on the *conceptual* idea of
    superset/subset.
     
    Julie, Apr 28, 2004
    #60
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.