DEV Community: Aswani Kumar

Using .h and .cpp files in an online C++ compiler (and why most of them fail)

Aswani Kumar — Mon, 09 Nov 2026 08:53:06 +0000

Most online C++ compilers give you one editor, and one editor means one file. That's fine until your course splits a class into Student.h and Student.cpp. Then the second line of main.cpp stops the build:

code.cc:2:10: fatal error: Student.h: No such file or directory
    2 | #include "Student.h"
      |          ^~~~~~~~~~~
compilation terminated.

Here's why that happens, three ways around it, and the linker errors you'll meet on the way.

Why the include fails

#include "Student.h" tells the compiler to read Student.h from the folder of the file that includes it. A one-file online compiler saves your code on its own in an empty folder, so there is no Student.h to read.

Pasting in just the header doesn't fix it either. The header only declares the class; the member functions are defined in Student.cpp. If that file isn't compiled too, the linker stops instead:

/usr/bin/ld: /tmp/ccdg4WQe.o: in function `main':
code.cc:(.text.startup+0x33): undefined reference to `Student::Student(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)'
...
collect2: error: ld returned 1 exit status

The program needs both files, compiled and linked together.

The example

A small class, split the usual way:

// Student.h
#ifndef STUDENT_H
#define STUDENT_H

#include <string>

class Student {
public:
    Student(const std::string& name, int score);
    std::string name() const;
    bool passed() const;

private:
    std::string name_;
    int score_;
};

#endif

// Student.cpp
#include "Student.h"

Student::Student(const std::string& name, int score) : name_(name), score_(score) {}

std::string Student::name() const { return name_; }

bool Student::passed() const { return score_ >= 50; }

// main.cpp
#include <iostream>
#include "Student.h"

int main() {
    Student ada("Ada", 91);
    Student tim("Tim", 42);
    std::cout << ada.name() << (ada.passed() ? " passed" : " failed") << "\n";
    std::cout << tim.name() << (tim.passed() ? " passed" : " failed") << "\n";
}

On your own computer you build both .cpp files into one program:

g++ main.cpp Student.cpp -o main
./main

Ada passed
Tim failed

Option 1: paste the class above `main`

This works in any online compiler. Put the class declaration and its member functions in the same file, above main, and drop the #include "Student.h" line. It's fine for a quick check, but you lose the very structure your course is trying to teach, and it doesn't scale past one or two classes.

Option 2: use an online IDE with projects

If you want to click Run in a browser with a tab per file, use a tool that has projects. OnlineGDB lets you add files to a project (and has a debugger), Playcode handles .cpp and .h files in folders, and Replit builds every C++ file in a project into one program. Check each one's current plans and limits yourself.

Option 3: send the files to a compiler API

If the code comes from a script, a course platform or an autograder rather than a person typing in a browser, send the files with the program. OnlineCompiler.io's API (which I build) takes main.cpp as the program and every other file in a files list:

curl -X POST https://api.onlinecompiler.io/api/run-code-sync/ \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "compiler": "g++-15",
    "code": "#include <iostream>\n#include \"Student.h\"\n\nint main() {\n    Student ada(\"Ada\", 91);\n    Student tim(\"Tim\", 42);\n    std::cout << ada.name() << (ada.passed() ? \" passed\" : \" failed\") << \"\\n\";\n    std::cout << tim.name() << (tim.passed() ? \" passed\" : \" failed\") << \"\\n\";\n}\n",
    "files": [
      {"name": "Student.h", "content": "#ifndef STUDENT_H\n#define STUDENT_H\n\n#include <string>\n\nclass Student {\npublic:\n    Student(const std::string& name, int score);\n    std::string name() const;\n    bool passed() const;\n\nprivate:\n    std::string name_;\n    int score_;\n};\n\n#endif\n"},
      {"name": "Student.cpp", "content": "#include \"Student.h\"\n\nStudent::Student(const std::string& name, int score) : name_(name), score_(score) {}\n\nstd::string Student::name() const { return name_; }\n\nbool Student::passed() const { return score_ >= 50; }\n"}
    ]
  }'

The response's output is Ada passed\nTim failed\n and exit_code is 0. What happens on the server:

Every .cpp, .cc and .cxx file you send is compiled and linked with the program, here as g++ -O2 -Wall code.cc Student.cpp -o code.out.
Headers aren't compiled on their own; they're read where a file includes them.
The name must match your #include exactly, capital letters included: student.h is not Student.h.
Folders work (lib/Student.h), up to 20 files and 1 MB besides the program.
g++-15 is C++17; use g++-15-cpp20 for C++20. Add "input" when the program reads from cin.

