"Visual C++ - Microsoft Pushes C++ into the Future"

[Lynn McGuire]

"Visual C++ - Microsoft Pushes C++ into the Future"
https://msdn.microsoft.com/en-us/magazine/mt694085.aspx

Lynn

[Real Troll]

Any ideas when is the next Visual C++ coming out?

I have VC++ since version 10 (10, 12, 13, 15) and I love it!!

[Bo Persson]

On 2017-01-10 21:25, Real Troll wrote:
> On 10/01/2017 20:05, Lynn McGuire wrote:
>> "Visual C++ - Microsoft Pushes C++ into the Future"
>> https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
>>
>> Lynn
>
>
> Any ideas when is the next Visual C++ coming out?
>

Soon-ish. It's at the Release Candidate level.

https://www.visualstudio.com/vs/visual-studio-2017-rc/


Bo Persson

[Rick C. Hodgin]

RC Candidate 2017 is out. Its IDE is slow and clunky at times. I've
seen the "Visual Studio is still working. We're sending feedback to
Microsoft about this UI action" pop up. And sometimes even simple
UI operations are very oddly timed for giving user feedback.

Best regards,
Rick C. Hodgin

[David Brown]

Modules are a great idea, at least in principle - I haven't followed
enough of the details to give a technical opinion. But it would have
been nice to see more cooperation between MSVC developers and clang
developers - clang has had an experimental module implementation for
some time now, and I believe MSVC wanting to go their own way has been a
big reason for C++17 not having modules. If the MS idea is technically
significantly better, that's fair enough - but not if it is just them
trying to be "first" at something in the C++ world.

Still, it's nice to see MSVC are catching up with C++14.

[Richard]

[Please do not mail me a copy of your followup]

David Brown <david...@hesbynett.no> spake the secret code
<o53kep$fq9$1...@dont-email.me> thusly:

>Modules are a great idea, at least in principle - I haven't followed
>enough of the details to give a technical opinion. But it would have
>been nice to see more cooperation between MSVC developers and clang
>developers -

Gabriel Dos Reis is a long-time gcc contributor and is the main person
behind modules at Microsoft. I guarantee you that he collaborates
with clang/gcc developers regarding modules.

>[...] clang has had an experimental module implementation for
>some time now,

If you look more deeply into what's been implemented in clang you find
that it's somewhere between an advanced precompiled header and a
module. It's less than full-blown modules and it's more than a
precompiled header.

>and I believe MSVC wanting to go their own way has been a
>big reason for C++17 not having modules.

What Gabriel Dos Reis has proposed is a direct result of experience
using the modules implementation in clang, not something that stabs
out in a completely different direction just for the sake of being
different.

>If the MS idea is technically
>significantly better, that's fair enough - but not if it is just them
>trying to be "first" at something in the C++ world.

Sorry, but this is just supposition on your part and doesn't seem to
be based on any of the actual information from either folks on the
clang team who have described their work with modules or from Gabriel
Dos Reis who has described Microsoft's work with modules.

AFAIK, what the clang team did never resulted in a formal proposal to
the standards committe. Maybe there was some working paper proposal
but a little googling didn't turn it up. Gabriel Dos Reis (and
collaborators) created a proposal to the standards committe that was
most definitely informed by the experiments dont with clang. I
suggest you take a look at the proposal. This is one version, there
may be a newer version: <https://isocpp.org/files/papers/N4047.pdf>.
For earlier discussions of a module system, see the references in the
above paper.

I'm unaware of any attempt, experimental or otherwise, to support modules
in gcc.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[David Brown]

Thank you for the information. I am glad to be corrected here - the C++
world gets better when everyone is working together. I guess I am just
a little disappointed that there are no modules in C++17, and I felt it
was unhelpful to have two competing (as I saw it) module systems. But
it was unfair of me to suggest that this was anything other than
people's desire to make a good technical solution rather than a fast fix.

> I'm unaware of any attempt, experimental or otherwise, to support modules
> in gcc.
>

I presume they are waiting until a solution is finalised (rather than
having yet another experimental version).

[Richard]

[Please do not mail me a copy of your followup]

