Change Insertion Operator Symbol by Macro?

[ruzip]

Hi, I would like something like:


cout "Hello " + mystr + ".\n";

instead of the standard << symbol..

cout << "Hello " << mystr << ".\n";


Is this possible using macros?

[mbozzi]

Is this possible using macros?

#include <iostream>
#include <string>

#define cout std::cout <<

int main()
{
  std::string mystr = "ruzip";    
  cout "Hello, " + mystr + ".\n";
}

It's possible in the particular case above, but it's also a waste of time and a bad idea.

[ruzip]

Thanks, it works.

I would also like to use non strings like int or float directly, without converting it to string.

[Duthomhas]

You need a nice preprocessor (like m4 maybe?) and a whole lot of effort.
Don’t waste your time.

Use the language as designed.


Why not?

Because cout "Hello, " + name + ".\n"; is not C++.
If you wish to use C++, then stick to C++ syntax.


Some keyboards do not have < and > on them.

If this is your rationale, you need to figure out how to handle that problem instead of dinking with C++ syntax. There is a useful thread on Stack Exchange that may help you:

https://superuser.com/questions/1020203/typing-and-characters-with-ansi-keyboard-lacking-the-key-these-characters-ar


Good luck!

[JLBorges]

> Is this possible using macros?
> I would also like to use non strings like int or float directly, without converting it to string.

"As a rule of thumb, if you can find a clean and manageable way to do something without the preprocessor, then you should do it that way." - The Boost Preprocessing library
https://www.boost.org/doc/libs/1_79_0/libs/preprocessor/doc/index.html

#include <iostream>
#include <string>
#include <concepts>
#include <iomanip>

namespace fancy_plus // best not to pollute the global unnamed namespace
{
    template < typename T > // output_streamable type - an object of type T can be sent to std::ostream
    concept output_streamable = requires( std::ostream& stm, const T& v )
    { { stm << v } -> std::same_as<std::ostream&> ; } ;

    template < output_streamable T > // T is an output_streamable type
    std::ostream& operator + ( std::ostream& stm, const T& v ) { return stm << v ; }
}

int main()
{
    using fancy_plus::operator+ ; // bring fancy_plus::operator+ into scope

    const std::string str = "abcd" ;

    std::cout + "string " + std::quoted(str) + "  int " + std::setfill('*') + std::setw(7) + 1234
              + "  double " + std::fixed + std::setprecision(8) + 56.78 + '\n' ;
}

http://coliru.stacked-crooked.com/a/a66c2d981a062772

[ruzip]

Thanks guys. It's for a lexer type macro that I'm doing.

I have settled with mbozzi's macro and the conversion to string just to keep it simple.

Thank you for the boost alternative solution JLBorges, I'll keep that in mind. :)

Problem solved. (for now)

[seeplus]

Note that for any non-POD type you can overload the allowable operators (eg, +, <<, = etc etc) to perform any code required.

[JLBorges]

Overload for any enumeration or class type (including POD class types).

The term POD is no longer used by the standard, and its type traits (std::is_pod etc.) are deprecated.
https://eel.is/c++draft/depr.meta.types

[George P]

M'ok, the C++ standard eschews the POD usage....

Half-joking, mostly serious....

So how are we hoo-mans supposed to refer to that entity? The "Formerly Known As POD" Entity?

More than a few terms are used incorrectly even by experienced people who should know otherwise, such as the C++ stdlib being called the STL.

[seeplus]

What abut DPOD (depreciated Plain Old Data)...

[George P]

Heh. ™

[JLBorges]

So how are we hoo-mans supposed to refer to that entity?

Ideally, one should not refer to that entity in C++20.

This type requirement is deprecated in the C++ standard. All of its uses have been replaced by the more refined type requirements, such as TrivialType.
https://en.cppreference.com/w/cpp/named_req/PODType

If we need to refer to the Cpp17UnaryTypeTrait std::is_pod<T> in C++20,

A POD class is a class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD class (or array thereof). A POD type is a scalar type, a POD class, an array of such a type, or a cv-qualified version of one of these types.
https://eel.is/c++draft/depr.meta.types#4

The GNU and LLVM compilers warn:

std::is_pod is deprecated: use is_standard_layout && is_trivial instead

http://coliru.stacked-crooked.com/a/f305d9d6bc870456

Microsoft error/warning:

std::is_pod and std::is_pod_v are deprecated in C++20. The 
std::is_trivially_copyable and/or std::is_standard_layout traits likely suit your use case. 
You can define _SILENCE_CXX20_IS_POD_DEPRECATION_WARNING or 
_SILENCE_ALL_CXX20_DEPRECATION_WARNINGS to acknowledge that you have received this warning.

[mbozzi]

A POD type is both "trivial" and "standard-layout". So the concept "POD" has been split in two.

Simplifying a little, a type is trivial if default construction & destruction does nothing and copy/move assignments & constructors are deleted or defaulted on their first declaration.

This means trivial types have no virtual member functions, because that would require a virtual table pointer to be assigned on construction. It also means that any copy/assignment operations behave like a memmove call.

Likewise, a type is standard layout if it follows the same memory layout rules as C.

Trivial types can have performance advantages and standard layout types are useful for interoperation with other tools. These concepts are useful separately, so this is partly why is_pod is deprecated.

[jonnin]

? if you can't type << you can't make the macros either.
if you can get it from a virtual keyboard or char mapper or whatever, once, you can copy it afterwards so the macro is moot.

most macros let you do cool hacks that are not fit to be used in serious code. Fun, amusing, etc but terrible code.
I would rather see aprintf than a macro like that.

[Duthomhas]

The term POD is no longer used by the standard, and its type traits (std::is_pod etc.) are deprecated.

A POD type is both "trivial" and "standard-layout". So the concept "POD" has been split in two.

This is where language-lawyering in C++ just keeps getting more and more stoopid.

The language is already huge, and while managing concepts properly is indeed important, taking the time to remove a common, valid, historic type-introspection function for something wordier is a waste of entropy.