Binary search tree methods
Namespace
#include &lt;bits/stdc++.h&gt;
using namespace std;

The first line supposedly inserts all includes your code needs but haven't specifically included. The second line saves you a lot of typing by not having to insert std:: in front of all relevant methods and types.
Please don't use those!
Read Why is “using namespace std;” considered bad practice? on Stack Overflow for the full read, but the short version is it's a major maintainability risk and allows function conflicts to arise.
The first line combined with the second line makes it even worse, since now you are no longer in control about how your code executes. You should tell the compiler what to do, not the other way around.
You current style not only hurts maintainability, it also hurts your understanding of how the language works. Practices like these lead to programmers not understanding how to make the best of namespaces.
Style
left=right=NULL;`

This hurts readability and maintainability. It's clear you're setting something to NULL, but not why. You're probably resetting something. However, you're resetting both left and right at the same time, on the same line. If you need to reset multiple things at the same time, you usually implement a function doing so.
if(val &lt; temp-&gt;val) {parent = temp; temp= temp-&gt;left;}`

All your if statements look like that. The more accepted (and more readable) style of bracketing in C++ goes like this:
if(val &lt; temp-&gt;val)
{
    parent = temp;
    temp= temp-&gt;left;
}

Don't be afraid of using newlines.
int main(){
    bTree a;
}

You declare a bTree named a. You're not doing anything with it, just creating something. If you would do something with it, you'd notice a isn't a good name for a bTree. a.insert(val) doesn't tell me anything, except you're inserting something into a. In a bigger project, you'll encounter more variable names and all those names should be descriptive.
Finally:
The size of code in C++ is usually irrelevant. Space is cheap nowadays and saving a couple of bytes in the source won't bring you anywhere with compiled languages. Only the size of the resulting binary may be relevant, especially if you're working on embedded systems.