David Brown <david...@hesbynett.no> spake the secret code

<o53qju$6lk$1...@dont-email.me> thusly:

>Thank you for the information. I am glad to be corrected here - the C++
>world gets better when everyone is working together.

You're welcome, and thanks for the non-hostile attitude that one
normally sees on usenet :).

>I guess I am just
>a little disappointed that there are no modules in C++17,

Yeah, I wanted it as well, but if no standards committee proposal
resulted from the clang experiments and there was no gcc
implementation, it doesn't surprise me that it was considered too
green for C++17. They are really cautious about introducing new stuff
into the standard that hasn't been well tested.

>and I felt it
>was unhelpful to have two competing (as I saw it) module systems.

I consider the standards proposal to be an evolution of the clang
system instead of a competing system. It is different because it
incorporates the lessons learned from the clang experiments.

>I presume they are waiting until a solution is finalised (rather than
>having yet another experimental version).

Lots of proposed stuff for C++11, C++14 and C++17 has been implemented
from working paper proposals and the working proposal from Gabriel Dos
Reis et al seems good enough to me to start a working implementation.

[Ian Collins]

C++14 has been the compiler's default mode for a while now.

--
Ian

[David Brown]

On 11/01/17 01:46, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <o53qju$6lk$1...@dont-email.me> thusly:
>
>> Thank you for the information. I am glad to be corrected here - the C++
>> world gets better when everyone is working together.
>
> You're welcome, and thanks for the non-hostile attitude that one
> normally sees on usenet :).
>
>> I guess I am just
>> a little disappointed that there are no modules in C++17,
>
> Yeah, I wanted it as well, but if no standards committee proposal
> resulted from the clang experiments and there was no gcc
> implementation, it doesn't surprise me that it was considered too
> green for C++17. They are really cautious about introducing new stuff
> into the standard that hasn't been well tested.

Some things get in faster, but I suppose in this case if the module
system under test turns out to have subtle flaws, it could cause /real/
problems for the future.

>
>> and I felt it
>> was unhelpful to have two competing (as I saw it) module systems.
>
> I consider the standards proposal to be an evolution of the clang
> system instead of a competing system. It is different because it
> incorporates the lessons learned from the clang experiments.

Fair enough.

>
>> I presume they are waiting until a solution is finalised (rather than
>> having yet another experimental version).
>
> Lots of proposed stuff for C++11, C++14 and C++17 has been implemented
> from working paper proposals and the working proposal from Gabriel Dos
> Reis et al seems good enough to me to start a working implementation.
>

Maybe they just haven't got round to it yet - there is no shortage of
tasks for the gcc developers (or clang developers, or, I expect, MSVC
developers). But if MSVC implements this, and clang update their
implementation to the same working paper proposal, then I would expect
gcc to follow if the current proposal is considered solid enough. It's
good not to have too many highly experimental implementations of a
feature, but also good to have more implementations once the feature
nears stability.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]

>If you look more deeply into what's been implemented in clang you find
>that it's somewhere between an advanced precompiled header and a
>module. It's less than full-blown modules and it's more than a
>precompiled header.

I really don't see the advantage to this. I worked for most of
a decade with a language called SPRITE which had modules, and
pre-compiled headers (called a Module Interface Definition). One
big source file defining all the modules, the public and private
module interfaces, composite types and global variables.

For large projects (this was a mainframe operating system), there
was significant contention to edit the MID (somewhat alleviated by
the patch method used to edit - engineers would submit patches to
the MID Master file, which would be re-generated once a week or
thereabouts).

C++ was perfect at version 2.1, and has been going downhill
ever since.

[jonkalb]

On Wednesday, January 11, 2017 at 10:06:59 AM UTC-8, Scott Lurndal wrote:

> C++ was perfect at version 2.1, and has been going downhill
> ever since.

I've heard of C++98, C++03, C++11, C++14, and C++17, but I've never heard of C++ version 2.1.

[Robert Wessel]

On Wed, 11 Jan 2017 19:55:32 -0800 (PST), jonkalb <goo...@kalbweb.com>
wrote:

