Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: A C++ program
192 views
Skip to first unread message
Message has been deleted
Message has been deleted
Melzzzzz
Apr 23, 2015, 11:08:14 PM4/23/15
to
On 24 Apr 2015 01:45:45 GMT
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >Do you know a C++-Implementation for Windows that can
>
> For example, on April 22, 2015 GCC 5.1 was released.
> Is there a Windows executable available?
It's too early, gcc 5.1 didn't hit my repo yet ;p
>
> I do not need to access special Windows features,
> just command-line I/O would be fine.
>
[bmaxa@maxa-pc examples]$ g++-trunk -Wall -std=c++14 -O3 -march=native -pthread should.cpp -o should
should.cpp: In function ‘int main()’:
should.cpp:15:19: error: unable to find string literal operator ‘operator""s’ with ‘const char [8]’, ‘long unsigned int’ arguments
::std::cout <<( "example"s ).find( 'x' ) << '\n';
[bmaxa@maxa-pc examples]$ /home/bmaxa/clang/bin/clang -Wall -std=c++1y -O3 -march=native -pthread should.cpp -o should
should.cpp:15:28: error: no matching literal operator for call to 'operator "" s' with arguments of types 'const char *' and 'unsigned long', and no matching literal operator template
::std::cout <<( "example"s ).find( 'x' ) << '\n';
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >Do you know a C++-Implementation for Windows that can
>
> For example, on April 22, 2015 GCC 5.1 was released.
> Is there a Windows executable available?
It's too early, gcc 5.1 didn't hit my repo yet ;p
>
> I do not need to access special Windows features,
> just command-line I/O would be fine.
>
[bmaxa@maxa-pc examples]$ g++-trunk -Wall -std=c++14 -O3 -march=native -pthread should.cpp -o should
should.cpp: In function ‘int main()’:
should.cpp:15:19: error: unable to find string literal operator ‘operator""s’ with ‘const char [8]’, ‘long unsigned int’ arguments
::std::cout <<( "example"s ).find( 'x' ) << '\n';
[bmaxa@maxa-pc examples]$ /home/bmaxa/clang/bin/clang -Wall -std=c++1y -O3 -march=native -pthread should.cpp -o should
should.cpp:15:28: error: no matching literal operator for call to 'operator "" s' with arguments of types 'const char *' and 'unsigned long', and no matching literal operator template
::std::cout <<( "example"s ).find( 'x' ) << '\n';
Message has been deleted
Melzzzzz
Apr 23, 2015, 11:37:53 PM4/23/15
to
On 24 Apr 2015 03:25:45 GMT
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> int main()
> { using namespace ::std::string_literals;
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >::std::cout <<( "example"s ).find( 'x' ) << '\n';
>
> I forgot a »using namespace«!
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> >::std::cout <<( "example"s ).find( 'x' ) << '\n';
>
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> int main()
> { using namespace ::std::string_literals;
> ::std::cout <<( "example"s ).find( 'x' ) << '\n'; }
>
Now it compiles fine.
>
Robbie Hatley
Apr 24, 2015, 8:34:07 AM4/24/15
to
On 4/23/2015 6:24 PM, Stefan Ram wrote:
> Is this a C++ that should be able to be compiled
> without compilation errors by a C++ compiler?
No. But see below.
> #include <initializer_list>
> #include <iostream>
> #include <ostream>
> #include <string>
> #include <regex>
> #include <ostream>
> #include <string>
> #include <thread>
> #include <memory>
>
> void alpha() { ::std::cout << "alpha\n"; }
>
> int main()
> { ::std::unique_ptr< ::std::string >s =
> ::std::make_unique< ::std::string >( "string" );
> ::std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
> ::std::cout <<( "example"s ).find( 'x' ) << '\n';
> ::std::thread t( alpha ); t.join(); }
Has errors. (see below)
> Do you know a C++-Implementation for Windows that can
> I am looking for a »precompiled binary« or windows
> installer, not a source tree.
Get Cygwin. It's a free development platform for Windows
which gives Windows a Linux-like feel (replaces cmd with
Bash for one thing, and re-interprets your file system
so that the Cygwin folder is / and the rest of your C: drive
is /cygdrive/c ). It has available compilers and interpreters
for a wide variety of programming languages: C, C++, Perl,
Python, Ruby, Haskel, and many more.
But your program has problems, even after I cleaned up some
of the more obvious errors (such as loads and loads of
superfluous colons):
#include <initializer_list>
#include <iostream>
#include <ostream>
#include <string>
#include <regex>
#include <ostream>
#include <string>
#include <thread>
#include <memory>
void alpha(void) {
std::cout << "alpha" << std::endl;
}
int main(void)
{
std::unique_ptr<std::string> s =
std::make_unique<std::string> ("string");
std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
std::cout << ("examples").find('x') << std::endl;
std::thread t(alpha);
t.join();
return 0;
}
Compilation attempt with g++ gives these errors:
%g++ -Wall -std=c++11 program.cpp -o program.exe
weird-program.cpp: In function ‘int main()’:
weird-program.cpp:16:7: error: ‘make_unique’ is not a member of ‘std’
std::make_unique<std::string> ("string");
^
weird-program.cpp:16:35: error: expected primary-expression before
‘>’ token
std::make_unique<std::string> ("string");
^
weird-program.cpp:18:30: error: request for member ‘find’ in
‘("examples")’, which is of non-class type ‘const char [9]’
std::cout << ("examples").find('x') << std::endl;
^
Hmmm. Function "make_unique" *should* be in header <memory>.
Ah, I see, I'm compiling with std=c++11, but I need std=c++14.
Then you need to rethink your usage of "find" a if it were
a method of a string literal. String literals don't have
methods. But std::string does, so i'll make that correction
for you. Yes, THIS version compiles:
#include <initializer_list>
#include <iostream>
#include <ostream>
#include <string>
#include <regex>
#include <ostream>
#include <string>
#include <thread>
#include <memory>
void alpha() {
std::cout << "alpha\n";
}
int main(void)
{
std::unique_ptr<std::string> s =
std::make_unique<std::string>("string");
std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
std::cout << std::string("examples").find('x') << std::endl;
std::thread t(alpha);
t.join();
return 0;
}
%g++ -Wall -std=c++14 program.cpp -o program.exe
[no errors, no warnings]
On running, prints:
1
alpha
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
Melzzzzz
Apr 24, 2015, 9:13:40 AM4/24/15
to
K. Frank
Apr 24, 2015, 11:59:35 AM4/24/15
to
Hi Stefan!
On Thursday, April 23, 2015 at 9:24:29 PM UTC-4, Stefan Ram wrote:
> Is this a C++ that should be able to be compiled
> without compilation errors by a C++ compiler?
Yes, I can get it to work with the mingw-w64 version
of g++ 4.9.2. See comments in line and below.
> #include <initializer_list>
> #include <iostream>
> #include <ostream>
> #include <string>
> #include <regex>
> #include <thread>
> #include <memory>
>
> void alpha() { ::std::cout << "alpha\n"; }
>
> int main()
> { ::std::unique_ptr< ::std::string >s =
As you noted in your follow-up posting, I needed
to add
using namespace ::std::string_literals;
Thus,
int main()
{
using namespace ::std::string_literals;
downloaded last year:
x86_64-4.9.2-release-posix-seh-rt_v3-rev0.7z
C:\>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
I successfully compiled your program as follows:
C:\>g++ -std=c++14 -o test test.cpp
(If I "downgrade" to "-std=c++11" it complains about
"string_literals" and "make_unique". Note, "-std=gnu++14"
also works.)
By the way, when I run your program it gives the following
output:
1
alpha
This is on 64-bit windows 7.
Happy Hacking!
K. Frank
On Thursday, April 23, 2015 at 9:24:29 PM UTC-4, Stefan Ram wrote:
> Is this a C++ that should be able to be compiled
> without compilation errors by a C++ compiler?
of g++ 4.9.2. See comments in line and below.
> #include <initializer_list>
> #include <iostream>
> #include <ostream>
> #include <string>
> #include <regex>
> #include <thread>
> #include <memory>
>
> void alpha() { ::std::cout << "alpha\n"; }
>
> int main()
> { ::std::unique_ptr< ::std::string >s =
to add
using namespace ::std::string_literals;
Thus,
int main()
{
using namespace ::std::string_literals;
::std::unique_ptr< ::std::string >s =
> ::std::make_unique< ::std::string >( "string" );
> ::std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
> ::std::cout <<( "example"s ).find( 'x' ) << '\n';
> ::std::thread t( alpha ); t.join(); }
>
> ::std::make_unique< ::std::string >( "string" );
> ::std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
> ::std::cout <<( "example"s ).find( 'x' ) << '\n';
> ::std::thread t( alpha ); t.join(); }
>
> Do you know a C++-Implementation for Windows that can
> execute this program (possibly after typos were corrected)?
> I am looking for a »precompiled binary« or windows
> installer, not a source tree.
Yes, I did this with a pre-built mingw-w64 compiler I
> execute this program (possibly after typos were corrected)?
> I am looking for a »precompiled binary« or windows
> installer, not a source tree.
downloaded last year:
x86_64-4.9.2-release-posix-seh-rt_v3-rev0.7z
C:\>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
I successfully compiled your program as follows:
C:\>g++ -std=c++14 -o test test.cpp
(If I "downgrade" to "-std=c++11" it complains about
"string_literals" and "make_unique". Note, "-std=gnu++14"
also works.)
By the way, when I run your program it gives the following
output:
1
alpha
This is on 64-bit windows 7.
Happy Hacking!
K. Frank
Robbie Hatley
Apr 26, 2015, 1:20:42 AM4/26/15
to
On 4/24/2015 6:13 AM, Melzzzzz wrote:
> On Fri, 24 Apr 2015 05:33:58 -0700
> Robbie Hatley <see.m...@for.my.address> wrote:
>
>
>> #include <initializer_list>
>> #include <iostream>
>> #include <ostream>
>> #include <string>
>> #include <regex>
>> #include <thread>
>> #include <memory>
>> void alpha(void) {
>> std::cout << "alpha" << std::endl;
>> }
>> int main(void)
>> {
>> std::unique_ptr<std::string> s =
>> std::make_unique<std::string> ("string");
>> std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
>> std::cout << ("examples").find('x') << std::endl;
>> std::thread t(alpha);
>> t.join();
>> return 0;
>> }
>>
>> Compilation attempt with g++ gives these errors:
>>
>> %g++ -Wall -std=c++11 program.cpp -o program.exe
>>
> You need -std=c++14 switch !
Scroll down. This was already covered in the part you erased
>> #include <initializer_list>
>> #include <iostream>
>> #include <ostream>
>> #include <string>
>> #include <regex>
>> #include <thread>
>> #include <memory>
>> void alpha(void) {
>> std::cout << "alpha" << std::endl;
>> }
>> int main(void)
>> {
>> std::unique_ptr<std::string> s =
>> std::make_unique<std::string> ("string");
>> std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
>> std::cout << ("examples").find('x') << std::endl;
>> std::thread t(alpha);
>> t.join();
>> return 0;
>> }
>>
>> Compilation attempt with g++ gives these errors:
>>
>> %g++ -Wall -std=c++11 program.cpp -o program.exe
>>
> You need -std=c++14 switch !
before replying:
Compilation attempt with g++ gives these errors:
%g++ -Wall -std=c++11 program.cpp -o program.exe
weird-program.cpp: In function ‘int main()’:
weird-program.cpp:16:7: error: ‘make_unique’ is not a member of ‘std’
weird-program.cpp:16:7: error: ‘make_unique’ is not a member of ‘std’
std::make_unique<std::string> ("string");
^
weird-program.cpp:16:35: error: expected primary-expression before
‘>’ token
weird-program.cpp:16:35: error: expected primary-expression before
‘>’ token
std::make_unique<std::string> ("string");
^
weird-program.cpp:18:30: error: request for member ‘find’ in
‘("examples")’, which is of non-class type ‘const char [9]’
weird-program.cpp:18:30: error: request for member ‘find’ in
‘("examples")’, which is of non-class type ‘const char [9]’
std::cout << ("examples").find('x') << std::endl;
^
Hmmm. Function "make_unique" *should* be in header <memory>.
Ah, I see, I'm compiling with std=c++11, but I need std=c++14. <<< HERE
Hmmm. Function "make_unique" *should* be in header <memory>.
Then you need to rethink your usage of "find" a if it were
a method of a string literal. String literals don't have
methods. But std::string does, so i'll make that correction
for you. Yes, THIS version compiles:
#include <initializer_list>
#include <iostream>
#include <ostream>
#include <string>
#include <regex>
#include <thread>
#include <memory>
void alpha() {
std::cout << "alpha\n";
}
#include <iostream>
#include <ostream>
#include <string>
#include <regex>
#include <thread>
#include <memory>
void alpha() {
std::cout << "alpha\n";
}
int main(void)
{
std::unique_ptr<std::string> s =
std::make_unique<std::string>("string");
std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
std::cout << std::string("examples").find('x') << std::endl;
{
std::unique_ptr<std::string> s =
std::make_unique<std::string>("string");
std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
std::thread t(alpha);
t.join();
return 0;
}
t.join();
return 0;
}
Richard
Apr 28, 2015, 3:55:10 PM4/28/15
to
[Please do not mail me a copy of your followup]
Robbie Hatley <see.m...@for.my.address> spake the secret code
<w9adncW9QZyupafI...@giganews.com> thusly:
>> Do you know a C++-Implementation for Windows that can
>> execute this program (possibly after typos were corrected)?
>> I am looking for a »precompiled binary« or windows
>> installer, not a source tree.
>
>Get Cygwin. [...]
Please god, no.
Just get Visual Studio Community Edition 2013. It's free and it just works.
<https://www.visualstudio.com/>
IMO, cygwin/mingw is a giant PITA on Windows and there isn't any need
for it. VS2013 represents C++11 quite well.
<https://msdn.microsoft.com/en-us/library/hh567368.aspx>
<http://en.cppreference.com/w/cpp/compiler_support>
Don't try to make Windows into Unix and don't try to make Unix into Windows.
Embrace them both for their strengths and learn their weaknesses.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Robbie Hatley <see.m...@for.my.address> spake the secret code
<w9adncW9QZyupafI...@giganews.com> thusly:
>> Do you know a C++-Implementation for Windows that can
>> execute this program (possibly after typos were corrected)?
>> I am looking for a »precompiled binary« or windows
>> installer, not a source tree.
>
Please god, no.
Just get Visual Studio Community Edition 2013. It's free and it just works.
<https://www.visualstudio.com/>
IMO, cygwin/mingw is a giant PITA on Windows and there isn't any need
for it. VS2013 represents C++11 quite well.
<https://msdn.microsoft.com/en-us/library/hh567368.aspx>
<http://en.cppreference.com/w/cpp/compiler_support>
Don't try to make Windows into Unix and don't try to make Unix into Windows.
Embrace them both for their strengths and learn their weaknesses.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Scott Lurndal
Apr 28, 2015, 4:43:41 PM4/28/15
to
legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>Robbie Hatley <see.m...@for.my.address> spake the secret code
><w9adncW9QZyupafI...@giganews.com> thusly:
>
>>> Do you know a C++-Implementation for Windows that can
>>> execute this program (possibly after typos were corrected)?
>>> I am looking for a »precompiled binary« or windows
>>> installer, not a source tree.
>>
>>Get Cygwin. [...]
>
>Please god, no.
>
>Just get Visual Studio Community Edition 2013. It's free and it just works.
><https://www.visualstudio.com/>
>
>IMO, cygwin/mingw is a giant PITA on Windows and there isn't any need
>for it. VS2013 represents C++11 quite well.
><https://msdn.microsoft.com/en-us/library/hh567368.aspx>
><http://en.cppreference.com/w/cpp/compiler_support>
>
>Don't try to make Windows into Unix and don't try to make Unix into Windows.
>
>Embrace them both for their strengths and learn their weaknesses
In other words, write two makefiles (or worse, whatever VS uses),
>[Please do not mail me a copy of your followup]
>
>Robbie Hatley <see.m...@for.my.address> spake the secret code
><w9adncW9QZyupafI...@giganews.com> thusly:
>
>>> Do you know a C++-Implementation for Windows that can
>>> execute this program (possibly after typos were corrected)?
>>> I am looking for a »precompiled binary« or windows
>>> installer, not a source tree.
>>
>>Get Cygwin. [...]
>
>Please god, no.
>
>Just get Visual Studio Community Edition 2013. It's free and it just works.
><https://www.visualstudio.com/>
>
>IMO, cygwin/mingw is a giant PITA on Windows and there isn't any need
>for it. VS2013 represents C++11 quite well.
><https://msdn.microsoft.com/en-us/library/hh567368.aspx>
><http://en.cppreference.com/w/cpp/compiler_support>
>
>Don't try to make Windows into Unix and don't try to make Unix into Windows.
>
>Embrace them both for their strengths and learn their weaknesses
have two completely distinct source bases or piles and piles of #ifdefs.
no thanks.
Öö Tiib
Apr 28, 2015, 5:07:09 PM4/28/15
to
On Tuesday, 28 April 2015 22:55:10 UTC+3, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Robbie Hatley <see.m...@for.my.address> spake the secret code
> <w9adncW9QZyupafI...@giganews.com> thusly:
>
> >> Do you know a C++-Implementation for Windows that can
> >> execute this program (possibly after typos were corrected)?
> >> I am looking for a »precompiled binary« or windows
> >> installer, not a source tree.
> >
> >Get Cygwin. [...]
>
> Please god, no.
Right.
> [Please do not mail me a copy of your followup]
>
> Robbie Hatley <see.m...@for.my.address> spake the secret code
> <w9adncW9QZyupafI...@giganews.com> thusly:
>
> >> Do you know a C++-Implementation for Windows that can
> >> execute this program (possibly after typos were corrected)?
> >> I am looking for a »precompiled binary« or windows
> >> installer, not a source tree.
> >
> >Get Cygwin. [...]
>
> Please god, no.
> Just get Visual Studio Community Edition 2013. It's free and it just works.
> <https://www.visualstudio.com/>
>
> IMO, cygwin/mingw is a giant PITA on Windows and there isn't any need
> for it.
MinGW works fine if you want to compile C or C++ on Windows.
> VS2013 represents C++11 quite well.
> <https://msdn.microsoft.com/en-us/library/hh567368.aspx>
> <http://en.cppreference.com/w/cpp/compiler_support>
unicode support "No" "No" and "No", defaulted and deleted functions
"Yes" but further weaseling shows that it does not work about move
constructors and assignments so "rule of zero" does not work.
It is on the midway between C++03 and C++11 while gcc on MinGW supports
most of the C++14.
> Don't try to make Windows into Unix and don't try to make Unix into Windows.
>
> Embrace them both for their strengths and learn their weaknesses.
web browser anyway. If you want native C++ then download Qt and it
looks passably native everywhere. Only few minor things (like
Bluetooth support on Android or OpenGL with some Intel budget
chips/drivers or annoyances with Apple's App-store) may take
some skill. Overall you will enjoy portable programming language
C++ ... at least way more portable than Java ever will be.
Richard
Apr 28, 2015, 5:32:16 PM4/28/15
to
[Please do not mail me a copy of your followup]
r...@zedat.fu-berlin.de (Stefan Ram) spake the secret code
<C++-20150...@ram.dialup.fu-berlin.de> thusly:
> Is this a C++ that should be able to be compiled
> without compilation errors by a C++ compiler?
>
>#include <initializer_list>
>#include <iostream>
>#include <ostream>
>#include <string>
>#include <regex>
>#include <thread>
>#include <memory>
>
>void alpha() { ::std::cout << "alpha\n"; }
>
>int main()
>#include <iostream>
>#include <ostream>
>#include <string>
>#include <regex>
>#include <thread>
>#include <memory>
>
>void alpha() { ::std::cout << "alpha\n"; }
>
>{ ::std::unique_ptr< ::std::string >s =
> ::std::make_unique< ::std::string >( "string" );
> ::std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
> ::std::regex pat {R"(\w{2}\s*\d{5}(-\d{4})?)"};
> ::std::cout <<( "example"s ).find( 'x' ) << '\n';
> ::std::thread t( alpha ); t.join(); }
>
> ::std::thread t( alpha ); t.join(); }
>
> Do you know a C++-Implementation for Windows that can
> execute this program (possibly after typos were corrected)?
> I am looking for a »precompiled binary« or windows
> installer, not a source tree.
The only thing VS2013 couldn't handle in this code was the string
> execute this program (possibly after typos were corrected)?
> I am looking for a »precompiled binary« or windows
> installer, not a source tree.
literal suffix (e.g. "example"s). I didn't try in VS2015 community
technology preview which I believe has this implemented according to
<http://en.cppreference.com/w/cpp/compiler_support>.
If you want even more C++11/14 compatibility, then you can continue
using the VS IDE and switch out the compiler for clang:
<http://www.ishani.org/projects/ClangVSX/> I haven't tried this
personally, but I trust in the quality of stuff produced by the clang
team. The project above simply packages what the clang team has been
doing into a nice add-on for Visual Studio.
"However, if nothing else, you can use ClangVSX as a quick way to
try out C++11/14 features that recent Clang releases have that
Visual Studio still does not..."
Richard
Apr 28, 2015, 5:44:19 PM4/28/15
to
[Please do not mail me a copy of your followup]
sl...@pacbell.net spake the secret code
<GhS%w.483012$IH4.2...@fx08.iad> thusly:
>>Don't try to make Windows into Unix and don't try to make Unix into Windows.
>>
>>Embrace them both for their strengths and learn their weaknesses
>
>In other words, write two makefiles (or worse, whatever VS uses),
>have two completely distinct source bases or piles and piles of #ifdefs.
>
>no thanks.
cross-platform code base, even if "cross platform" just means "more
varieties of Unix than a single linux distribution".
The original poster's code compiled just fine in VS2013 with one exception.
I didn't try it in VS 2015 community preview (also free), but I
suspect it would handle the one exception just fine as well.
If your code base is littered with #ifdef's, for whatever reason,
chances are you're abusing the preprocessor and should use other
superior abstraction mechanisms in C++ that have been there for
decades.
Paavo Helde
Apr 29, 2015, 12:56:48 AM4/29/15
to
legaliz...@mail.xmission.com (Richard) wrote in
news:mhooil$pcr$2...@news.xmission.com:
> [Please do not mail me a copy of your followup]
>
> Robbie Hatley <see.m...@for.my.address> spake the secret code
> <w9adncW9QZyupafI...@giganews.com> thusly:
>>
For developing unrelated software, not so much.
news:mhooil$pcr$2...@news.xmission.com:
> [Please do not mail me a copy of your followup]
>
> Robbie Hatley <see.m...@for.my.address> spake the secret code
> <w9adncW9QZyupafI...@giganews.com> thusly:
>>
>>Get Cygwin. [...]
>
> Please god, no.
>
>
> Please god, no.
>
> IMO, cygwin/mingw is a giant PITA on Windows and there isn't any need
> for it.
Cygwin is fine for getting a bunch of decent Unix tools working on Windows.
> for it.
For developing unrelated software, not so much.
David Brown
Apr 29, 2015, 3:08:46 AM4/29/15
to
different things, with a certain overlap and common history.
Cygwin was used a lot in the past as a way to get *nix software and
tools running on Windows - it emulates most of posix. It has the
disadvantages of being big, bulky, slow, and feeling "alien" in Windows
(plus not everyone likes the licensing terms).
Mingw provides a much smaller wrapper to make Windows look a bit more
posix-like, but without covering everything. (As an example, cygwin
provides "fork", even though it is very expensive to implement on
Windows. mingw is limited to "spawn" which is much faster and less
obtrusive. Mingw also lets you work with filenames and directories in
Windows style, rather than converting them to a bastardisation between
*nix and Windows.)
Mingw is a perfectly good toolchain for Windows - it's C support
(especially for the Mingw-w64 variant) is far superior to MS' tools.
And msys (or now msys2) is a solid set of *nix tools and command-line
utilities that are efficient and fit well with the rest of Windows.
But if you need to compile *nix software unchanged on Windows, then
cygwin might be the only way to do it.
Richard
Apr 29, 2015, 11:29:36 AM4/29/15
to
[Please do not mail me a copy of your followup]
Paavo Helde <myfir...@osa.pri.ee> spake the secret code
<XnsA48B50CC143F7m...@216.196.109.131> thusly:
>Cygwin is fine for getting a bunch of decent Unix tools working on Windows.
>For developing unrelated software, not so much.
If what you want is a C++ development environment, then get VS
community edition.
I am very comfortable and productive with the command-line, but I first
used a C++ IDE (VC6) in the late 1990s and now I don't want to go back
to the primitive tools of the unix command-line for building, writing,
editing, and debugging C++ code. (I'm OK with writing CMakeLists.txt,
because cmake operates at a higher level than make.)
I found myself much more productive using an IDE. Until recently, the
best IDE for C++ development was Visual Studio, but with the release
of CLion, it has a serious challenger. There are some things I like
about both; CLion has a much faster feel than VS for navigating,
editing and writing C++ code. VS has a truly awesome debugger. It
makes gdb look like the early 1990s immitation of dbx that it is. VS
has a better docking system than CLion. CLion has better refactoring
support, although I haven't yet tried the VS2015 refactoring support.
Richard
Apr 29, 2015, 11:33:25 AM4/29/15
to
[Please do not mail me a copy of your followup]
David Brown <david...@hesbynett.no> spake the secret code
<mhpvvi$om1$1...@dont-email.me> thusly:
>Mingw is a perfectly good toolchain for Windows - it's C support
>(especially for the Mingw-w64 variant) is far superior to MS' tools.
The POSIX implementation in MSVC has always been weak, although
apparently they're finally getting around to plugging some of the
holes in VS 2015.
>But if you need to compile *nix software unchanged on Windows, then
>cygwin might be the only way to do it.
with system differences between unix implementations for decades and
most of the time, dealing with the differences isn't a huge deal,
although it is annoying. That's the whole reason people have
configure scripts and the whole mess that is autotools and so-on.
Personally I find CMake's approach to the problem better than
autotools and it is more portable because it doesn't depend on bash or
perl or python or whatever.
David Brown
Apr 29, 2015, 5:30:48 PM4/29/15
to
On 29/04/15 17:33, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <mhpvvi$om1$1...@dont-email.me> thusly:
>
>> Mingw is a perfectly good toolchain for Windows - it's C support
>> (especially for the Mingw-w64 variant) is far superior to MS' tools.
>
> I think you're confusing C with POSIX here. They aren't the same thing.
> The POSIX implementation in MSVC has always been weak, although
> apparently they're finally getting around to plugging some of the
> holes in VS 2015.
No, MSVC has always been notoriously bad at standard C. It barely
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <mhpvvi$om1$1...@dont-email.me> thusly:
>
>> Mingw is a perfectly good toolchain for Windows - it's C support
>> (especially for the Mingw-w64 variant) is far superior to MS' tools.
>
> I think you're confusing C with POSIX here. They aren't the same thing.
> The POSIX implementation in MSVC has always been weak, although
> apparently they're finally getting around to plugging some of the
> holes in VS 2015.
implements the language parts of C99, and until only a couple of years
ago, it was missing substantial parts of the C99 library. For C++, I
believe it is only a few years behind the mainstream (gcc, llvm, Intel)
- but I haven't used it myself for quite some time.
Posix support is an issue for Windows and translation layers (like
cygwin, or the much smaller and thinner layers in mingw libraries) - and
despite promises when NT was new, Windows has never tried to support
posix properly.
>
>> But if you need to compile *nix software unchanged on Windows, then
>> cygwin might be the only way to do it.
>
> I agree with this because you said "unchanged". I've been dealing
> with system differences between unix implementations for decades and
> most of the time, dealing with the differences isn't a huge deal,
> although it is annoying. That's the whole reason people have
> configure scripts and the whole mess that is autotools and so-on.
> Personally I find CMake's approach to the problem better than
> autotools and it is more portable because it doesn't depend on bash or
> perl or python or whatever.
>
(limited) experience. But if you need to use it for something, then
cygwin is the way to go for the greatest compatibility. When I first
compiled a gcc cross-compiler on Windows, cygwin was the only "easy"
option - but for many years it's been possible (and /much/ faster and
easier) with mingw.
David Brown
Apr 29, 2015, 5:34:15 PM4/29/15
to
On 29/04/15 17:29, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Paavo Helde <myfir...@osa.pri.ee> spake the secret code
> <XnsA48B50CC143F7m...@216.196.109.131> thusly:
>
>> Cygwin is fine for getting a bunch of decent Unix tools working on Windows.
>> For developing unrelated software, not so much.
>
> Agreed. If what you want is sed/awk/grep, then by all means get cygwin.
No, get msys (or now msys2), which includes these tools compiled with
> [Please do not mail me a copy of your followup]
>
> Paavo Helde <myfir...@osa.pri.ee> spake the secret code
> <XnsA48B50CC143F7m...@216.196.109.131> thusly:
>
>> Cygwin is fine for getting a bunch of decent Unix tools working on Windows.
>> For developing unrelated software, not so much.
>
> Agreed. If what you want is sed/awk/grep, then by all means get cygwin.
mingw. They are faster, and a lot easier to use along with other
Windows stuff.
Only use cygwin if you need fork() and other "tougher" posix calls.
>
> If what you want is a C++ development environment, then get VS
> community edition.
emacs or vim).
>
> I am very comfortable and productive with the command-line, but I first
> used a C++ IDE (VC6) in the late 1990s and now I don't want to go back
> to the primitive tools of the unix command-line for building, writing,
> editing, and debugging C++ code. (I'm OK with writing CMakeLists.txt,
> because cmake operates at a higher level than make.)
>
> I found myself much more productive using an IDE. Until recently, the
> best IDE for C++ development was Visual Studio, but with the release
> of CLion, it has a serious challenger. There are some things I like
> about both; CLion has a much faster feel than VS for navigating,
> editing and writing C++ code. VS has a truly awesome debugger. It
> makes gdb look like the early 1990s immitation of dbx that it is. VS
> has a better docking system than CLion. CLion has better refactoring
> support, although I haven't yet tried the VS2015 refactoring support.
>
option for an IDE on Windows.
Richard
Apr 30, 2015, 11:05:57 AM4/30/15
to
[Please do not mail me a copy of your followup]
David Brown <david...@hesbynett.no> spake the secret code
<mhrifv$3jh$1...@dont-email.me> thusly:
David Brown <david...@hesbynett.no> spake the secret code
>On 29/04/15 17:33, Richard wrote:
>>
>> David Brown <david...@hesbynett.no> spake the secret code
>> <mhpvvi$om1$1...@dont-email.me> thusly:
>>
>>> Mingw is a perfectly good toolchain for Windows - it's C support
>>> (especially for the Mingw-w64 variant) is far superior to MS' tools.
>>
>
>No, MSVC has always been notoriously bad at standard C. It barely
>implements the language parts of C99, and until only a couple of years
>ago, it was missing substantial parts of the C99 library.
OK, I'll take your word for it on that. Honestly, I haven't written
>No, MSVC has always been notoriously bad at standard C. It barely
>implements the language parts of C99, and until only a couple of years
>ago, it was missing substantial parts of the C99 library.
*C* code since the early 1990s and I really don't want to go back to
writing C code having used C++ all this time.
>For C++, I
>believe it is only a few years behind the mainstream (gcc, llvm, Intel)
>- but I haven't used it myself for quite some time.
gaps, certainly when compared to the gcc that ships with enterprise
linux distributions. (I know, you can always build your own gcc to get
around that, but at a big linux shop where I worked for the past 4 years
we were stuck with the lowest common denominator among all distributions
which left us with gcc 4.2.1 and the irony that our Windows build had
access all the modern features, but our linux build did not.)
The whole compiler landscape has changed with C++11/14; compiler
implementations are not only keeping up with the standard, they are
often ahead of the standard by implementing C++14/17 features from
working drafts before they are officially adopted. Things are moving
much faster now than they have previously.
I believe this table is a pretty accurate comparison:
<http://en.cppreference.com/w/cpp/compiler_support>
If it's not, please edit the table to be more accurate :-).
David Brown
Apr 30, 2015, 11:20:03 AM4/30/15
to
On 30/04/15 17:05, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <mhrifv$3jh$1...@dont-email.me> thusly:
>
>> On 29/04/15 17:33, Richard wrote:
>>>
>>> David Brown <david...@hesbynett.no> spake the secret code
>>> <mhpvvi$om1$1...@dont-email.me> thusly:
>>>
>>>> Mingw is a perfectly good toolchain for Windows - it's C support
>>>> (especially for the Mingw-w64 variant) is far superior to MS' tools.
>>>
>>> I think you're confusing C with POSIX here. [...]
>>
>> No, MSVC has always been notoriously bad at standard C. It barely
>> implements the language parts of C99, and until only a couple of years
>> ago, it was missing substantial parts of the C99 library.
>
> OK, I'll take your word for it on that. Honestly, I haven't written
> *C* code since the early 1990s and I really don't want to go back to
> writing C code having used C++ all this time.
I write C all the time, but for embedded systems rather than PC's. But
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <mhrifv$3jh$1...@dont-email.me> thusly:
>
>> On 29/04/15 17:33, Richard wrote:
>>>
>>> David Brown <david...@hesbynett.no> spake the secret code
>>> <mhpvvi$om1$1...@dont-email.me> thusly:
>>>
>>>> Mingw is a perfectly good toolchain for Windows - it's C support
>>>> (especially for the Mingw-w64 variant) is far superior to MS' tools.
>>>
>>> I think you're confusing C with POSIX here. [...]
>>
>> No, MSVC has always been notoriously bad at standard C. It barely
>> implements the language parts of C99, and until only a couple of years
>> ago, it was missing substantial parts of the C99 library.
>
> OK, I'll take your word for it on that. Honestly, I haven't written
> *C* code since the early 1990s and I really don't want to go back to
> writing C code having used C++ all this time.
comp.lang.c has plenty of unpleasant things to say about MSVC for C.
>
>> For C++, I
>> believe it is only a few years behind the mainstream (gcc, llvm, Intel)
>> - but I haven't used it myself for quite some time.
>
> VS2013 is quite current and VS2015 is filling in more of the C++11/14
> gaps, certainly when compared to the gcc that ships with enterprise
> linux distributions. (I know, you can always build your own gcc to get
> around that, but at a big linux shop where I worked for the past 4 years
> we were stuck with the lowest common denominator among all distributions
> which left us with gcc 4.2.1 and the irony that our Windows build had
> access all the modern features, but our linux build did not.)
issues - I don't make much use of native compilers. But some shops have
very restrictive rules on the tools that developers are allowed to use -
for good reasons or for bad reasons.
>
> The whole compiler landscape has changed with C++11/14; compiler
> implementations are not only keeping up with the standard, they are
> often ahead of the standard by implementing C++14/17 features from
> working drafts before they are officially adopted. Things are moving
> much faster now than they have previously.
useful features, and C++14 improves them.
Richard
Apr 30, 2015, 11:21:45 AM4/30/15
to
[Please do not mail me a copy of your followup]
David Brown <david...@hesbynett.no> spake the secret code
<mhrimf$4di$1...@dont-email.me> thusly:
>Or mingw-w64 and an IDE (Eclipse, Code Blocks, JEdit, etc. - or even
>emacs or vim).
1988 through 1998. It's an editor with a keyboard shortcut to invoke
a build, not really an IDE.
vim? Some people swear by it with the multiple windows and whatnot
that are in vim (not classic vi). It might be usable with all the
doodads and extensions on top, but a good IDE is much more than an
editor. I haven't tried a vim-ified experience, but if you're using
it only as classic vi experience, then it's only good for small
projects in my opinion. I used it for editing code from 1978-ish
through 1988. I still use daily for editing email. I don't use it
for editing anything other than small "will this compile?" type
programs.
JEdit seems to be an editor and not an IDE.
Eclipse? God no, please don't. Go use CLion from JetBrains instead.
In fact, always prefer something from JetBrains over Eclipse. For
Java it simply blows Eclipse out of the water. Yes, JetBrains IDEs
are commercial, but if you're working on open source, ask for a free
license and you'll probably get one.
Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
haven't yet.
If your environment doesn't actually parse C++ to give you
semantically meaningful navigation (oops, that cuts out ctags and
therefore vim and emacs as well), refactoring (oops, that cuts out any
editor), an intelligent debugger (oops, that cuts out editors) and
so-on, then it's not an IDE. It's an editor with keyboard shortcuts
to invoke other programs to make up for its deficiencies as an IDE.
The "I" (integrated) in IDE really is important.
Christopher Pisz
Apr 30, 2015, 12:23:35 PM4/30/15
to
On 4/30/2015 10:21 AM, Richard wrote:
SNIP
> Eclipse? God no, please don't. Go use CLion from JetBrains instead.
> In fact, always prefer something from JetBrains over Eclipse. For
> Java it simply blows Eclipse out of the water. Yes, JetBrains IDEs
> are commercial, but if you're working on open source, ask for a free
> license and you'll probably get one.
How does CLion measure up to Msvc if one intends to solely write code on
Windows? Is there any advantage to it? Is it difficult to find all the
common windows libs and such, like the winsock lib? Come with them?
I see the price tag is lower for an individual license and Intellisense
has really been pissing me off lately.
Or would it be more for a person who is writing code for multiple platforms?
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
SNIP
> Eclipse? God no, please don't. Go use CLion from JetBrains instead.
> In fact, always prefer something from JetBrains over Eclipse. For
> Java it simply blows Eclipse out of the water. Yes, JetBrains IDEs
> are commercial, but if you're working on open source, ask for a free
> license and you'll probably get one.
Windows? Is there any advantage to it? Is it difficult to find all the
common windows libs and such, like the winsock lib? Come with them?
I see the price tag is lower for an individual license and Intellisense
has really been pissing me off lately.
Or would it be more for a person who is writing code for multiple platforms?
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Öö Tiib
Apr 30, 2015, 12:50:37 PM4/30/15
to
On Thursday, 30 April 2015 18:21:45 UTC+3, Richard wrote:
> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
> haven't yet.
From general purpose IDEs NetBeans understands and highlights C++ lot
> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
> haven't yet.
better than Code Blocks and tools seem also easier to integrate to it.
If you want to design for iPad or iPhone then you need Apple Xcode
that is otherwise not too good IDE. If you want to try Qt then it
is easiest with Qt Creator that is passable for IDE.
Paavo Helde
Apr 30, 2015, 2:12:50 PM4/30/15
to
legaliz...@mail.xmission.com (Richard) wrote in news:mhth9u$11t$2
@news.xmission.com:
> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
> haven't yet.
IMO you have not lost anything. My list of complaints about C::B is so long
I cannot even start.
@news.xmission.com:
> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
> haven't yet.
I cannot even start.
Richard
Apr 30, 2015, 3:00:03 PM4/30/15
to
[Please do not mail me a copy of your followup]
Paavo Helde <myfir...@osa.pri.ee> spake the secret code
<XnsA48CD7BEE3FFmy...@216.166.105.131> thusly:
refactoring test suite against it:
<https://github.com/LegalizeAdulthood/refactor-test-suite>
So far, CLion has been the best performer against this test suite.
(Which reminds me, I need to rerun the suite against the CLion 1.0
release build.)
Ian Collins
Apr 30, 2015, 3:22:20 PM4/30/15
to
嘱 Tiib wrote:
> On Thursday, 30 April 2015 18:21:45 UTC+3, Richard wrote:
>> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
>> haven't yet.
>
> From general purpose IDEs NetBeans understands and highlights C++ lot
> better than Code Blocks and tools seem also easier to integrate to it.
NetBeans remote build options and lack of visual clutter are some of the
> On Thursday, 30 April 2015 18:21:45 UTC+3, Richard wrote:
>> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
>> haven't yet.
>
> From general purpose IDEs NetBeans understands and highlights C++ lot
> better than Code Blocks and tools seem also easier to integrate to it.
reasons I prefer it over Eclipse. When developing for multiple
compilers/targets "build all" from the IDE is a blessing!
--
Ian Collins
David Brown
Apr 30, 2015, 4:57:17 PM4/30/15
to
- I prefer to keep my source code and build system independent of the
editor in use.
Maybe I'll give NetBeans a shot some time - I've only heard good things
about it. But Eclipse is the standard in the embedded world, and almost
all integrated development tools are based on it (except Microchip uses
NetBeans, and Atmel uses MSVC). It's easy enough to use a different
editor, and Makefiles keeps the builds independent of the IDE, but
sometimes low-level debugging can't be done with anything other than the
vendor's tools - and that usually means Eclipse.
Eclipse used to be painfully slow, buggy and bloated, but I find it
works well these days.
0 new messages