The same thing from Python, reading the files from the folder you run it in:

from pathlib import Path
import requests

files = ["Student.h", "Student.cpp"]
response = requests.post(
    "https://api.onlinecompiler.io/api/run-code-sync/",
    headers={"Authorization": "YOUR_API_KEY"},
    json={
        "compiler": "g++-15",
        "code": Path("main.cpp").read_text(),
        "files": [{"name": name, "content": Path(name).read_text()} for name in files],
    },
    timeout=60,
)
result = response.json()
print(result["output"], end="")
print(result["error"], end="")
print("exit code:", result["exit_code"])

What if your course says `#include "Student.cpp"`?

Some courses have main.cpp include the .cpp file instead of the header, so the class arrives with its code in one step. Change the include and send the same two files: it prints the same output. The rule that makes both styles work is that a file included with #include "..." is compiled only through that include, never again on its own, so each function is compiled exactly once.

On your own computer the two styles need different commands. With the header, build both files (g++ main.cpp Student.cpp). With #include "Student.cpp", build only g++ main.cpp. Build both in that style and the class is compiled twice, which the linker refuses (shortened):

$ g++ main.cpp Student.cpp -o main
/usr/bin/ld: /tmp/cciho97q.o: in function `Student::Student(...)':
Student.cpp:(.text+0x0): multiple definition of `Student::Student(...)'; /tmp/ccteijRb.o:main.cpp:(.text+0xb0): first defined here
collect2: error: ld returned 1 exit status

An IDE that builds every .cpp file in a project does exactly that, so there, include the header. Headers are how larger C++ programs are built anyway.

The errors, in one table

Error	What it means	Fix
`fatal error: Student.h: No such file or directory`	The header isn't next to the program, or its name differs (case counts)	Add it under the exact name you include
undefined reference to `Student::Student(...)'	The header was found, but nothing defines the functions it declares	Compile and link `Student.cpp` too
`redefinition of 'class Student'`	One file read the header twice, and it has no include guard	Wrap it in `#ifndef STUDENT_H` / `#define STUDENT_H` / `#endif`, or use `#pragma once`
multiple definition of `passMark()'	A function body lives in a header that two `.cpp` files include	Move the body to the `.cpp`, or mark it `inline`
multiple definition of `main'	A second file (often a `.cpp` with a leftover test `main`) defines `main`	Keep one `main`

Grading multi-file C++ automatically

If you teach, the same files list works with the API's run-tests endpoint: send the student's Student.cpp, your own main.cpp that exercises it, and a list of inputs with expected outputs, and you get a verdict for each test and a score. That's how you can auto-grade a class assignment without setting up a judge server. The free plan has 100,000 runs a month, no credit card.

The full guide, with every output and the C, Java and folder variations, is here: C++ header files in an online compiler.

Disclosure: I build OnlineCompiler.io. Options 1 and 2 above work without it.

I Built a Multi-Tenant CRM with PostgreSQL Row-Level Security — Here's What I Learned

Aswani Kumar — Sun, 01 Mar 2026 09:07:11 +0000

Every CRM I've ever used has made me angry.

Not the "this button is in the wrong place" kind of angry. The "I'm paying $65/user/month and I can't even export my own data" kind of angry.

I'm Ashwin Kumar. I ran MicroPyramid, a software consulting firm with 100+ engineers and clients across the US, Australia, Israel, and the UK. Over a decade, we built custom CRMs, ERPs, and SaaS platforms for dozens of companies. And every single time, the conversation started the same way:

"We're using Salesforce/HubSpot/Zoho, but it's too expensive, too locked-in, and we can't customize it."

So we'd build them something custom. Again and again. After the fifth time building essentially the same multi-tenant CRM from scratch, I thought — why not build it once, properly, and open-source it?

That became Django-CRM (now BottleCRM). It's got 2,100+ stars on GitHub, it's MIT-licensed, and it runs in production. But the most interesting technical decision — the one I want to talk about — is how we handle multi-tenancy.

The Multi-Tenancy Problem

If you're building any SaaS, you need multi-tenancy. Multiple organizations sharing the same application, each seeing only their own data. There are three common approaches:

Separate databases per tenant — bulletproof isolation, operational nightmare
Schema-per-tenant (the django-tenants approach) — each tenant gets a PostgreSQL schema, shared database
Shared schema with Row-Level Security — one schema, one set of tables, PostgreSQL enforces isolation at the row level

When I started, django-tenants was the obvious choice. It's mature, well-documented, and the Django community loves it. I almost went with it.