Before standardization, C++ usually had version numbers. C++2.0 was
mostly what was described by the second edition of Stroustrup's "The
C++ Programming Language", or roughly the language as of 1989 (the
book was published in 1991). What's called 2.1 is, I think, what
corresponds to the 3rd edition of that book (published 1997),
reflecting the language of a year or two prior to that.

All approximately.

[Scott Lurndal]

2.1 came out about 1991, IIRC. We started using C++ in
1989 for an operating system project, and upgraded to
Cfront 2.1 about '91 or thereabouts.

I think the 3rd edition of the book represents C++ 3.0
which was the first release to have templates and exceptions.

(In those days, C++ was compiled to C then compiled with
a vanilla C compiler (we used a port of PCC for the motorola
88100 RISC processor))

[red floyd]

On 1/11/2017 10:06 AM, Scott Lurndal wrote:

> I really don't see the advantage to this. I worked for most of
> a decade with a language called SPRITE which had modules, and
> pre-compiled headers (called a Module Interface Definition). One
> big source file defining all the modules, the public and private
> module interfaces, composite types and global variables.

Dude, you were at Burroughs (later Unisys)? I interviewed there
back in '84!!!

[Scott Lurndal]

Indeed. In the Pasadena MCP group working on Omega (what became MCP/VS 2.0);
started in '83.

[red floyd]

No kidding? That's where I interviewed! As a side note, IIRC, SPRITE
looked a heck of a lot like Modula-2.

[Scott Lurndal]

Yes, the language designers were influenced by Algol and Modula.

07963000$SET CONTENTS "PROC: show_known_ssps"
07964000% ---------------------------------------------------------
07965000% | |
07966000 show_known_ssps
07967000% | |
07968000% ---------------------------------------------------------
07969000
07970000PROC( ssp_time VALUE SSP_TIME );
07971000SHARES
07972000 CONST loader_storage, %108
07973000 CONST mcp_identification,
07974000 VAR message_storage,
07975000 CONST pointer_reference_table,
07976000 VAR queue_storage;
07977000
07978000CONST
07979000 no_firmware STRING (9) OF HEX = "080347000";
07980000
07981000VAR
07982000 base_ptr DAT_POINTER,
07983000 ch_ptr PTR TO CHANNEL_TABLE_ENTRY,
07984000 keyboard_message STRING (30) OF HEX :=
07985000
07986000% PROC # <n> - SSP ON CC/UU
07987000
07988000 "244" + "C7B" + "AF0" + "C60" + "387" + "087" + "800" + "000",
07989000
07990000 procno PACKED STRUC
07991000 CASE BOOLEAN
07992000 IS true:
07993000 as_int DINT1
07994000 OR false:
07995000 as_hex HEX2
07996000 ESAC
07997000 CURTS := [true, processor_number],
07998000 search_done BOOLEAN;
07999000
08000000
08001000
08002000 keyboard_message[8::2] := procno.as_hex;
08003000 base_ptr := ioat_ptrs.first_element;
08004000 search_done := false;
08005000
08006000 DO
08007000 FIND ioat_ptr OVER base_ptr..ioat_ptrs.last_element
08008000 INTO ioat_ptrs.base @
08009000 WHERE ioat_ptr@.primary_hardware_type = shared_system_processor
08010000 THEN
08011000 message_iosta := ioat_ptr @.device_status_number;
08012000 ch_ptr := ptr( channel_table_ptrs.base @
08013000 [ioat_ptr @.primary_channel_number] );
08014000
08014000
08015000 IF ^ch_ptr @.flags.good_firmware_file
08016000 THEN
08017000 keyboard_message[22::9] := no_firmware;
08018000 ELSE
08019000 keyboard_message[22::3] := fill_string( "0" );
08020000 FI;
08021000
08022000 kbout_mod.kbospr( keyboard_message );
08023000
08024000 IF load_flag = cold_start %108
08025000 THEN %108
08026000 q1.ioat_address_in_dat := ioat_ptr;
08027000 q1.virtual_opcode_variants := vop_ssp_set_time;
08028000 q1.copy_desc := mcp.copy_desc( system_initialization,
08029000 data_page );
08030000 mcp.move_repeat( mcp.offset_ptr( ssp_time ),
08031000 q1.relative_buffer_addresses );
08032000 q1.relative_buffer_end_addr +:= SSP_TIME.SIZE;
08033000 q1.mcp_generated_io := true;
08034000 q1.ignore_unrecovered_error := true;
08035000
08036000 io_mod.initiate_mcp_io; % Set the time
08037000
08038000 FI; %108
08039000 base_ptr := ptr_add( ioat_ptr, 1 );
08040000 ELSE
08041000 search_done := true;
08042000 DNIF;
08043000
08044000 OD UNTIL search_done;
08045000
08046000CORP;

