Member Avatar for tintin.iitk 
class A {
A& a;
public:
A(): a(* new A()) {}
};

There is a huge flaw here and before I compiled this code I was hoping that it will fail to compile, But it didn't. At first I felt like I had a big flaw in C++ as it allowed data member pointers of the same kind in a class, but then I realized the flaw was in that it is a recursive function call, which will form an infinite loop. Apart from recursive functions, which other methods do you ppl know about C++?

Edited by mike_2000_17 because: Fixed formatting
  • 3 Contributors
  • 3 Replies
  • 257 Views
  • 12 Hours Discussion Span
  • Latest Post Latest Post by gusano79

Dani AI

Generated

Short note clarifying what happened and a few practical cautions.

Your example compiles because a reference (or a pointer) to the same class is legal: pointers/references have a known size, so the compiler can lay out the class. What you ran into is a runtime problem, not a compile-time one — each A constructed initializes its reference by allocating another A, which in turn does the same, producing unbounded recursive construction until the program crashes. As pointed out, C++ trusts the programmer; as observed, compilers cannot generally prove termination, so they won't (and cannot in general) reject this pattern.

Common related pitfalls to watch for:

  • Dangling references/pointers: binding to a local or to deleted storage.
  • Ownership mistakes and leaks from manual new/delete; prefer RAII.
  • Member initialization surprises: initialization happens in declaration order, not the order in the initializer list.
  • Object slicing when passing/assigning polymorphic types by value.
  • Missing virtual destructor in a polymorphic base.
  • Uninitialized data and other undefined-behavior traps.

Practical mitigations and a simple pattern

  • Prefer smart pointers (modern C++: std::unique_ptr, std::shared_ptr/std::weak_ptr) and factory functions to control construction.
  • Build cross-references in two phases: construct objects first, then set pointers/references between them to avoid recursive constructors. For example:
#include <memory>

struct Node { Node* partner = nullptr; };

auto a = std::make_unique<Node>();
auto b = std::make_unique<Node>();
a->partner = b.get();
b->partner = a.get();

Debugging tips: run under a debugger, enable AddressSanitizer/UBSan or similar tools, and add simple guard counters if you suspect unintended recursion. In short: the language lets you express the pattern you wrote; safe designs (RAII, two-phase init, smart pointers) avoid the runtime traps.

Recommended Answers

All 3 Replies

Member Avatar for jbennet

C is designed with the assumption that if the the programmer does something, however strange it seems, it is because he means to do it.

Member Avatar for tintin.iitk

That's a good way of looking at it.. but anyway I was more interested in knowing what other such necessary-to-avoid situations are.. like dynamic memory allocation is another such thing. Well, I'm a beginner as far as C++ programming is concerned(mostly used java) and was curious to know what all things I should be cautious about. Anyway, Java did solve the problem of leaked dynamic memory allocation through its internal junk management but C/C++ are not much safe (ok, smart pointers and std::auto_ptr are alternatives, but still not foolproof)about that. Returning to the original problem, even Java suffers from this risk of falling into infinite loops dues to recursive function calls.

Member Avatar for gusano79

Returning to the original problem, even Java suffers from this risk of falling into infinite loops dues to recursive function calls.

C is designed with the assumption that if the the programmer does something, however strange it seems, it is because he means to do it.

C is notorious for giving you "enough rope to shoot yourself in the foot"--but it doesn't matter what language you're talking about... if it allows you to define a recursive function, you can always define one that never terminates.

Allowing recursion without this possibility is sort of like inventing a language in which untruthful statements aren't grammatical--a warm, fuzzy thought, but such a thing simply doesn't exist.

Sometimes recursion loops are detectable, but no development environment I've ever worked with has even bothered to try.

The halting problem is at the heart of this issue... I recommend you study it if you haven't seen it already. This version is more entertaining.

commented: thats an interesting link +21
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.