Then I did the math.

Why Schema-Per-Tenant Broke Down

With django-tenants, every migrate runs against every schema. Got 500 tenants? That's 500 migration runs. Add a column? Hope you've got time.

Here's what we actually hit in production with schema-per-tenant on a previous project:

Migration time scaled linearly with tenant count. 200 tenants meant 45+ minute deploys.
Connection pooling was painful. PgBouncer doesn't love SET search_path on every request. We burned hours debugging stale connections.
Cross-tenant queries were nearly impossible. Want to build an admin dashboard showing all tenants? You're writing raw SQL with UNION ALL across schemas.
Django's ORM assumed one schema. We were constantly fighting the framework instead of using it.

RLS flips the model entirely.

Row-Level Security: Let PostgreSQL Do the Hard Work

With RLS, every table has a policy that says: "You can only see rows where org_id matches the current session variable." PostgreSQL enforces this at the engine level — not in your application code, not in your ORM, not in a middleware hack. At the database engine level.

Here's what an actual RLS policy looks like for our leads table:

-- Enable RLS on the table
ALTER TABLE leads_lead ENABLE ROW LEVEL SECURITY;

-- Force RLS even for table owners
ALTER TABLE leads_lead FORCE ROW LEVEL SECURITY;

-- The policy: users can only see rows belonging to their org
CREATE POLICY tenant_isolation_policy ON leads_lead
    USING (org_id = current_setting('app.current_org')::INTEGER);

-- Separate policy for INSERT (ensure users can only create rows for their org)
CREATE POLICY tenant_insert_policy ON leads_lead
    FOR INSERT
    WITH CHECK (org_id = current_setting('app.current_org')::INTEGER);

That's it. Once this policy exists, PostgreSQL will never return a row from another tenant, even if your application code has a bug. Even if someone writes a raw SQL query. Even if a junior developer forgets to add .filter(org=request.org). The database says no.

This is defense in depth that actually works.

How Django Talks to RLS

The magic glue is a middleware that sets the PostgreSQL session variable on every request. Here's the actual pattern:

# middleware/tenant.py

class TenantMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Extract org from the authenticated user's JWT
        org_id = getattr(request, 'org', None)

        if org_id:
            from django.db import connection
            with connection.cursor() as cursor:
                cursor.execute(
                    "SET app.current_org = %s", [str(org_id)]
                )

        response = self.get_response(request)

        # Reset to prevent connection pool leakage
        if org_id:
            with connection.cursor() as cursor:
                cursor.execute("RESET app.current_org")

        return response

The beauty: your views and serializers don't need to know about tenancy at all. The ORM just works. Querysets automatically return only the current tenant's data because PostgreSQL filters at the engine level.

# views.py — no tenant filtering needed!

class LeadViewSet(viewsets.ModelViewSet):
    serializer_class = LeadSerializer
    permission_classes = [IsAuthenticated]

    def get_queryset(self):
        # This returns ALL leads — but RLS ensures
        # only the current org's leads come back
        return Lead.objects.all().order_by('-created_at')

    def perform_create(self, serializer):
        # org_id is set automatically, and RLS validates
        # that it matches the session variable
        serializer.save(
            org_id=self.request.org.id,
            created_by=self.request.user
        )

No .filter(org=request.org) scattered across 200 views. No chance of forgetting it in one place and leaking data. The database is the single source of truth for tenant isolation.

The Full Stack: Why Django + SvelteKit

A lot of people ask why not Next.js or React. Short answer: I've shipped production apps with all of them, and for a CRM, SvelteKit wins on three fronts:

Bundle size. CRMs have dozens of forms, tables, and modals. Svelte compiles away the framework — our JS bundle is ~40% smaller than the React equivalent we prototyped.
Reactivity without boilerplate. Svelte 5's runes ($state, $derived) are cleaner than useState + useEffect + useMemo. For a data-heavy app, this matters.
SvelteKit's routing is file-based and simple. No fighting with App Router vs Pages Router. No server components confusion. It just works.

The full stack:

Layer	Tech	Why
Backend	Django 5 + DRF	Battle-tested, ORM is excellent for complex data models
Frontend	SvelteKit 2 + Svelte 5 + TailwindCSS 4	Fast, small, great DX
Database	PostgreSQL 14+	RLS, JSONB, full-text search — all in one
Auth	JWT (access + refresh tokens)	Stateless, works with mobile apps
Background jobs	Celery + Redis	Email, notifications, data imports
Deployment	Docker Compose	One command: `docker compose up`

Performance: RLS vs Schema-Per-Tenant