constructs like the FIND statement were mapped to one of the search
instructions.

http://vseries.lurndal.org/doku.php?id=instructions:sea
http://vseries.lurndal.org/doku.php?id=instructions:slt

[Rick C. Hodgin]

On Tuesday, January 10, 2017 at 3:05:30 PM UTC-5, Lynn McGuire wrote:
> "Visual C++ - Microsoft Pushes C++ into the Future"
> https://msdn.microsoft.com/en-us/magazine/mt694085.aspx

I remember when Visual Studio 98 came out. I was mostly a DOS user
back then. I used Windows 3.x and later, but for most of my development
I was using The SemWare Editor, DOS 6.22, and Microsoft MASM 6.11d, and
Microsoft C++ 6.1.

When I began looking at Visual Studio 98 I was still thinking of the
standard development model: code, compile, link, test, exit, back to
code, compile again, link again, test again, repeat.

But, one day I accidentally made a change to source code in the debug
window and pressed F10 to single-step continue. It said "Applying
changes..." and then single-stepped.

I sat there ... with my jaw hanging open. I didn't know what had just
happened. I said out loud, "What?" And then I began to try it again
and I realized what it was doing.

And that was when I was introduced to what has since become my most
valuable debugging tool. I hold edit-and-continue to be the absolute
highest possible tool a person can possess (beyond the common/standard
debugging abilities like watch, inspect memory, break, step, manually
change variables, etc.).

Visual Studio is my tool of choice for development SOLELY for that
reason. And when I get CAlive completed, it will have a very robust
version of that feature.