Let's talk numbers. These are from our benchmarks with realistic data (10K-100K rows per tenant):

Query performance: Virtually identical. PostgreSQL's query planner treats RLS policies like additional WHERE clauses. With a proper index on org_id, there's negligible overhead — we measured <1ms difference on 95th percentile queries.

Migration speed: This is where RLS dominates. One schema means one migration run, regardless of tenant count. 500 tenants? Same 3-second migration as 1 tenant.

Connection pooling: Standard PgBouncer works perfectly. No search_path switching, no stale state. Each request just sets a session variable and resets it.

Disk usage: Shared indexes across all tenants. Schema-per-tenant duplicates every index for every tenant. At 500 tenants with 15 tables, that's 7,500 indexes vs. 15.

The tradeoff? Schema-per-tenant gives you harder isolation boundaries. If a tenant needs a custom column or a different schema, schema-per-tenant handles that natively. With RLS, every tenant shares the same schema. For a CRM where every tenant uses the same data model, this isn't a limitation — it's a feature.

Why MIT and Not AGPL

This was a deliberate choice. AGPL would have "protected" the project by forcing anyone who modifies it to open-source their changes. But in practice:

AGPL scares enterprises. Legal teams see AGPL and close the tab. We wanted adoption.
MIT builds trust. You can fork it, modify it, sell it, host it — we don't care. Use it however you want.
Community over control. The projects with the healthiest ecosystems — React, Vue, Django itself — are permissively licensed. We wanted contributors, not compliance officers.

Our bet: if the product is good enough, people contribute because they want to, not because a license forces them. So far, that bet is paying off.

Lessons From Running This With Real Clients

After years of running multi-tenant CRM deployments, here's what I wish someone had told me:

1. Always reset the session variable. If you set app.current_org and don't reset it, connection pools will serve the wrong tenant's data to the next request. We learned this the hard way. Always reset in a finally block or middleware teardown.

2. Superuser bypasses RLS by default. PostgreSQL RLS policies don't apply to superusers or table owners unless you use FORCE ROW LEVEL SECURITY. We missed this initially and wondered why our admin panel showed all data. Add FORCE to every table.

3. Test with multiple tenants from day one. Write a test that creates two orgs, inserts data for both, and asserts that each org can only see its own. Run it in CI. Never skip it.

4. Audit logging needs the org context too. Your audit trail should capture which org performed which action. Don't rely on application-level logging alone — use PostgreSQL triggers that read current_setting('app.current_org').

5. Data exports are trivially simple. Need to export all of tenant 42's data? SET app.current_org = '42'; COPY leads_lead TO '/tmp/leads.csv' CSV HEADER; — RLS does the filtering for you.

Getting Started

BottleCRM runs with a single command:

# docker-compose.yml (simplified)
services:
  backend:
    build: ./backend
    environment:
      - DATABASE_URL=postgres://crm:crm@db:5432/bottlecrm
      - REDIS_URL=redis://redis:6379
      - SECRET_KEY=${SECRET_KEY}
    depends_on:
      - db
      - redis

  frontend:
    build: ./frontend
    environment:
      - PUBLIC_API_URL=http://backend:8000
    ports:
      - "3000:3000"

  db:
    image: postgres:16
    environment:
      - POSTGRES_DB=bottlecrm
      - POSTGRES_USER=crm
      - POSTGRES_PASSWORD=crm
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

  celery:
    build: ./backend
    command: celery -A crm worker -l info
    depends_on:
      - db
      - redis

volumes:
  pgdata:

git clone https://github.com/MicroPyramid/Django-CRM.git
cd Django-CRM
docker compose up

That's it. Open localhost:3000, create an account, and you've got a production-grade CRM running locally.

Ship It

Building BottleCRM taught me that the best multi-tenancy strategy isn't the most clever one — it's the one that lets PostgreSQL do what it's good at. RLS pushes tenant isolation into the database engine where it belongs. Your application code stays clean, your deployments stay fast, and your data stays safe.

If you're building a multi-tenant Django app, seriously consider RLS before reaching for django-tenants. It's less magical, more explicit, and PostgreSQL has been battle-testing this feature since version 9.5.

⭐ Star Django-CRM on GitHub — 2,100+ stars and growing

🚀 Try the live demo at bottlecrm.io — free, no credit card

🤝 Contribute — we're looking for help with the mobile app (Flutter), analytics dashboard, and documentation. Check the issues tab.

Built with 🐍 Django + ⚡ SvelteKit + 🐘 PostgreSQL. MIT Licensed. Free forever.