I wanted to share this because Visual Studio often times gets a bad
rap. I do not advise anyone using any Visual Studios between 2010
and 2015, as Microsoft really went off track for a while. 2015
brought them mostly back, and 2017 looks to be similar (though I
have not done much with it yet as it's still clunky in RC state).

Visual Studio is a very powerful tool. It can increase your
productivity so much. And if you get a Windows VM running in a
Linux environment, you can use VS in the Windows VM with a network
drive mapped to your Linux partition, and you're able to develop
your Linux apps using Visual Studio, flip to the terminal window
and compile and run. And with Visual Studio 2015's code analyzer
feature, it will find a lot more bugs that have never shown up
in your code.

A very powerful tool.

[Scott Lurndal]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
>On Tuesday, January 10, 2017 at 3:05:30 PM UTC-5, Lynn McGuire wrote:
>> "Visual C++ - Microsoft Pushes C++ into the Future"
>> https://msdn.microsoft.com/en-us/magazine/mt694085.aspx
>
>I remember when Visual Studio 98 came out. I was mostly a DOS user
>back then. I used Windows 3.x and later, but for most of my development
>I was using The SemWare Editor, DOS 6.22, and Microsoft MASM 6.11d, and
>Microsoft C++ 6.1.
>

>Visual Studio is a very powerful tool. It can increase your
>productivity so much. And if you get a Windows VM running in a
>Linux environment, you can use VS in the Windows VM with a network
>drive mapped to your Linux partition, and you're able to develop
>your Linux apps using Visual Studio, flip to the terminal window
>and compile and run. And with Visual Studio 2015's code analyzer
>feature, it will find a lot more bugs that have never shown up
>in your code.
>
>A very powerful tool.

There are a dozen native IDE's available for linux with all the
same features as VS. But none of them are as useful than VIM+Make+GDB.

[Rick C. Hodgin]

That, my friend, is a viscous rumor stared by aliens.

[Rick C. Hodgin]

On Thursday, January 12, 2017 at 1:29:46 PM UTC-5, Scott Lurndal wrote:

Actually, I've never found one. The closest I've found is Sun Studio
for Solaris. But since Oracle is closing up all the sources, it's not
a viable target any longer.

Show me a Linux-based toolkit that has edit-and-continue and the same
type of refactoring abilities Visual Studio has with some of the
plugins / extensions available and I'll try it.

[Ian Collins]

Oh I wish there were... Then I could convince the bulk of my current
team to migrate off Windows.

> But none of them are as useful than VIM+Make+GDB.

Spoken like a true Luddite!

--
Ian

[Cholo Lennon]

Well, AFAIK nobody has the awesome "edit and continue" feature except VS
(which IMHO has the best debugger out there).


--
Cholo Lennon
Bs.As.
ARG

[Rick C. Hodgin]

There was an effort spear-headed by Apple a few years back to get
"fix-and-continue" working in their toolchain + gdb. As I understand
it, they completed it and got it working fairly decently (though not
bug free).

I do not use Apple products so I have no idea where it is today. I've
just seen forum posts from time to time dating back to the 2000s.

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<edq3af...@mid.individual.net> thusly:

>On 01/13/17 07:29 AM, Scott Lurndal wrote:
>> There are a dozen native IDE's available for linux with all the
>> same features as VS.

Clearly you don't use VS for anything more fancy than typing.

There is only one IDE that comes even close to VS productivity and
that is CLion.

>> But none of them are as useful than VIM+Make+GDB.

Yes, you are using an IDE for typing. They do much more than that.

Oh, and gdb is absolutely horrible. It hasn't changed in 20+ years
since I first used it. The VS debugger crushes gdb.

[Rick C. Hodgin]

On Thursday, January 12, 2017 at 4:13:58 PM UTC-5, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <edq3af...@mid.individual.net> thusly:
>
> >On 01/13/17 07:29 AM, Scott Lurndal wrote:
> >> There are a dozen native IDE's available for linux with all the
> >> same features as VS.
>
> Clearly you don't use VS for anything more fancy than typing.
>
> There is only one IDE that comes even close to VS productivity and
> that is CLion.
>
> >> But none of them are as useful than VIM+Make+GDB.
>
> Yes, you are using an IDE for typing. They do much more than that.
>
> Oh, and gdb is absolutely horrible. It hasn't changed in 20+ years
> since I first used it. The VS debugger crushes gdb.

I agree. Microsoft's Visual Studio development platform is second
to none. It is the model I am seeking to use as a base for my own
IDE. I have the same drag/drop/popout window plan, along with some
new extensions I'd like to see.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>Ian Collins <ian-...@hotmail.com> spake the secret code
><edq3af...@mid.individual.net> thusly:
>
>>On 01/13/17 07:29 AM, Scott Lurndal wrote:
>>> There are a dozen native IDE's available for linux with all the
>>> same features as VS.
>
>Clearly you don't use VS for anything more fancy than typing.
>
>There is only one IDE that comes even close to VS productivity and
>that is CLion.
>
>>> But none of them are as useful than VIM+Make+GDB.
>
>Yes, you are using an IDE for typing. They do much more than that.
>
>Oh, and gdb is absolutely horrible. It hasn't changed in 20+ years
>since I first used it. The VS debugger crushes gdb.

VS doesn't run on linux. That automatically makes it a non-starter.

[Cholo Lennon]

On 01/12/2017 06:13 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <edq3af...@mid.individual.net> thusly:
>
>> On 01/13/17 07:29 AM, Scott Lurndal wrote:
>>> There are a dozen native IDE's available for linux with all the
>>> same features as VS.
>
> Clearly you don't use VS for anything more fancy than typing.
>
> There is only one IDE that comes even close to VS productivity and
> that is CLion.
>

I haven't tested CLion very well (is not free), but I use other IDEs
from Jetbrains (IntelliJ/PyCharm), they are really good. On
Linux/Solaris I use Eclipse CDT for C++, it's not bad and in some
categories is (way) better than VS.

>>> But none of them are as useful than VIM+Make+GDB.
>
> Yes, you are using an IDE for typing. They do much more than that.
>

> Oh, and gdb is absolutely horrible. It hasn't changed in 20+ years
> since I first used it. The VS debugger crushes gdb.
>

I agree

[Asger Joergensen]

Hi Richard
%

Richard wrote:

> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <edq3af...@mid.individual.net> thusly:
>
> > On 01/13/17 07:29 AM, Scott Lurndal wrote:
> >> There are a dozen native IDE's available for linux with all the
> >> same features as VS.
>
> Clearly you don't use VS for anything more fancy than typing.
>
> There is only one IDE that comes even close to VS productivity and
> that is CLion.

Don't forget C++Bulder

Best regards
Asger

[Lynn McGuire]

Is that the descendant of Turbo C ? The Turbo Pascal and Turbo C IDEs were freaking awesome. I developed several products with
those back in the 80s.

Lynn

[jonkalb]

On Wednesday, January 11, 2017 at 8:21:38 PM UTC-8, robert...@yahoo.com wrote:
> On Wed, 11 Jan 2017 19:55:32 -0800 (PST), jonkalb <goo...@kalbweb.com>
> wrote:
>
> >On Wednesday, January 11, 2017 at 10:06:59 AM UTC-8, Scott Lurndal wrote:
> >
> >> C++ was perfect at version 2.1, and has been going downhill
> >> ever since.
> >
> >I've heard of C++98, C++03, C++11, C++14, and C++17, but I've never heard of C++ version 2.1.
>
>
> Before standardization, C++ usually had version numbers.

No.

> C++2.0 was
> mostly what was described by the second edition of Stroustrup's "The
> C++ Programming Language", or roughly the language as of 1989 (the
> book was published in 1991). What's called 2.1 is, I think, what
> corresponds to the 3rd edition of that book (published 1997),
> reflecting the language of a year or two prior to that.

You are referring to CFront version numbers, not language version numbers.

But at least I understand now what you meant.

[Asger Joergensen]

Hi Lynn

>
> Is that the descendant of Turbo C ? The Turbo Pascal and Turbo C IDEs were
> freaking awesome. I developed several products with those back in the 80s.
>

Yes a direct line, but a lot have happened since then:
https://www.embarcadero.com/

Best regards
Asger

[Richard]

[Please do not mail me a copy of your followup]

"Asger Joergensen" <Ju...@Asger-P.dk> spake the secret code
<xn0kkyqiy...@news.astraweb.com> thusly:

I forgot about it after having used it 15 years ago :)

[Scott Lurndal]

jonkalb <goo...@kalbweb.com> writes:

>
>You are referring to CFront version numbers, not language version numbers.

The two were, of course, one and the same at the time.

[jonkalb]

No.

Even if there is only one compiler for a language there is still a difference between the compiler and the language.

In the case of C++ and CFront, by the time CFront 2.1 was released, there were C++ compilers available from Glockenspiel (Nov. '86), GNU (Dec. '87), Oregon Software (Jan. '88), and Zortech (Jun. '88). The Glockenspiel compiler was a CFront port, but had its own release numbers.

Jon

[Öö Tiib]

You write twice that version numbers of C++ reference implementation were
*incorrect* to use as version numbers of C++ specification. However
you fail second time to type what you consider as *correct*. What version
of C++ specification did CFront 2.1 implement? How you tell it? Why?
Since with just CFront version number as contender on stage it stays the
winner and any argumentation is waste of words. ;-)

[Cholo Lennon]

C++ Builder is (or was) really nice (I used it a lot until version 6),
but IMO has some problems:

- It's proprietary
- It's very expensive
- Its main libraries (VCL and FireMonkey) are coded in Object Pascal:
this imposes some limitations to C++, ie. some kind of MI are not
allowed or source/header files (related to VCL) must have a strict
naming convention in order to be compilable. Also debugging Pascal code
is not funny :-P
- Until recently its compiler was behind modern standards (AFAIK they
changed their ancient compiler for clang)
- It doesn't support Linux.
- It is difficult to integrate 3rd party libraries (nobody test their
libraries with C++ Builder)