Any tips?

[eli m]

I am coming to C++ from python. Do you guys have any tips for me? Examples: How to learn it effectively, what not to do, etc.

[Ian Collins]

eli m wrote:
> I am coming to C++ from python. Do you guys have any tips for me?
> Examples: How to learn it effectively, what not to do, etc.

Don't use trial and error!

Find a decent book, there have been several recent threads covering
recommendation here.

Posting here with problems is fine.

Do try and clean up the mess that appalling google interface makes of
your posts and quotes!

See http://www.netmeister.org/news/learn2quote.html

--
Ian Collins

[Saeed Amrollahi]

On Wednesday, March 6, 2013 5:26:40 AM UTC+3:30, eli m wrote:
> I am coming to C++ from python. Do you guys have any tips for me? Examples: How to learn it effectively, what not to do, etc.

Hi
1. At first you should understand the common property
between C++ and Python is both are programming languages, period.
They are so different with each other with different idioms/styles.
While Python is dynamic programming language, C++ is type-safe static language.
Static type checking, type safety and increasing relay on compiler are among
major characteristics of C++
2. You should never learn "Modern" C++ with a book that was written before
1997. My recommendations:
1) Andrew Koenig & Barbara Moo. Accelerated C++, Addison-Wesley, 2000.
2) Bjarne Stroustrup. Programming: Principles and Practice in C++,
Addison-Wesley, 2009.
3) Bjarne Stroustrup. The C++ Programming Language, Addison-Wesley,
2013. (Coming soon)
4) Stanley Lippman, Josee Lajoie & Barbara Moo. C++ Primer, 2012.
5) Bjarne Stroustrup. The C++ Programming Language, Addison-Wesley,
special edition, 2000.
At this time, the point is: use C++98 or C++11, the books
1, 2 and 5 are based on C++98 and 3 and 4 based on C++11.
of course there other good books. I believe the book #1 and #2
are really good. #1 is concise and #2 is very detailed about
programming not C++.
3. If you would like use C++ effectively as you mentioned
you have to use C++ as C++, not as "C with some stuffs".
In Modern C++, you should use standard library at first
place: use string rather than C-style char. string, use vector
and array (C++11) rather than C-Style arrays and a lot of
generic algorithms in STL part of C++ standard library.
4. Use modern C++ programming environment.
My recommendation:
- Visual Studio 2012, Visual Studio 2010 (Windows)
- Code::Blocks (Linux/Ubuntu)
5. There are plenty of resources about C++ on Net, but
honestly just a small fraction of them is really good.
My recommendations:
- http://www.parashift.com/c++-faq
- http://www.isocpp.org/
- http://www.stroustrup.com
- The Videos on Microsoft Channel 9
by Stephan T. Lavavej about C++ standard library
Don't forget the comp.lang.c++ and Stack Overflow
(http://stackoverflow.com) are good places to ask question.
Welcome to C++ community with 3,500,000+ members.

Regards,
-- Saeed Amrollahi Boyouki

[Juha Nieminen]

eli m <techg...@gmail.com> wrote:
> I am coming to C++ from python. Do you guys have any tips for me?
> Examples: How to learn it effectively, what not to do, etc.

No pun intended, but there's actually a book called "Effetive C++",
which is actually quite good. It's not a total beginner's book, as it
assumes that you have at least some knowledge of C++ already, but I would
say that you can actually learn quite a lot on-the-fly while reading the
book and finding out what it's talking about. Probably better than by
reading some beginner's book. (What makes this a better way of learning,
IMO, is that it goes right to the good stuff, rather than spending
hundreds of pages on trivialities and teaching bad habits, like most
beginners' books do.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Öö Tiib]

On Wednesday, 6 March 2013 03:56:40 UTC+2, eli m wrote:
> I am coming to C++ from python. Do you guys have any tips for me?

I can give some such tips just to get into feeling. ;)

0) Skim C++ FAQ first and return to it now and then. It is over 20 years
old FAQ, actively updated and most interesting things about C++ are
mentioned in it. http://www.parashift.com/c++-faq/
Do not take it as holy bible. The answers it gives are most popular
for a practical reasons.

1) Learning C++ by trial and error is impossible. Reasons:
* C++ syntax is designed to be laconic. Random row of ASCII characters
does not compile, but getting it to compile with tiny changes is
possible.
* Lot of C++ code that compiles without any compiling errors is illegal
but compiler messages are not required from implementation.
* Lot of C++ code that runs is not defined what it should do but it may
sometimes look that it does exactly what you expect it to do.
* Above is true about usage of standard C++ library as well. It is
library that sometimes has documented that something is undefined but
sometimes the docs just do not say what happens in certain situations.

2) There are only few books that the masters of C++ accept as good. Take
the code examples in those as illustration of particular feature the
paragraph describes. Nothing else. Illustrations are often not meant
to work in real product.

3) Debugging C++ program without special tools is very hard. As one of the
first things learn to use tools that help you to debug the programs you
write.

4) When you write program then do not take over the "undefined" nature of
C++ and its library. Try to write programs where everything what
happens is defined by using only the constructs of C++ that have
defined behavior.

5) Do not expect to learn C++ quickly. If you are bright guy then you will
feel yourself familiar with it in 6 months. Some never learn it despite
they try.

6) Do not hope that C++ code you see in some place of internet is good.
On the contrary, it is usually bad or even terrible.

7) Do not hope that C++ code you may see in C++ library implementation is
good.
* It may contain obscure and illegal constructs that do not work even on
next version of same compiler.
* It will contain names reserved for usage internally in implementations.
* It may contain undefined behaviors that standard allows it to contain.
* It is designed to be efficient on particular compiler and not readable.

[Jorgen Grahn]

On Wed, 2013-03-06, Saeed Amrollahi wrote:
> On Wednesday, March 6, 2013 5:26:40 AM UTC+3:30, eli m wrote:

>> I am coming to C++ from python. Do you guys have any tips [...] ?

>
> Hi
> 1. At first you should understand the common property
> between C++ and Python is both are programming languages, period.

Yes! Python is a nice language, but knowing it doesn't help you write
C++ code. (Also, trying to write Python in C++ is a bad idea.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[James Kanze]

On Wednesday, March 6, 2013 7:27:51 AM UTC, Saeed Amrollahi wrote:
> On Wednesday, March 6, 2013 5:26:40 AM UTC+3:30, eli m wrote:

> > I am coming to C++ from python. Do you guys have any tips
> > for me? Examples: How to learn it effectively, what not to
> > do, etc.

[...]

> 2. You should never learn "Modern" C++ with a book that was written before
> 1997. My recommendations:
> 1) Andrew Koenig & Barbara Moo. Accelerated C++, Addison-Wesley, 2000.
> 2) Bjarne Stroustrup. Programming: Principles and Practice in C++,
> Addison-Wesley, 2009.
> 3) Bjarne Stroustrup. The C++ Programming Language, Addison-Wesley,
> 2013. (Coming soon)
> 4) Stanley Lippman, Josee Lajoie & Barbara Moo. C++ Primer, 2012.
> 5) Bjarne Stroustrup. The C++ Programming Language, Addison-Wesley,
> special edition, 2000.
> At this time, the point is: use C++98 or C++11, the books
> 1, 2 and 5 are based on C++98 and 3 and 4 based on C++11.
> of course there other good books. I believe the book #1 and #2
> are really good. #1 is concise and #2 is very detailed about
> programming not C++.

The choice between 1 and 2 will depend partially on how much
experience you have programming, in general. If you know no
programming, I would recommend 2, regardless of what language
you ultimately want to program in, because that's what it
teaches. If you're already an experienced programmer, 1 is
a lot shorter, and will still present everything you need to
know that isn't general programming skills.

[...]

> 4. Use modern C++ programming environment.
> My recommendation:
> - Visual Studio 2012, Visual Studio 2010 (Windows)
> - Code::Blocks (Linux/Ubuntu)

I don't know. I use Visual Studios 2012 (at present) under
Windows, because that's my employers standard; I've always used
vim, bash and makefiles under Unix. And the vim, bash and
makefiles environment is far more productive than the Visual
Studios environment. If you're just starting programming,
something like Visual Studios is probably a pretty good idea, so
you don't have to learn everything at once, just to compile
hello world. But if you are already an experienced programmer,
it's probably worth your while to learn how to use more powerful
tools; there's just so much you can't do in Visual Studios (or
in any of the IDE's I've used under Linux, but I've not tried
any new ones recently).

--
James

[James Kanze]

That's "Effective C++", by Scott Meyers, and it depends on what
beginners book, but I would suggest the more recent Stroustrup
or the Koenig and Moo first. But I don't think you should
consider yourself qualified to actually develop applications in
C++ until you've also mastered "Effective C++".

--
James

[Balog Pal]

On 3/6/2013 6:25 PM, James Kanze wrote:
> I don't know. I use Visual Studios 2012 (at present) under
> Windows, because that's my employers standard; I've always used
> vim, bash and makefiles under Unix. And the vim, bash and
> makefiles environment is far more productive than the Visual
> Studios environment.

Could you elaborate please? What makes the listed things more
productive? (Or did you meant it for yourself only based on familiar
ground, not in general?)

> But if you are already an experienced programmer,
> it's probably worth your while to learn how to use more powerful
> tools; there's just so much you can't do in Visual Studios (or
> in any of the IDE's

Like what?

[Jorgen Grahn]

On Thu, 2013-03-07, Balog Pal wrote:
> On 3/6/2013 6:25 PM, James Kanze wrote:
>> I don't know. I use Visual Studios 2012 (at present) under
>> Windows, because that's my employers standard; I've always used
>> vim, bash and makefiles under Unix. And the vim, bash and
>> makefiles environment is far more productive than the Visual
>> Studios environment.
>
> Could you elaborate please? What makes the listed things more
> productive? (Or did you meant it for yourself only based on familiar
> ground, not in general?)

Hopefully he did, or I'd have to start an Emacs-vs-Vim war ;-)

Unix versus (other) IDEs has been discussed continuously for as long
as I can remember, and it never leads anywhere. It's near impossible
to find someone who knows both worlds well enough to have a useful
general opinion, and if such a person exists she can't prove it to us.

Personally: my workflow combined with a decent Unix environment
doesn't feel limiting. And I don't think it's because my brain is
wired in an unusual way. Can I switch to an IDE and change my
workflow to become even /less/ limited? No idea; it would take years
to find out, and I'm not prepared to make that huge investment with
an uncertain outcome.

Also, I've never seen anyone do anything with an IDE that I couldn't
do as well or better. (That's not proof, because most people seem not
to use their tools efficiently at all, no matter what the tools are.)

[Juha Nieminen]

Balog Pal <pa...@lib.hu> wrote:
> On 3/6/2013 6:25 PM, James Kanze wrote:
>> I don't know. I use Visual Studios 2012 (at present) under
>> Windows, because that's my employers standard; I've always used
>> vim, bash and makefiles under Unix. And the vim, bash and
>> makefiles environment is far more productive than the Visual
>> Studios environment.
>
> Could you elaborate please? What makes the listed things more
> productive? (Or did you meant it for yourself only based on familiar
> ground, not in general?)

One thing about Unix, especially modern Linux distros, is that it has
been kind of designed for development, unlike Windows, which has been
designed as a graphical user interface, with little regard to anything
else.

I like in Linux, for example, that if I need a common third-party
library that's not already in my system, I can install it with a couple
of mouse clicks (or, alternatively, with a shell command), and it becomes
immediately available to my program. I don't need to search it, manually
download it, configure it, install it, tell the compiler where to find
it... A couple of mouse clicks, and that's it.

(To be fair, it's not the case with every single library in existence.
Only with those that can be found in one of the distro's repositories.
However, the vast majority of common libraries tend to be there.)

[Ian Collins]

Juha Nieminen wrote:
> Balog Pal <pa...@lib.hu> wrote:
>> On 3/6/2013 6:25 PM, James Kanze wrote:
>>> I don't know. I use Visual Studios 2012 (at present) under
>>> Windows, because that's my employers standard; I've always used
>>> vim, bash and makefiles under Unix. And the vim, bash and
>>> makefiles environment is far more productive than the Visual
>>> Studios environment.
>>
>> Could you elaborate please? What makes the listed things more
>> productive? (Or did you meant it for yourself only based on familiar
>> ground, not in general?)
>
> One thing about Unix, especially modern Linux distros, is that it has
> been kind of designed for development, unlike Windows, which has been
> designed as a graphical user interface, with little regard to anything
> else.

That comment shouldn't be specific to Linux, most modern UNIX systems
are equally, if not more, developer friendly.

--
Ian Collins

[Ian Collins]

As I've posted elsewhere, over the past 30+ years I've used everything
from teletypes to the modern crop of cross-platform IDEs and these days
I do most of my work in NetBeans.

Why? Because it integrates well with the other tools I use and supports
all of my programming languages. It also has built in support for the
C, C++ and PHP unit test frameworks I use. I've even started to like
the background compilation feature, which saves on wasted build time.

If someone sat me down at any of my past setups, I'd still be productive
(well maybe not too productive on the 110baud teletype!), just not as
productive as I am now.

--
Ian Collins

[Öö Tiib]

On Thursday, 7 March 2013 10:48:58 UTC+2, Ian Collins wrote:
> I do most of my work in NetBeans.

+1. Only few things that I haven't found well-integrated into it like
issue-management system and review board.

[Jorgen Grahn]

On Thu, 2013-03-07, Ian Collins wrote:
> Juha Nieminen wrote:
...

>> One thing about Unix, especially modern Linux distros, is that it has
>> been kind of designed for development, unlike Windows, which has been
>> designed as a graphical user interface, with little regard to anything
>> else.
>
> That comment shouldn't be specific to Linux, most modern UNIX systems
> are equally, if not more, developer friendly.

Apart from the *BSDs, not in the sense that JN meant. Are there
really any left, anyway?

[James Kanze]

On Thursday, 7 March 2013 18:22:14 UTC, Jorgen Grahn wrote:
> On Thu, 2013-03-07, Ian Collins wrote:

> > Juha Nieminen wrote:

> ...

> >> One thing about Unix, especially modern Linux distros, is that it has
> >> been kind of designed for development, unlike Windows, which has been
> >> designed as a graphical user interface, with little regard to anything
> >> else.

> > That comment shouldn't be specific to Linux, most modern UNIX systems
> > are equally, if not more, developer friendly.

> Apart from the *BSDs, not in the sense that JN meant. Are there
> really any left, anyway?

Solaris is still around. I think AIX is too.

--
James

[Ian Collins]

Jorgen Grahn wrote:
> On Thu, 2013-03-07, Ian Collins wrote:
>> Juha Nieminen wrote:

> ....

>>> One thing about Unix, especially modern Linux distros, is that it has
>>> been kind of designed for development, unlike Windows, which has been
>>> designed as a graphical user interface, with little regard to anything
>>> else.
>>
>> That comment shouldn't be specific to Linux, most modern UNIX systems
>> are equally, if not more, developer friendly.
>
> Apart from the *BSDs, not in the sense that JN meant. Are there
> really any left, anyway?

In my opinion Solaris (and the numerous OpenSolaris derivatives) have
better developer tools than Linux, especially for analysing applications
(and the OS) in a production0n environment.

--
Ian Collins

[Balog Pal]

On 3/7/2013 9:10 AM, Jorgen Grahn wrote:
> Unix versus (other) IDEs has been discussed continuously for as long
> as I can remember, and it never leads anywhere.

I don't agree with that -- I was in several such discussions and learnt
about a plenty of tools and methods I overlooked or was too skeptic to
try harder. Guess I'm not alone with that.

Also I saw many false claims shot down.

> It's near impossible
> to find someone who knows both worlds well enough to have a useful
> general opinion, and if such a person exists she can't prove it to us.

The point is IMO not switching environment right ahead (that is normally
hindered by many factors) bu to converge to a more productive work in
time. (I.e currently I work on windows again, but last times I worked on
linux I always looked around to find some productive environment - just
to get disappointed again and again. Maybe the next time I'm there it
will change due to people answer my questions. ;)

> Personally: my workflow combined with a decent Unix environment
> doesn't feel limiting. And I don't think it's because my brain is
> wired in an unusual way. Can I switch to an IDE and change my
> workflow to become even /less/ limited? No idea; it would take years
> to find out, and I'm not prepared to make that huge investment with
> an uncertain outcome.

I don't get this -- just because I launched an IDE or a multiwindow
smart text editor never stoppped me to run a few terminals, command
lines, tools, whatever if I needed them. I do prefer them being
integrated, but if the integration is handicapped I rather use the
external thing. Or go out for advanced tasks. (As an example: we have a
Git Provider plugin that integrates into VS and is in theory great:
shows status on the solution tree, pending differences with source code
navigation, even an interface channel to access GE and tortoise. But in
practice it uses an old and bad access engine to git (at least it was
the case a year ago) that slows down everything having a big project;
also hashas a tendency to lock git stuff from other tools. So I rather
uninstalled it and just use gitk and git gui in other windows, and
launch GitExtenions time to time, while also run git commands from FAR
manager, and even have a python tool that autmates refreshing the
satellite repos.) If the issue will be fixed eventually, or another
integration emerges, I'll add it to the mix and use less of the
externals, the least used dropping out naturally.

> Also, I've never seen anyone do anything with an IDE that I couldn't
> do as well or better.

IDE is not supposed to be a silver bullet, but to save time wasted on
switching tools and views. I just HATE to see some piece of info on the
screen ad being forced to select, copy, paste it to some other place,
enriched with some commands instead of being able to just do it on spot.
And in work I have a ton of such activity.

> (That's not proof, because most people seem not
> to use their tools efficiently at all, no matter what the tools are.)

Yeah, Iwas pretty shocked to observe that with all those supposedly
excellent unix-based tools my colleagues (who were linux guru level)
could not do as much as walking a list of compiler errors with F4 --
instead had to do actions to open the related sources and navigate to
lines. :-((( I thought we left that behind in last century.

And guess we agree that being one pretty frequent activity.

[Jorgen Grahn]

On Fri, 2013-03-08, Balog Pal wrote:
> On 3/7/2013 9:10 AM, Jorgen Grahn wrote:

...

>> Also, I've never seen anyone do anything with an IDE that I couldn't
>> do as well or better.
>
> IDE is not supposed to be a silver bullet, but to save time wasted on
> switching tools and views.

The above was just a statement about what I've seen -- not
a statement about what IDEs are good for.

> I just HATE to see some piece of info on the
> screen ad being forced to select, copy, paste it to some other place,
> enriched with some commands instead of being able to just do it on spot.
> And in work I have a ton of such activity.

The counter-argument: when I do stuff in a shell I can use any tools I
want, not just the ones the IDE maker thought of. And I can write my
own. I also use the shell history and its search functions (e.g.
Ctrl-R in bash) a lot, so I never have to type the same thing twice.

>> (That's not proof, because most people seem not
>> to use their tools efficiently at all, no matter what the tools are.)
>
> Yeah, Iwas pretty shocked to observe that with all those supposedly
> excellent unix-based tools my colleagues (who were linux guru level)
> could not do as much as walking a list of compiler errors with F4 --
> instead had to do actions to open the related sources and navigate to
> lines. :-((( I thought we left that behind in last century.

Linux "gurus" know that Emacs does this by default. Either they
felt this was unimportant to them, or they were just wannabes.

To me, that shows how hard it is to discuss this. You are shocked by
that, but I on the other hand don't feel a need for such a tool. I
just look at the first few errors, or the one I know is the core one,
and recompile[1].

You can't look at the tool without taking the /workflow/ into account.

/Jorgen

[1] Compilation must be fast, correct and free from noise for this to
work.

[Balog Pal]

On 3/8/2013 2:40 PM, Jorgen Grahn wrote:
> On Fri, 2013-03-08, Balog Pal wrote:
>> On 3/7/2013 9:10 AM, Jorgen Grahn wrote:

> ....

>>> Also, I've never seen anyone do anything with an IDE that I couldn't
>>> do as well or better.
>>
>> IDE is not supposed to be a silver bullet, but to save time wasted on
>> switching tools and views.
>
> The above was just a statement about what I've seen -- not
> a statement about what IDEs are good for.
>
>> I just HATE to see some piece of info on the
>> screen ad being forced to select, copy, paste it to some other place,
>> enriched with some commands instead of being able to just do it on spot.
>> And in work I have a ton of such activity.
>
> The counter-argument: when I do stuff in a shell I can use any tools I
> want, not just the ones the IDE maker thought of. And I can write my
> own.

Err, I honestly don't see any difference here if we consider IDEs from
real life. I'm not aware of a single one without capability to launch
external commands, record macros, write programs in a full-potential
language with access to anything your OS+ provides, and even if that is
not enough provide extensibility API so you can write your thing "the
provider didn't think about as a plugin. (Or better yet use the plugin
the other guy wrote to cover that topic. ;-)

> I also use the shell history and its search functions (e.g.
> Ctrl-R in bash) a lot, so I never have to type the same thing twice.

Keeping history of anything is probably the first thing any IDE (or GUI
program) learned.

And as I already said, nothing forbids to have a bash running to
supplement the IDE. While the other way around does not work.

>>> (That's not proof, because most people seem not
>>> to use their tools efficiently at all, no matter what the tools are.)
>>
>> Yeah, Iwas pretty shocked to observe that with all those supposedly
>> excellent unix-based tools my colleagues (who were linux guru level)
>> could not do as much as walking a list of compiler errors with F4 --
>> instead had to do actions to open the related sources and navigate to
>> lines. :-((( I thought we left that behind in last century.
>
> Linux "gurus" know that Emacs does this by default. Either they
> felt this was unimportant to them, or they were just wannabes.

I saw only a single guy using Emacs and only part-time. The others were
certainly aware of it and that feature.

OTOH, Emacs, integrated with build system this way is a manifestation of
IDE, so arguments for its usability plays for that team in the
IDE/just-editor matches. :)

> To me, that shows how hard it is to discuss this. You are shocked by
> that, but I on the other hand don't feel a need for such a tool. I
> just look at the first few errors, or the one I know is the core one,
> and recompile[1].

I several times considered to use a stopper to measure time wasted this
way. Didn't do it for laziness and thinking social issues. But I read
some cool articles with similar measurements -- that revealed
interesting things. Among them that some activities are completely
missing from people's "subjective" time, and typing commands normally
play there. IOW the waste is well observable from outside only.

> You can't look at the tool without taking the /workflow/ into account.
>

> [1] Compilation must be fast, correct and free from noise for this to
> work.

It probably fits some workflow when you concentrate on a few-line
change. I'm currently reshaping an old codebase that's over 1MLOC in
size. Would be dead in the water if could not navigate error or search
locations at once anywhere in the ~3300 files.

But even at the smallest scale I never got the idea what is good to type
(or even fetch from history) a filename in the project to open it manually.

[Jorgen Grahn]

On Fri, 2013-03-08, Balog Pal wrote:
> On 3/8/2013 2:40 PM, Jorgen Grahn wrote:
>> On Fri, 2013-03-08, Balog Pal wrote:

...

>> To me, that shows how hard it is to discuss this. You are shocked by
>> that, but I on the other hand don't feel a need for such a tool. I
>> just look at the first few errors, or the one I know is the core one,
>> and recompile[1].

...

> It probably fits some workflow when you concentrate on a few-line
> change. I'm currently reshaping an old codebase that's over 1MLOC in
> size. Would be dead in the water if could not navigate error

I do these tasks too, and I can assure you am not dead in the water!

> or search
> locations at once anywhere in the ~3300 files.

Did I say I couldn't do that? I don't use IDEs, but I don't write my
code in Notepad, either! This is a vital feature.

> But even at the smallest scale I never got the idea what is good to type
> (or even fetch from history) a filename in the project to open it manually.

Ok, back to my original comment about the futility of these discussions.
You don't trust me, and I don't trust you. Neither of us is going to
change.

/Jorgen

[Scott Lurndal]

Balog Pal <pa...@lib.hu> writes:
>On 3/8/2013 2:40 PM, Jorgen Grahn wrote:

>> I also use the shell history and its search functions (e.g.
>> Ctrl-R in bash) a lot, so I never have to type the same thing twice.
>
>Keeping history of anything is probably the first thing any IDE (or GUI
>program) learned.
>
>And as I already said, nothing forbids to have a bash running to
>supplement the IDE. While the other way around does not work.

Why not? This seems to be perfectly symmetric.

>
>>>> (That's not proof, because most people seem not
>>>> to use their tools efficiently at all, no matter what the tools are.)
>>>
>>> Yeah, Iwas pretty shocked to observe that with all those supposedly
>>> excellent unix-based tools my colleagues (who were linux guru level)
>>> could not do as much as walking a list of compiler errors with F4 --
>>> instead had to do actions to open the related sources and navigate to
>>> lines. :-((( I thought we left that behind in last century.
>>
>> Linux "gurus" know that Emacs does this by default. Either they
>> felt this was unimportant to them, or they were just wannabes.
>
>I saw only a single guy using Emacs and only part-time. The others were
>certainly aware of it and that feature.

even [g]vim supports this "feature", although my compiles never have
syntax errors (:-) for the humor impaired).

For example:

http://www.vim.org/scripts/script.php?script_id=1861
http://vim.wikia.com/wiki/Use_the_quickfix_window_to_list_all_errors

vim also integrates cscope directly, as well as ctags.

I suppose that makes vim an IDE of sorts.

The advantage of the unix tools over an integrated IDE is that you can
use the editor you like, the cross-reference tools you like and everything
is in a separate window. One can also do development over a low-bandwidth
link (e.g. secure shell) effectively, whereas any GUI-based IDE will
suck rocks.

I've no desire, after 30 years of using vi(m), to learn a new editor,
nor do I wish to take my hands from the keyboard and touch the mouse
if it can be avoided (hence focus-follows-mouse rather than click-to-focus
and no-autoraise-with-focus are key tunables in a usable window manager).

>
>OTOH, Emacs, integrated with build system this way is a manifestation of
>IDE, so arguments for its usability plays for that team in the
>IDE/just-editor matches. :)

Except emacs doesn't require a GUI, window manager or display, simply
a 'terminal window', which then allows efficient remote access.

>
>> To me, that shows how hard it is to discuss this. You are shocked by
>> that, but I on the other hand don't feel a need for such a tool. I
>> just look at the first few errors, or the one I know is the core one,
>> and recompile[1].
>
>I several times considered to use a stopper to measure time wasted this
>way. Didn't do it for laziness and thinking social issues. But I read
>some cool articles with similar measurements -- that revealed
>interesting things. Among them that some activities are completely
>missing from people's "subjective" time, and typing commands normally
>play there. IOW the waste is well observable from outside only.
>
>> You can't look at the tool without taking the /workflow/ into account.
>>
>> [1] Compilation must be fast, correct and free from noise for this to
>> work.
>
>It probably fits some workflow when you concentrate on a few-line
>change. I'm currently reshaping an old codebase that's over 1MLOC in
>size. Would be dead in the water if could not navigate error or search
>locations at once anywhere in the ~3300 files.

cscope + [g]vim. Or ctags + [g]vim.

YMMV.

scott

[Paavo Helde]

Balog Pal <pa...@lib.hu> wrote in news:khdhim$c8l$1...@news.ett.com.ua:

> On 3/8/2013 2:40 PM, Jorgen Grahn wrote:
>> On Fri, 2013-03-08, Balog Pal wrote:
>>> On 3/7/2013 9:10 AM, Jorgen Grahn wrote:
>> ....
>>>> Also, I've never seen anyone do anything with an IDE that I
>>>> couldn't do as well or better.
>>>
>>> IDE is not supposed to be a silver bullet, but to save time wasted
>>> on switching tools and views.

Switching views in a non-IDE is Alt-Tab or equivalent, but I have not yet
found convenient ways to switch views inside an IDE without reaching to
the mouse.

>> I also use the shell history and its search functions (e.g.
>> Ctrl-R in bash) a lot, so I never have to type the same thing twice.
>
> Keeping history of anything is probably the first thing any IDE (or
> GUI program) learned.

The history of debug launch commands with different command-line
arguments is still missing in my primary IDE, after 10+ years. I have
resorted to starting the program from the bash command-line, then
attaching the debugger, but this is cumbersome as well.

>
> And as I already said, nothing forbids to have a bash running to
> supplement the IDE. While the other way around does not work.

+1 for that, having multiple CygWin bash shells running all the time. But
I would not be so sure which one is primary and which is supplement.

>>>> (That's not proof, because most people seem not
>>>> to use their tools efficiently at all, no matter what the tools
>>>> are.)
>>>
>>> Yeah, Iwas pretty shocked to observe that with all those supposedly
>>> excellent unix-based tools my colleagues (who were linux guru level)
>>> could not do as much as walking a list of compiler errors with F4 --
>>> instead had to do actions to open the related sources and navigate
>>> to lines. :-((( I thought we left that behind in last century.

Ironically, this is the only reason I launch our chosen Linux IDE
(CodeBlocks, and I did not choose it) - the only thing which it is good
at is navigating to errors (editing sucks, debugging does not work at
all, compile without attempted recompile of earlier dependencies not
possible, find-in-project-files missing, recently edited windows list
missing (i.e. Alt-W-2 not working), etc.), so the only use is actually to
fix some random compilation errors time after time (usually caused by so-
called "MS language extensions" compiling fine on Windows and failing on
Linux).

Cheers
Paavo

[Balog Pal]

On 3/8/2013 11:38 PM, Paavo Helde wrote:
> Balog Pal <pa...@lib.hu> wrote in news:khdhim$c8l$1...@news.ett.com.ua:
>

> Switching views in a non-IDE is Alt-Tab or equivalent, but I have not yet
> found convenient ways to switch views inside an IDE without reaching to
> the mouse.

In VS you can bind any key to any command -- built-in or written by you.
Can be even dependent on what kind of document you're in. I'm not sure
if you can re-bind system-wide stuff like alt-tab, I never wanted, as it
is there to switch to outside windows. (I recall how annoying it was
when I worked with virtual machines and alt-tab switched windows inside
the VM when I wanted the next natural desktop window :)

>>> I also use the shell history and its search functions (e.g.
>>> Ctrl-R in bash) a lot, so I never have to type the same thing twice.
>>
>> Keeping history of anything is probably the first thing any IDE (or
>> GUI program) learned.
>
> The history of debug launch commands with different command-line
> arguments is still missing in my primary IDE

Indeed, though if you have a just a number of variants, in VS you can
add projects that has no content just the debug setting. Then can launch
any easily. Probably it can be covered by a macro too. I have only a few
variants so never bothered with better way.

>, after 10+ years. I have
> resorted to starting the program from the bash command-line, then
> attaching the debugger, but this is cumbersome as well.

From command line you can launch gdb or ddd providing the full command
line for the of the program, so it should not be really more hassle.

>> And as I already said, nothing forbids to have a bash running to
>> supplement the IDE. While the other way around does not work.
>
> +1 for that, having multiple CygWin bash shells running all the time. But
> I would not be so sure which one is primary and which is supplement.

Shouldn't matter -- the point is to have everything at fingertip so
activity is used on new work rather than retype incantations or info the
system really knows.

>>>>> (That's not proof, because most people seem not
>>>>> to use their tools efficiently at all, no matter what the tools
>>>>> are.)
>>>>
>>>> Yeah, Iwas pretty shocked to observe that with all those supposedly
>>>> excellent unix-based tools my colleagues (who were linux guru level)
>>>> could not do as much as walking a list of compiler errors with F4 --
>>>> instead had to do actions to open the related sources and navigate
>>>> to lines. :-((( I thought we left that behind in last century.
>
> Ironically, this is the only reason I launch our chosen Linux IDE
> (CodeBlocks, and I did not choose it) - the only thing which it is good
> at is navigating to errors (editing sucks, debugging does not work at
> all, compile without attempted recompile of earlier dependencies not
> possible, find-in-project-files missing, recently edited windows list
> missing (i.e. Alt-W-2 not working), etc.), so the only use is actually to
> fix some random compilation errors time after time (usually caused by so-
> called "MS language extensions" compiling fine on Windows and failing on
> Linux).

A few years ago someone suggested CB, I dropped it after very little try
as hopeless. Too bad, as it looks like something used up much
development time, so could be useful.

I recall my early years -- Borland C++ 3.1 IDE just rocked. Had
practically everything I could imagined at the time, and so many
successors were much bigger but didn't come even close.

[Balog Pal]

On 3/8/2013 9:53 PM, Jorgen Grahn wrote:

> Ok, back to my original comment about the futility of these discussions.
> You don't trust me, and I don't trust you. Neither of us is going to
> change.

You missed the point despite I even described it in an earlier post.
It's not a pissing or dick-measuring contest.

And I'm still interested in *how* you do the wasteless navigation --
can you tell us or it's a top secret?

[Robert Wessel]

On Fri, 08 Mar 2013 16:38:43 -0600, Paavo Helde
<myfir...@osa.pri.ee> wrote:

>Balog Pal <pa...@lib.hu> wrote in news:khdhim$c8l$1...@news.ett.com.ua:
>
>> On 3/8/2013 2:40 PM, Jorgen Grahn wrote:
>>> On Fri, 2013-03-08, Balog Pal wrote:
>>>> On 3/7/2013 9:10 AM, Jorgen Grahn wrote:
>>> ....
>>>>> Also, I've never seen anyone do anything with an IDE that I
>>>>> couldn't do as well or better.
>>>>
>>>> IDE is not supposed to be a silver bullet, but to save time wasted
>>>> on switching tools and views.
>
>Switching views in a non-IDE is Alt-Tab or equivalent, but I have not yet
>found convenient ways to switch views inside an IDE without reaching to
>the mouse.

In VS, for example, you can ctrl-tab, hold down the control key, and
then navigate to whatever active file and/or window you want with the
arrow keys. Just ctrl-tab wanders through the active open files.

[Paavo Helde]

Robert Wessel <robert...@yahoo.com> wrote in
news:6kelj8p1j6c4v6sep...@4ax.com:

Thanks for the tip, it has not occured to me to use arrow keys in the
ctrl-tab list though I have seen it occasionally (for navigating through
the open files I am using Alt-W digit or Alt-W W instead).

Now the next step would be to get the arrow keys working in the Alt-Tab
list as well...

Cheers
Paavo

[Balog Pal]

On 3/9/2013 9:48 AM, Paavo Helde wrote:
>>> Switching views in a non-IDE is Alt-Tab or equivalent, but I have not
>>> yet found convenient ways to switch views inside an IDE without
>>> reaching to the mouse.
>>
>>
>> In VS, for example, you can ctrl-tab, hold down the control key, and
>> then navigate to whatever active file and/or window you want with the
>> arrow keys. Just ctrl-tab wanders through the active open files.
>
> Thanks for the tip, it has not occured to me to use arrow keys in the
> ctrl-tab list though I have seen it occasionally (for navigating through
> the open files I am using Alt-W digit or Alt-W W instead).
>
> Now the next step would be to get the arrow keys working in the Alt-Tab
> list as well...

The other navigation feature I use very much is Alt-minus to go to
previous spot(s) (and forward with shift). That is something I doubt
single-window editors could hope to get.

I find it useful despite having a plenty of ways to have information
without leaving the edited spot (like tooltips, code definition window).

In the workflow of doing review -- either interactively or just
inspecting patches all the navigation support is also critical to
productivity IME. Not only affecting the raw time but precision. A
feature that shows documentation of a function by just hovering the
mouse over it can save overlooking some precondition or responsibility.

[Nick Keighley]

On Mar 6, 1:56 am, eli m <techgeek...@gmail.com> wrote:

> I am coming to C++ from python. Do you guys have any tips for me? Examples: How to learn it effectively, what not to do, etc.

"Accelerated C++" might suit you. It tends to start with the powerful
high level stuff and only grubs around with pointers and such like
later on.

I liked the original Stroustrup (ToC could be better!) and he's now
written a book for beginners (no idea what its like).

I like the Effective books but again I'm a bit out of date on where
these are now.

I can't function without Josuttis on the standard library, but you may
be able to replace it with some of the better online stuff.

Oh and read the comp.lang.c++ FAQ (ignore his rants about "business
value")

Write Lots Of Code.


Happy programming!

[Nick Keighley]

really? I've used both (well not vim). I've also used Qt Creator. I'd
like to see how you measure "productivity"

> If you're just starting programming,
> something like Visual Studios is probably a pretty good idea, so
> you don't have to learn everything at once, just to compile
> hello world.

even compiling hello world is non-trivial with VS!

> But if you are already an experienced programmer,
> it's probably worth your while to learn how to use more powerful
> tools; there's just so much you can't do in Visual Studios (or
> in any of the IDE's I've used under Linux, but I've not tried
> any new ones recently).

like? If I want to process text I use Perl and tend to use it as a
scripting language as well (bash syntax drives me nuts) but VS seems
fine for most stuff.

[woodb...@gmail.com]

On Friday, March 8, 2013 8:01:51 AM UTC, Ian Collins wrote:
>
> In my opinion Solaris (and the numerous OpenSolaris derivatives) have
>
> better developer tools than Linux, especially for analysing applications
>
> (and the OS) in a production0n environment.
>

I'm thinking about OpenSolaris again. Currently my Linux
server forks several copies of itself and the children
do an accept on the same socket. IIrc, that doesn't work
on Solaris. If that's right, what's the alternative on
Solaris?

I'm using Arch Linux right now and like it for the
most part. It seems easier to administer than the
version of Linux I was using previously. I haven't
used Solaris in a number of years, so am not sure
how the administration of Solaris compares with Linux.
Solaris might be right for me at some point, but am
not sure if that time is yet.

Brian

[Paavo Helde]

woodb...@gmail.com wrote in
news:89c70517-389d-43fd...@googlegroups.com:

> On Friday, March 8, 2013 8:01:51 AM UTC, Ian Collins wrote:
>>
>> In my opinion Solaris (and the numerous OpenSolaris derivatives) have
>>
>> better developer tools than Linux, especially for analysing
>> applications
>>
>> (and the OS) in a production0n environment.
>>
>
> I'm thinking about OpenSolaris again. Currently my Linux
> server forks several copies of itself and the children
> do an accept on the same socket. IIrc, that doesn't work
> on Solaris. If that's right, what's the alternative on
> Solaris?

Are you implying that some fundamental OS-level feature is missing on
Solaris, making this platform unusable for some purposes? That's kind of
hard to believe.

For the socket reuse problem: is it really about socket reuse or port
reuse? For port reuse, setsockopt(SO_REUSEADDR, ...) before bind() might
do the trick. Disclaimer: I have no experience with Solaris.

Cheers
Paavo

[Nick Keighley]

I tend to find GUIs slicker at what they're designed to do and fail
miserably when you want to do something different. Unix GUIs are
getting
better but still seem a little clunky compared with windows (I've no
modern experience of Macs (apart from trying to display a few photos
on
one and finding it a nightmare!)). Unix shells are nasty until you
try
and get anything done on windows when you realise how great they are!
Hence my choice of Perl as a scripting language. Its systax slightly
less shit than other shells and its sort of portable.

I suppose the ultimate would be a GUI with a scripting language (yes
I've heard of emacs), I understand Macs have something like this and
I've
used tools that tried to do this (Rational Rose, Understand) but
never
really grokked them.

[Jorgen Grahn]

On Fri, 2013-03-08, Balog Pal wrote:

> On 3/8/2013 9:53 PM, Jorgen Grahn wrote:
>
>> Ok, back to my original comment about the futility of these discussions.
>> You don't trust me, and I don't trust you. Neither of us is going to
>> change.
>
> You missed the point despite I even described it in an earlier post.
> It's not a pissing or dick-measuring contest.

It feels a lot like one ... and this will be my last posting in this
part of the thread.

> And I'm still interested in *how* you do the wasteless navigation --
> can you tell us or it's a top secret?

I didn't understand you were asking a question. Do you mean this from
upthread?

|> It probably fits some workflow when you concentrate on a few-line
|> change. I'm currently reshaping an old codebase that's over 1MLOC in
|> size. Would be dead in the water if could not navigate error
|
|I do these tasks too, and I can assure you am not dead in the water!
|
|> or search
|> locations at once anywhere in the ~3300 files.
|
|Did I say I couldn't do that? I don't use IDEs, but I don't write my
|code in Notepad, either! This is a vital feature.

The last thing I assumed was obvious: tags. AIUI the first text
editor feature to target programmers -- it was supported in vi
back around 1980.

If you're asking about the larger "reshaping a large codebase" part, I
have no short, specific answer. I use a mix of techniques and
standard tools.

[woodb...@gmail.com]

On Sunday, March 10, 2013 7:48:02 AM UTC, Paavo Helde wrote:
>
> Are you implying that some fundamental OS-level feature is missing on
>
> Solaris, making this platform unusable for some purposes? That's kind of
>
> hard to believe.
>

I was unsure if I could find the link again but did
find it with https://duckduckgo.com
.

http://plumeria.vmth.ucdavis.edu/info/oreilly/perl/cookbook/ch17_13.htm

That says, "On some operating systems, notably Solaris, you cannot have multiple children doing an accept on the same socket. You have to use file locking to ensure that only one child can call accept at any particular moment."

Is that still the case with Solaris 11?


Brian
Ebenezer Enterprises - Proverbs 3:5,6.
http://webEbenezer.net

[James Kanze]

On Friday, 8 March 2013 10:25:50 UTC, Balog Pal wrote:
> On 3/7/2013 9:10 AM, Jorgen Grahn wrote:

[...]
> Yeah, I was pretty shocked to observe that with all those supposedly

> excellent unix-based tools my colleagues (who were linux guru level)
> could not do as much as walking a list of compiler errors with F4 --
> instead had to do actions to open the related sources and navigate to
> lines. :-((( I thought we left that behind in last century.

That would shock me too, since I've been doing it under Unix
(and Windows) since over 20 years. (Of course, it's not F4, but
some other key sequence. But I'm assuming that that's not your
point.)

--
James

[James Kanze]

On Saturday, 9 March 2013 11:34:28 UTC, Nick Keighley wrote:
> On Mar 6, 5:25 pm, James Kanze <james.ka...@gmail.com> wrote:

[...]

> > I don't know.  I use Visual Studios 2012 (at present) under
> > Windows, because that's my employers standard; I've always used
> > vim, bash and makefiles under Unix.  And the vim, bash and
> > makefiles environment is far more productive than the Visual
> > Studios environment.

> really? I've used both (well not vim). I've also used Qt Creator. I'd
> like to see how you measure "productivity"

Getting working code out of the door. Actually, creating and
maintaining working code effectively, for a complete definition
of working code (i.e. maintainable, tested, documented...).

> > If you're just starting programming,
> > something like Visual Studios is probably a pretty good idea, so
> > you don't have to learn everything at once, just to compile
> > hello world.

> even compiling hello world is non-trivial with VS!

You mean because you have to create a solution, with a project?

For anything more complex, the fact that you don't have to
write a makefile is a win for a beginner.

For production code, of course, the fact that you can't really
create arbitrary rules, like you can in a makefile, is
a problem. As is sharing "projects" between different
solutions, which use different compiler options. I've done it,
but it involves editing the project files by hand; at that
point, you're better off using makefiles, because the higher
level makefile can pass explicit information down to the project
file. (With VC++, you have to create rules conditioned on the
solution name.)

> > But if you are already an experienced programmer,
> > it's probably worth your while to learn how to use more powerful
> > tools; there's just so much you can't do in Visual Studios (or
> > in any of the IDE's I've used under Linux, but I've not tried
> > any new ones recently).

> like?

If you limit yourself to the IDE, just about anything useful.
Try creating a project in which several different sources are
generated from other programs. There's special mechanism for
the case where a single source and header are generated by
a single tool (e.g. lex and yacc), and you can have one (but
only one) pre-build step. But the build system doesn't
understand any dependencies created by the pre-build, and if you
want two or more operations, you have to wrap them into some
sort of script. (The fact that the build system decides what
needs recompiling *before* doing the pre-build is a serious
error, since the purpose of the pre-build is normally to
regenerate some files.)

> If I want to process text I use Perl and tend to use it as a
> scripting language as well (bash syntax drives me nuts) but VS seems
> fine for most stuff.

Bash syntax is a bit special, but the real problem is that the
individual tools aren't always coherent. You need to learn
several different variations of regular expressions, for
example. It's still an order of magnitude better than Perl, but
I tend to use Python for anything non-trivial today (unless it's
non-trivial enough to justify using C++).

--
James

[Ian Collins]

James Kanze wrote:
> On Saturday, 9 March 2013 11:34:28 UTC, Nick Keighley wrote:
>> On Mar 6, 5:25 pm, James Kanze <james.ka...@gmail.com> wrote:
>
>>> But if you are already an experienced programmer,
>>> it's probably worth your while to learn how to use more powerful
>>> tools; there's just so much you can't do in Visual Studios (or
>>> in any of the IDE's I've used under Linux, but I've not tried
>>> any new ones recently).
>
>> like?
>
> If you limit yourself to the IDE, just about anything useful.
> Try creating a project in which several different sources are
> generated from other programs. There's special mechanism for
> the case where a single source and header are generated by
> a single tool (e.g. lex and yacc), and you can have one (but
> only one) pre-build step. But the build system doesn't
> understand any dependencies created by the pre-build, and if you
> want two or more operations, you have to wrap them into some
> sort of script. (The fact that the build system decides what
> needs recompiling *before* doing the pre-build is a serious
> error, since the purpose of the pre-build is normally to
> regenerate some files.)

One advantage of popular cross-platform IDE like Eclipse and NetBeans is
they do generate makefiles under the hood and (at least with NetBeans)
those makefiles are designed to support hand editing. The IDE generated
akefiles can also be use to run builds on remote hosts where running an
IDE is impractical.

--
Ian Collins

[Balog Pal]

On 3/13/2013 4:55 PM, James Kanze wrote:
> For production code, of course, the fact that you can't really
> create arbitrary rules, like you can in a makefile, is
> a problem. As is sharing "projects" between different
> solutions, which use different compiler options. I've done it,
> but it involves editing the project files by hand; at that
> point, you're better off using makefiles, because the higher
> level makefile can pass explicit information down to the project
> file. (With VC++, you have to create rules conditioned on the
> solution name.)

I wonder where this comes -- MS switched to MsBuild a few years ago, and
in that you can do about anything you could in a makefile. Yes, those
who mastered makefiles already may be better off with that. Others are
probably not, as for the sensible stuff it's ways simpler, and plays
naturally with the IDE.

Certainly you CAN and definitely should share most rules -- that is done
by creating .props and .targets files, and the .vcxproj should have only
the file lists. Certainly any really specific options can be set (either
per project or per file).

So all you write about is possible alright. I don't say it is trivial or
nice but that same applies to make and probably most other build systems
for big real-life projects.

> Bash syntax is a bit special, but the real problem is that the
> individual tools aren't always coherent. You need to learn
> several different variations of regular expressions, for
> example. It's still an order of magnitude better than Perl, but
> I tend to use Python for anything non-trivial today (unless it's
> non-trivial enough to justify using C++).

Yeah, me too -- IMO python beats why bother with old scripting stuff
when it provides all the power, is portable and reads like a real
language instead of emulating the old modem output before NO CARRIER. :->

[Ian Collins]

woodb...@gmail.com wrote:
> On Sunday, March 10, 2013 7:48:02 AM UTC, Paavo Helde wrote:
>>
>> Are you implying that some fundamental OS-level feature is missing
>> on
>>
>> Solaris, making this platform unusable for some purposes? That's
>> kind of
>>
>> hard to believe.
>>

Please wrap your lines!

> I was unsure if I could find the link again but did find it with

> https://duckduckgo.com ..

>
> http://plumeria.vmth.ucdavis.edu/info/oreilly/perl/cookbook/ch17_13.htm
>
> That says, "On some operating systems, notably Solaris, you cannot
> have multiple children doing an accept on the same socket. You have
> to use file locking to ensure that only one child can call accept at
> any particular moment."
>
> Is that still the case with Solaris 11?

It doesn't appear to have been the case for a long time:

https://blogs.oracle.com/pgdh/entry/how_not_to_load_balance1

--
Ian Collins

[James Kanze]

On Wednesday, March 13, 2013 7:55:33 PM UTC, Ian Collins wrote:
> James Kanze wrote:

[...]

> One advantage of popular cross-platform IDE like Eclipse and NetBeans is
> they do generate makefiles under the hood and (at least with NetBeans)
> those makefiles are designed to support hand editing. The IDE generated
> akefiles can also be use to run builds on remote hosts where running an
> IDE is impractical.

I'll have to give Eclipse another try. I did try it, and found
that while it might be OK for Java, it didn't handle C++ very
well, and it didn't integrate foreign editors (like vim) very
well (and like most IDE's, it's native editor was shit). That
was a long time ago, however, so those problems might be
solved.

Of course, when you've been using makefiles for a while, it
doesn't take much to write a new one; in the simplest cases, you
just define a macro with your sources, and include your master
makefile. And the ones generated by the IDE aren't probably
much use in the more complicated cases, where you have to build
the tool which generates some of your sources. (And of course,
this isn't even possible under VS; a single project can't build
an intermediate .exe needed to build the final .dll.)

--
James

[James Kanze]

On Wednesday, March 13, 2013 8:31:48 PM UTC, Balog Pal wrote:
> On 3/13/2013 4:55 PM, James Kanze wrote:
> > For production code, of course, the fact that you can't really
> > create arbitrary rules, like you can in a makefile, is
> > a problem. As is sharing "projects" between different
> > solutions, which use different compiler options. I've done it,
> > but it involves editing the project files by hand; at that
> > point, you're better off using makefiles, because the higher
> > level makefile can pass explicit information down to the project
> > file. (With VC++, you have to create rules conditioned on the
> > solution name.)

> I wonder where this comes -- MS switched to MsBuild a few years ago, and
> in that you can do about anything you could in a makefile. Yes, those
> who mastered makefiles already may be better off with that. Others are
> probably not, as for the sensible stuff it's ways simpler, and plays
> naturally with the IDE.

That's simply not true. There are so many things that one can
easily do in makefiles, but which are extremely complicated, if
not impossible, with MS's project and solution files (which is
what the IDE uses). Some examples of things you cannot do
in a Microsoft project:

- Build a local .exe to generate the code you need to compile
for the .dll the project is supposed to build. You have to
create a separate project for the .exe (even if it is build from
only a single .cpp). Which, of course, exposes an internal
detail of the project to everyone working on the solution.

- Use the same project in different solutions, with the
solution passing down information telling the project how to
configure itself. You can work around this somewhat, by using
conditionals in the project file, but it's awkward, since the
support for conditionals only supports full equality. You
can't make something conditional on a regular expression match
on the solution name, for example. And conditions on the
solution name are the only way you can make anything dependent
on the actual solution file.

Add to this that the VS compiler's error messages can be totally
useless when templates are involved. Not always, not even
usually, but from time to time, you'll get an error message
without the slightest indication of where the error is in *your*
sources. And the fact that you can't debug into code which was
compiled elsewhere, even if you have the sources. (I've
recently worked on a Python interface, and at times, it was
useful to step into the Python code, to see what Python was
expecting of me, and what I was doing wrong. The VS debugger
simply refused to do it; luckily, I had access to Linux box as
well, with gdb.)

> Certainly you CAN and definitely should share most rules -- that is done
> by creating .props and .targets files, and the .vcxproj should have only
> the file lists. Certainly any really specific options can be set (either
> per project or per file).

Certainly. That's what we do, and I've written Python scripts
to generate new projects, to ensure that every one stays on the
same page. (There are a few things, normally at the top, which
don't seem to work if you put them in at .props: the list of
project configurations, for example. Which was a pain when
I had to add support for 64 bits, but that's not something you
do every day.) But the problem remains: you cannot directly
push down information from the solution file (which in addition
uses GUIDs everywhere, rather than the names of anything, which
makes editing it by hand a real pain). Our .props files are
full of things like:

<attribute_name Condition=" '$(SolutionName)' == 'OneSolution' ">value</attribute_name>
<attribute_name Condition=" '$(SolutionName)' == 'DifferentSolution' ">different_value</attribute_name>
...

Every time we use the project in a new solution, we have to come
back and add it here.

> So all you write about is possible alright. I don't say it is trivial or
> nice but that same applies to make and probably most other build systems
> for big real-life projects.

It's true that most build systems are pretty bad: I've been
using GNU make, largely because I know it, but the make syntax
is horrible. Of the other systems I've tried, however, either
they don't have the support for some feature I need, or they're
simply broken.

The dependency checking in both Jam and VS is seriously broken:
VS fails when pre-build steps modify sources or headers (and
only allows one pre-build step per project, so you have to write
scripts to chain several together), and Jam fails when you use
things like:

#include GB_dependentInclude(syst,dependentSource.cc)

(where, of course, the underlying macros will change the path so
that dependentSource.cc will be found in a system dependent
directory---instead of syst, you could do arch, for architecture
dependent, or comp, for compiler dependent).

> > Bash syntax is a bit special, but the real problem is that the
> > individual tools aren't always coherent. You need to learn
> > several different variations of regular expressions, for
> > example. It's still an order of magnitude better than Perl, but
> > I tend to use Python for anything non-trivial today (unless it's
> > non-trivial enough to justify using C++).

> Yeah, me too -- IMO python beats why bother with old scripting stuff
> when it provides all the power, is portable and reads like a real
> language instead of emulating the old modem output before NO CARRIER. :->

So you've tried Perl as well. :-)

--
James

[Ian Collins]

James Kanze wrote:
> On Wednesday, March 13, 2013 7:55:33 PM UTC, Ian Collins wrote:
>> James Kanze wrote:
>
> [...]
>> One advantage of popular cross-platform IDE like Eclipse and NetBeans is
>> they do generate makefiles under the hood and (at least with NetBeans)
>> those makefiles are designed to support hand editing. The IDE generated
>> akefiles can also be use to run builds on remote hosts where running an
>> IDE is impractical.
>
> I'll have to give Eclipse another try. I did try it, and found
> that while it might be OK for Java, it didn't handle C++ very
> well, and it didn't integrate foreign editors (like vim) very
> well (and like most IDE's, it's native editor was shit). That
> was a long time ago, however, so those problems might be
> solved.

NetBeans C and C++ improved significantly once it became the IDE used by
Sun for their Studio IDE.

> Of course, when you've been using makefiles for a while, it
> doesn't take much to write a new one; in the simplest cases, you
> just define a macro with your sources, and include your master
> makefile. And the ones generated by the IDE aren't probably
> much use in the more complicated cases, where you have to build
> the tool which generates some of your sources. (And of course,
> this isn't even possible under VS; a single project can't build
> an intermediate .exe needed to build the final .dll.)

My point was that with NetBeans (and possibly Eclipse) the top level
makefile is only generated once and is designed for hand editing. I
often do exactly what you mention on Solaris, build the object files
used by dtrace probes, as part of my build process.

--
Ian Collins

[Balog Pal]

On 3/14/2013 6:34 PM, James Kanze wrote:
>> I wonder where this comes -- MS switched to MsBuild a few years ago, and
>> in that you can do about anything you could in a makefile. Yes, those
>> who mastered makefiles already may be better off with that. Others are
>> probably not, as for the sensible stuff it's ways simpler, and plays
>> naturally with the IDE.
>
> That's simply not true.

'True' is never so simple. :) Well, reading my words it is possible to
mean it too literally -- by "anything" I meant a practical approach, we
have many build sytems tuned for different things and ways of work, and
some weaknesses, but *able* to carry out processing any kind of inputs
to any kind of outputs using any kind of translators in between. In
actual work we normally bent to what our tools like rather than waste
much time on fighting a weakness. And IME it's way less terrible than it
looks unless build systems are changed every few months.

Yes, VS has a plenty of problems writing the project files (at least
VS2010 I use), like the property manager is just FUBAR due to bugs, and
the regular editor is obsessed to write the attributes for every config.
But the former is hardly ever needed and the latter is easy to overcome
-- and before checkin you look at diff anyway.

> There are so many things that one can
> easily do in makefiles, but which are extremely complicated, if
> not impossible, with MS's project and solution files (which is
> what the IDE uses). Some examples of things you cannot do
> in a Microsoft project:
>
> - Build a local .exe to generate the code you need to compile
> for the .dll the project is supposed to build. You have to
> create a separate project for the .exe (even if it is build from
> only a single .cpp). Which, of course, exposes an internal
> detail of the project to everyone working on the solution.

You just described how to solve the *build*. So it is not impossible,
right? All tools normally impose some way of organization. So you youse
two projects instead of one. Actually I can think of several ways to
work it around, but all look way too much hassle with an excessive
requirement (and one pretty moot with original comparison).

> - Use the same project in different solutions, with the
> solution passing down information telling the project how to
> configure itself. You can work around this somewhat, by using
> conditionals in the project file, but it's awkward, since the
> support for conditionals only supports full equality.

Well, it's indeed an overlook that you can't define macros and params
directly in .sln, but you can define them in several ways. And having a
.props file with the condition on solution name and defining them seem
not such a big difference to me.

> You
> can't make something conditional on a regular expression match
> on the solution name, for example.

I'm not so proficient in msbuild to provide actual counterexample code
but am 99% positive that claim is false. You can use a wide range of
string manipulation and other functions -- I do in practice. [it was a
year ago when I had to fix the build of or project]. I recall i could
use anything you can do with a C# String.

> And conditions on the
> solution name are the only way you can make anything dependent
> on the actual solution file.

I bet in practice you use the project in just a handful of solutions and
can figure out groups with just basic string ops if regex is really not
accessible -- what may well be.

> Add to this that the VS compiler's error messages can be totally
> useless when templates are involved. Not always, not even
> usually, but from time to time, you'll get an error message
> without the slightest indication of where the error is in *your*
> sources.

Yeah, that is plain pure PITA and shame on MS folks. Actually templates
are the better covered part -- but just have an error in a .h file, the
message will not tell how it was included or even which .cpp was being
compiled. (and it's braindead that /showincludes is option that modifies
the project rather than being part of env. Can be worked around somewhat
but still major WTF, especially as would need minimal work on the
implementation.)

I wish msvc had diagnostics on level of gcc. But it's the compiler issue
and has little to do with the IDE or the build.

(for template probblems remember that the 'error list' contains only one
line of info -- if you switch to output you (may) find more diagnostics
explaining the case, with navigation and whatever. )

> And the fact that you can't debug into code which was
> compiled elsewhere, even if you have the sources.

You what? You can attach to any process, and if one crashes you're
offered attach JIT. You can load symbols anytime and anywhere from
remote servers or collect them in your cache, or just ad hoc -- if you
have them certainly. (did you try right-click on gray lines in stack
trace and use Load symbols'?

Without symbols you're really limited to assy, but it may still be
better than nothing. And IIRC you can force to use source file even if
it is not the same as during compile at your own risk.

> (I've
> recently worked on a Python interface, and at times, it was
> useful to step into the Python code, to see what Python was
> expecting of me, and what I was doing wrong. The VS debugger
> simply refused to do it; luckily, I had access to Linux box as
> well, with gdb.)

Did you install the python extension to VS? I never tried a mix like you
describe but it definitely can walk on python separately.

>> Certainly you CAN and definitely should share most rules -- that is done
>> by creating .props and .targets files, and the .vcxproj should have only
>> the file lists. Certainly any really specific options can be set (either
>> per project or per file).
>
> Certainly. That's what we do, and I've written Python scripts
> to generate new projects, to ensure that every one stays on the
> same page. (There are a few things, normally at the top, which
> don't seem to work if you put them in at .props: the list of
> project configurations, for example.

I didn't have to mess with that part. IMO configuration should work if
you import the props early enough, but the IDE would likely not
recognize them. (It looks for some labels to decypher stuff and if you
stray from what it expects, it misreports some elements -- but they
still fork fine in the build.)

> Which was a pain when
> I had to add support for 64 bits, but that's not something you
> do every day.)

My observation is also that configurations are PITA -- and if you try to
mix C# with C++ in a solution it goes out of hand. Fortunately I could
weed out everything and just have a Debug and Release from the initial
mess. It's especially "nice" how solution creates a full matrix of
config and target.

Do I guess right that you tried to sidestep the mess by creating a copy
of the .sln and one use 32 and the other for 64 bit? I'd probably try
something like that.

> But the problem remains: you cannot directly
> push down information from the solution file (which in addition
> uses GUIDs everywhere, rather than the names of anything, which
> makes editing it by hand a real pain). Our .props files are
> full of things like:
>
> <attribute_name Condition=" '$(SolutionName)' == 'OneSolution' ">value</attribute_name>
> <attribute_name Condition=" '$(SolutionName)' == 'DifferentSolution' ">different_value</attribute_name>
> ...
>
> Every time we use the project in a new solution, we have to come
> back and add it here.

If you use some naming schema that fits with the available string
functions you can make it much simpler. I'd put .EndsWith("64") or
.IndexOf to locate substrings. That IMO could save most of the edits in
a practical system.

But even with the raw form,
compared to all the crap I face everyday I would not consider to mention
that as a minor nuisance. Yes, you have to configure the stuff somewhere
-- so have one file that maps solution names to a set of attribute
values, and the projects work with the latter. And include the mapper up
front.

Sure in my practice there's no proliferation of .sln files, others may
not be so fortunate.

http://msdn.microsoft.com/en-us/library/dd633440.aspx

And from hits like these
http://www.msbuildextensionpack.com/help/4.0.5.0/html/9c5401ed-6f55-089e-3918-2476c186ca66.htm
I'd think you can even extend the msbuild expressions.

>> So all you write about is possible alright. I don't say it is trivial or
>> nice but that same applies to make and probably most other build systems
>> for big real-life projects.
>
> It's true that most build systems are pretty bad: I've been
> using GNU make, largely because I know it, but the make syntax
> is horrible. Of the other systems I've tried, however, either
> they don't have the support for some feature I need, or they're
> simply broken.

I worked with several build systems and recall none that could be
figured out without massive reading, or that was simple to find out any
problem if it surfaced. So my general conclusion is that build is a
general life-sucker and I feel lucky if there's a guy around who can
manage it. :) Well, currently I'm out of that luck.

> The dependency checking in both Jam and VS is seriously broken:
> VS fails when pre-build steps modify sources or headers (and

Well, that one I would not call 'broken' but the specified way it does
things. IMO it is possible to make build fit that model.

> only allows one pre-build step per project, so you have to write
> scripts to chain several together),

All those steps are defined in some msbuild script file that can be
rewritten to your liking. Yes, I agree that the stock pre and postbuild
steps are extremely limited, and are just dropped in for simple things.
But it is not a msbuild restriction, rather like I claimed make is
broken because I didn't like some of the stock rules.

IIRC the stock steps DO have attribute to describe inputs and outputs
and if you use them correctly, the dependency will be considered. If you
jut modify files without telling the system that will go unnoticed.
However I recall in VS2010 the thing is bugged -- while specification
and even UI allows a list of outputs, only the first one is actually
considered. :-(((


My practical problem is not related to the theory of work at all -- I
keep source generation and other translation as solvable.

But I encounter buggy behavior with dependency output itself. (in the
intermediate folder files are created with inputs, outputs, command
lines, etc) On my machine I see some weird entries listed as
dependency, some nvidia drs.bin file belonging to the video driver.
Other time some .h files are missing from the list. With a small but
noticeable chance. Guess due to some race conditions like those
prevalent in the msdev IDE. Now THAT is something really nasty.

If you called this system not usable for that reason I'd not say a word
of objection.

[James Kanze]

On Thursday, 14 March 2013 22:36:16 UTC, Balog Pal wrote:
> On 3/14/2013 6:34 PM, James Kanze wrote:

[...]

> > There are so many things that one can easily do in
> > makefiles, but which are extremely complicated, if not
> > impossible, with MS's project and solution files (which is
> > what the IDE uses). Some examples of things you cannot do
> > in a Microsoft project:

> > - Build a local .exe to generate the code you need to compile
> > for the .dll the project is supposed to build. You have to
> > create a separate project for the .exe (even if it is build from
> > only a single .cpp). Which, of course, exposes an internal
> > detail of the project to everyone working on the solution.

> You just described how to solve the *build*. So it is not impossible,
> right? All tools normally impose some way of organization. So you youse
> two projects instead of one. Actually I can think of several ways to
> work it around, but all look way too much hassle with an excessive
> requirement (and one pretty moot with original comparison).

Adding projects right and left breaks encapsulation.

> > - Use the same project in different solutions, with the
> > solution passing down information telling the project how to
> > configure itself. You can work around this somewhat, by using
> > conditionals in the project file, but it's awkward, since the
> > support for conditionals only supports full equality.

> Well, it's indeed an overlook that you can't define macros and params
> directly in .sln, but you can define them in several ways. And having a
> .props file with the condition on solution name and defining them seem
> not such a big difference to me.

Yes. Project files seem to lack a few features, but The
solution files are literally from the middle ages.

> > You
> > can't make something conditional on a regular expression match
> > on the solution name, for example.

> I'm not so proficient in msbuild to provide actual counterexample code
> but am 99% positive that claim is false. You can use a wide range of
> string manipulation and other functions -- I do in practice. [it was a
> year ago when I had to fix the build of or project]. I recall i could
> use anything you can do with a C# String.

I'm basing my statement on the reference
(http://msdn.microsoft.com/en-us/library/7szfhaft.aspx). If
some form of regular expressions are supported, Microsoft isn't
documenting the syntax needed to use it. (In other contexts,
I'm sure that Microsoft supports regular expressions, but they
don't seem to provide a syntax for it here.)

> > And conditions on the
> > solution name are the only way you can make anything dependent
> > on the actual solution file.

> I bet in practice you use the project in just a handful of solutions and
> can figure out groups with just basic string ops if regex is really not
> accessible -- what may well be.

In practice, I have no idea what solution files are being used.
I deliver library components, which other groups merge into
their final product. I can't make an exhaustive list of all
solutions, because I don't even know all of my clients.

> > Add to this that the VS compiler's error messages can be totally
> > useless when templates are involved. Not always, not even
> > usually, but from time to time, you'll get an error message
> > without the slightest indication of where the error is in *your*
> > sources.

> Yeah, that is plain pure PITA and shame on MS folks. Actually templates
> are the better covered part -- but just have an error in a .h file, the
> message will not tell how it was included or even which .cpp was being
> compiled. (and it's braindead that /showincludes is option that modifies
> the project rather than being part of env. Can be worked around somewhat
> but still major WTF, especially as would need minimal work on the
> implementation.)

The problem with the .h file seems to be fixed in 2012. On the
other hand, VS parallelizes the builds, and error messages from
different projects are mixed in the output. For the moment, if
I can't find the error quickly, I'll copy paste the entire
output pane into vim, then run a Python script
(SortOutputByProject.py) over it, then search for error. Once
I know which project isn't building correctly, I can build only
it, and get some usable error output.

[...]

> > And the fact that you can't debug into code which was
> > compiled elsewhere, even if you have the sources.

> You what? You can attach to any process, and if one crashes you're
> offered attach JIT. You can load symbols anytime and anywhere from
> remote servers or collect them in your cache, or just ad hoc -- if you
> have them certainly. (did you try right-click on gray lines in stack
> trace and use Load symbols'?

This seems to be a regression in 2012; I do remember doing
something like what you describe in the past. But when I do
step into function on a Python function, it still steps over.

> Without symbols you're really limited to assy, but it may still be
> better than nothing.

It is. Even in g++, you can't get full symbolic debugging
without all of the symbols. But if you're familiar with the
compiler and the assembler, you can sort of match things up, and
see what's happening. (I'm not trying to debug Python. I'm
just trying to figure out where it's deciding that my input was
wrong.)

> And IIRC you can force to use source file even if
> it is not the same as during compile at your own risk.

With 2012, you have to. If there is a pre-build step, the
debugger always decides that the library isn't up to date.
(This definitely wasn't a problem in earlier versions.)

> >> Certainly you CAN and definitely should share most rules -- that is done
> >> by creating .props and .targets files, and the .vcxproj should have only
> >> the file lists. Certainly any really specific options can be set (either
> >> per project or per file).

> > Certainly. That's what we do, and I've written Python scripts
> > to generate new projects, to ensure that every one stays on the
> > same page. (There are a few things, normally at the top, which
> > don't seem to work if you put them in at .props: the list of
> > project configurations, for example.

> I didn't have to mess with that part. IMO configuration should work if
> you import the props early enough, but the IDE would likely not
> recognize them. (It looks for some labels to decypher stuff and if you
> stray from what it expects, it misreports some elements -- but they
> still fork fine in the build.)

It only seems to be an issue when you create new projects.
Except for VS completely rewriting your filter files whenever
you add or remove a file.

(There's another wierd thing in 2012: my pre-build step will
write the output to second file, the delete the original and
rename the second---not really necessary in this case, but old
habits die hard. Rather often, when I do this, VS looses the
generated file. The name still appears in the navigation pane,
but clicking on it gets you nowhere, and if there's an error in
the generated code, clicking on it is also does nothing. This
is definitely a regression; I never had any problems with this
in earlier versions.)

> > Which was a pain when
> > I had to add support for 64 bits, but that's not something you
> > do every day.)

> My observation is also that configurations are PITA -- and if you try to
> mix C# with C++ in a solution it goes out of hand. Fortunately I could
> weed out everything and just have a Debug and Release from the initial
> mess. It's especially "nice" how solution creates a full matrix of
> config and target.

> Do I guess right that you tried to sidestep the mess by creating a copy
> of the .sln and one use 32 and the other for 64 bit? I'd probably try
> something like that.

No, we have one .sln for both. I actually works pretty well,
but there were a few painful moments getting there.

> > But the problem remains: you cannot directly
> > push down information from the solution file (which in addition
> > uses GUIDs everywhere, rather than the names of anything, which
> > makes editing it by hand a real pain). Our .props files are
> > full of things like:

> > <attribute_name Condition=" '$(SolutionName)' == 'OneSolution' ">value</attribute_name>
> > <attribute_name Condition=" '$(SolutionName)' == 'DifferentSolution' ">different_value</attribute_name>
> > ...

> > Every time we use the project in a new solution, we have to come
> > back and add it here.

> If you use some naming schema that fits with the available string
> functions you can make it much simpler. I'd put .EndsWith("64") or
> .IndexOf to locate substrings. That IMO could save most of the edits in
> a practical system.

We do. The problem is that the conditionals only support ==, !=
and HasTrailingSlash for strings.

> But even with the raw form,
> compared to all the crap I face everyday I would not consider to mention
> that as a minor nuisance. Yes, you have to configure the stuff somewhere
> -- so have one file that maps solution names to a set of attribute
> values, and the projects work with the latter. And include the mapper up
> front.

> Sure in my practice there's no proliferation of .sln files, others may
> not be so fortunate.

> http://msdn.microsoft.com/en-us/library/dd633440.aspx

This seems to apply to the MSBuild framework, and not to the
project files; at least, it talks of tasks, which aren't present
in the .vcxproj files (at least not that I've seen).

--
James

[Andy Champ]

On 15/03/2013 17:18, James Kanze wrote:
> On the
> other hand, VS parallelizes the builds, and error messages from
> different projects are mixed in the output.

There's a pulldown at the top of the output window. If you change it
from "build" to "build order" it will split it by project.

Andy

[Nick Keighley]

On Mar 13, 3:55 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Saturday, 9 March 2013 11:34:28 UTC, Nick Keighley  wrote:
> > On Mar 6, 5:25 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > > I don't know.  I use Visual Studios 2012 (at present) under
> > > Windows, because that's my employers standard; I've always used
> > > vim, bash and makefiles under Unix.  And the vim, bash and
> > > makefiles environment is far more productive than the Visual
> > > Studios environment.
>
> > really? I've used both (well not vim). I've also used Qt Creator. I'd
> > like to see how you measure "productivity"
>
> Getting working code out of the door.  Actually, creating and
> maintaining working code effectively, for a complete definition
> of working code (i.e. maintainable, tested, documented...).

and what evidence do you have that this is easier with vim/bash/make
than VS? Just saying so isn't enough. As I say I've worked in both
environments I don't see the massive disparity you claim. I think
there's a little bit of unix bigotry.

> > > If you're just starting programming,
> > > something like Visual Studios is probably a pretty good idea, so
> > > you don't have to learn everything at once, just to compile
> > > hello world.
>
> > even compiling hello world is non-trivial with VS!
>
> You mean because you have to create a solution, with a project?

yep. And turn off a bunch of MS extensions and explain you want to use
ASCII and I think a couple of other things. Out of the box VS isn't a
C compiler.

> For anything more complex, the fact that you don't have to
> write a makefile is a win for a beginner.

not just beginners

ok. I think you have me! The last VS project I worked on we avoided
such things (probably because it was hard). The only thing that did do
this seemed to rebuild everytime even then it wasn't necessary.

> > If I want to process text I use Perl and tend to use it as a
> > scripting language as well (bash syntax drives me nuts) but VS seems
> > fine for most stuff.
>
> Bash syntax is a bit special, but the real problem is that the
> individual tools aren't always coherent.  You need to learn
> several different variations of regular expressions, for
> example.  It's still an order of magnitude better than Perl,

really? What tools? sed and awk and such like?

[Nick Keighley]

perhaps I need to look at Python again. I choose Perl for its
integration of regexps. It looked like the language awk should have
been to me.

[James Kanze]

On Saturday, March 16, 2013 2:00:54 PM UTC, Nick Keighley wrote:
> On Mar 13, 8:31 pm, Balog Pal <p...@lib.hu> wrote:

[...]

> > > Bash syntax is a bit special, but the real problem is that the
> > > individual tools aren't always coherent.  You need to learn
> > > several different variations of regular expressions, for
> > > example.  It's still an order of magnitude better than Perl, but
> > > I tend to use Python for anything non-trivial today (unless it's
> > > non-trivial enough to justify using C++).

> > Yeah, me too -- IMO python beats why bother with old scripting stuff
> > when it provides all the power, is portable and reads like a real
> > language instead of emulating the old modem output before NO CARRIER. :->

> perhaps I need to look at Python again. I choose Perl for its
> integration of regexps. It looked like the language awk should have
> been to me.

AWK is the language AWK should have been. AWK is an excellent
language for what it was designed to do, and I still use it a
lot. Mainly in interactive mode, today---for one liners from
the command line, AWK still beats anything else I've seen. I've
tried Perl at various times, and each time, went away
disgusted---it's probably the worst real language I've seen.
Python's pretty good (although the way it handles iteration is
really, really bad), but for one liners from the command line,
you still have to import too many libraries (like re), and
explicitly loop over the input. It's also very easy (but quite
verbose) to create plug-ins for Python.

--
James

[James Kanze]

On Saturday, March 16, 2013 1:58:14 PM UTC, Nick Keighley wrote:
> On Mar 13, 3:55 pm, James Kanze <james.ka...@gmail.com> wrote:
> > On Saturday, 9 March 2013 11:34:28 UTC, Nick Keighley  wrote:
> > > On Mar 6, 5:25 pm, James Kanze <james.ka...@gmail.com> wrote:

> > > > I don't know.  I use Visual Studios 2012 (at present) under
> > > > Windows, because that's my employers standard; I've always used
> > > > vim, bash and makefiles under Unix.  And the vim, bash and
> > > > makefiles environment is far more productive than the Visual
> > > > Studios environment.

> > > really? I've used both (well not vim). I've also used Qt Creator. I'd
> > > like to see how you measure "productivity"

> > Getting working code out of the door.  Actually, creating and
> > maintaining working code effectively, for a complete definition
> > of working code (i.e. maintainable, tested, documented...).

> and what evidence do you have that this is easier with vim/bash/make
> than VS? Just saying so isn't enough. As I say I've worked in both
> environments I don't see the massive disparity you claim. I think
> there's a little bit of unix bigotry.

Personal experience. And I do know Windows and VS now.
Originally, I put my lower productivity under Windows down to
the fact that I wasn't familar with it. Now, it's gotten to the
point where every time I want to do something, I can't find the
proper support in VS, and none of the so called experts seem to
know how to do it either---they often seem surprised that such
things actually can be done.

> > > > If you're just starting programming,
> > > > something like Visual Studios is probably a pretty good idea, so
> > > > you don't have to learn everything at once, just to compile
> > > > hello world.

> > > even compiling hello world is non-trivial with VS!

> > You mean because you have to create a solution, with a project?

> yep. And turn off a bunch of MS extensions and explain you want to use
> ASCII and I think a couple of other things. Out of the box VS isn't a
> C compiler.

Out of the box, neither is g++, nor Sun CC. The difference is,
perhaps, that in the Unix world, you expect to have to actually
read the compiler documentation, and determine what options you
need for your project. VS pops up with two default
configurations (Debug and Release), neither of which really
corresponds to what you might want to do in most cases. (My
personal libraries are developed with with something like eight
different configurations: optimized or not, profiling or not,
multi-threaded or not.)

> > For anything more complex, the fact that you don't have to
> > write a makefile is a win for a beginner.

> not just beginners

It's a lot like C++. When you being, you're overwhelmed by how
much you need to know. With a little experience, however,
you've got a good tool set for your style of programming, and a
number of more or less standard idioms, and you can knock out
complex programs in very little time.

*Not* generating significant amounts of code by machine results
in an enormous loss of productivity. I'd have to go back 25 or
30 years to find a project in which there wasn't a lot of
machine generated code. Why should I waste my time doing things
the machine can do better?

> > > If I want to process text I use Perl and tend to use it as a
> > > scripting language as well (bash syntax drives me nuts) but VS seems
> > > fine for most stuff.

> > Bash syntax is a bit special, but the real problem is that the
> > individual tools aren't always coherent.  You need to learn
> > several different variations of regular expressions, for
> > example.  It's still an order of magnitude better than Perl,

> really? What tools? sed and awk and such like?

Sed, awk and grep are the three standard ones. Each of which
has a subtly different form of regular expressions. (In the
case of grep, of course, there's grep, egrep and fgrep, each
with a different version of regular expressions.)

Once it gets too complicated to just type in at the command line
(say after about 10 lines of code), I'll switch to Python. It's
a bit of a shame that you need boilerplate to get os, sys and re
(since I almost always need them), and having to explicity loop
over each line (rather than implicitly, and is sed and awk)
makes for an extra line or two, but on the whole, it still
works pretty well.

Under Windows, I'll also use Python sometimes when C++ would be
better, simply to avoid having to create an extra project, and
project dependencies, just to get an .exe to generate my code.

--
James

[woodb...@gmail.com]

On Saturday, March 16, 2013 4:42:03 PM UTC, James Kanze wrote:
>
>
>
> Under Windows, I'll also use Python sometimes when C++ would be
>
> better, simply to avoid having to create an extra project, and
>
> project dependencies, just to get an .exe to generate my code.
>

I suggest to bite the bullet in those cases. Long term
you'll be glad you did.

[James Kanze]

If it were just me...

The problem is that I'm producing low level support libraries,
which are used in a number of different solutions. If I
introduce an additional project (and I have in some cases), it
means that all of the solutions which use my library have to be
sure to add the correct dependencies. (The usual way of
specifying dependencies in VS is in the solution file. We've
been trying to wean people from this, and get them to use
references, rather than what VS calls dependencies, but it is
slow business.)

--
James

[Balog Pal]

On 3/16/2013 5:42 PM, James Kanze wrote:
>>>> really? I've used both (well not vim). I've also used Qt Creator. I'd
>>>> like to see how you measure "productivity"
>
>>> Getting working code out of the door. Actually, creating and
>>> maintaining working code effectively, for a complete definition
>>> of working code (i.e. maintainable, tested, documented...).
>
>> and what evidence do you have that this is easier with vim/bash/make
>> than VS? Just saying so isn't enough. As I say I've worked in both
>> environments I don't see the massive disparity you claim. I think
>> there's a little bit of unix bigotry.
>
> Personal experience. And I do know Windows and VS now.
> Originally, I put my lower productivity under Windows down to
> the fact that I wasn't familar with it. Now, it's gotten to the
> point where every time I want to do something, I can't find the
> proper support in VS, and none of the so called experts seem to
> know how to do it either---they often seem surprised that such
> things actually can be done.

I have the same personal experience in the opposite direction. Though
that makes me stop the claims in either way, rather conclude that some
people are way more productive than others; and by all means shall be
left alone to use their tools, whatever those are.

A claim like "now I'm familiar" makes me even more skeptic -- I
personally keep finding better tools I missed every few weeks despite
working with VS for 2+ decades.

> The difference is,
> perhaps, that in the Unix world, you expect to have to actually
> read the compiler documentation, and determine what options you
> need for your project.

It's not a difference. You're supposed to know the walk and the talk.
Yet I see majority of people around never bother, just poke around and
experiment on the fly. Then draw conclusion on the system they use.
Independently on the environment.

> VS pops up with two default
> configurations (Debug and Release), neither of which really
> corresponds to what you might want to do in most cases.

IME that makes perfect sense for most things, and proliferation of
configs is suspicious at best. While there are plenty of examples to
handle different config options inside the module -- along with checks
or alterations of settings. As you can do much with #pragma, and from
outside use just define-s.

> (My
> personal libraries are developed with with something like eight
> different configurations: optimized or not, profiling or not,
> multi-threaded or not.)

For libs it makes more sense, though to me profiling looks like a local
alteration rather than a config -- and ST I think I just never used --
does it have any actual advantage?

But AFAIK it is not hard to save your project as an appwizard template
so once you created your prototype with the 8 configs, can use it for
all subsequent projects.

>>> For anything more complex, the fact that you don't have to
>>> write a makefile is a win for a beginner.
>
>> not just beginners
>
> It's a lot like C++. When you being, you're overwhelmed by how
> much you need to know. With a little experience, however,
> you've got a good tool set for your style of programming, and a
> number of more or less standard idioms, and you can knock out
> complex programs in very little time.

Yeah, but complex need not mean a certain way. I.e. code generation can
be used put in the build through a translator or a prebuild step -- but
you may just run it by hand and put the result in the sources directly.
Depending on the change probability the latter may be ways more
efficient. And simpler.
On windows the most prevalent generation step is related to COM, but
it's supported internally through #import. So you can travel many miles
before even the old-style, way limited VS project management becomes
insufficient.

The need to use makefile usually comes from non-native requirements,
cross-platform projects or people coming from other realm and bending
the system to their familiar way.

>>> If you limit yourself to the IDE, just about anything useful.
>>> Try creating a project in which several different sources are
>>> generated from other programs. There's special mechanism for
>>> the case where a single source and header are generated by
>>> a single tool (e.g. lex and yacc), and you can have one (but
>>> only one) pre-build step. But the build system doesn't
>>> understand any dependencies created by the pre-build, and if you
>>> want two or more operations, you have to wrap them into some
>>> sort of script. (The fact that the build system decides what
>>> needs recompiling *before* doing the pre-build is a serious
>>> error, since the purpose of the pre-build is normally to
>>> regenerate some files.)
>
>> ok. I think you have me! The last VS project I worked on we avoided
>> such things (probably because it was hard).

Or not really necessary. :) Actually with the msbuild-based way it's
not that hard, and examples can be found in OS projects.

>> The only thing that did do
>> this seemed to rebuild everytime even then it wasn't necessary.

Guess you did not specify inputs/outputs correctly. ;)

> *Not* generating significant amounts of code by machine results
> in an enormous loss of productivity. I'd have to go back 25 or
> 30 years to find a project in which there wasn't a lot of
> machine generated code. Why should I waste my time doing things
> the machine can do better?

IMO that should depend on the project nature. And with C++ you have a
plenty of internal mechanisms that work fine generating code (macros,
templates). The cases I recall related to generation had their substrate
changing only once in 2-4 weeks (database schema, XSD, message
descriptions), so executing the translators by hand was perfectly fair
game. And imposing it on every build be a waste of resources.

> Sed, awk and grep are the three standard ones.

And with VS you have most of their use cases built-in. in advanced form
too, as you can select for scope "all files in project/solution" tuned
with extensions -- a thing that is hardly trivial from command line.

And hopefully everyone is aware of the native win32 build of all the gnu
tools that work fine from windoze command line -- and where the shell
rules are needed the easiest is to summon a git bash :)

[Balog Pal]

On 3/16/2013 11:27 PM, James Kanze wrote:
> The problem is that I'm producing low level support libraries,
> which are used in a number of different solutions. If I
> introduce an additional project (and I have in some cases), it
> means that all of the solutions which use my library have to be
> sure to add the correct dependencies. (The usual way of
> specifying dependencies in VS is in the solution file. We've
> been trying to wean people from this, and get them to use
> references, rather than what VS calls dependencies, but it is
> slow business.)

Hm, IMO using the 'project dependencies' is a thing that should be
banned (except for C# mix and similar handicapped stuff). And project
reference be the only allowed way.

[Balog Pal]

On 3/15/2013 6:18 PM, James Kanze wrote:
>> I'm not so proficient in msbuild to provide actual counterexample code
>> but am 99% positive that claim is false. You can use a wide range of
>> string manipulation and other functions -- I do in practice. [it was a
>> year ago when I had to fix the build of or project]. I recall i could
>> use anything you can do with a C# String.
>
> I'm basing my statement on the reference
> (http://msdn.microsoft.com/en-us/library/7szfhaft.aspx).

That is certainly true, but only half of it. The condition itself is
only == but you can use expressions with lhs and rhs.

> If
> some form of regular expressions are supported, Microsoft isn't
> documenting the syntax needed to use it.

Just try the expressions I referred to in previous post. I definitely
used them in my common .props -- could post example from a different
machine only.

>>> And conditions on the
>>> solution name are the only way you can make anything dependent
>>> on the actual solution file.
>
>> I bet in practice you use the project in just a handful of solutions and
>> can figure out groups with just basic string ops if regex is really not
>> accessible -- what may well be.
>
> In practice, I have no idea what solution files are being used.

Well, I see your case from the other branch -- indeed it has some
challenges.

> I deliver library components, which other groups merge into
> their final product. I can't make an exhaustive list of all
> solutions, because I don't even know all of my clients.

I recall two approaches for such situations. One compiles the component
in several versions, distribute the binaries (that have suffixes for
versions) and .h, the latter has magic to figure out the proper variant
and sets it as defaultlib.

The other is to compile from source -- with that it is natural
expectation to follow all the prescribed steps to add the project or
project group.

And here it's possible to map configs in the build manager -- the
solution has the usual 2 (debug/release), and for your project selects
the desired variant of the 8).

> The problem with the .h file seems to be fixed in 2012.

Wow at least some progress in a decade.

> On the
> other hand, VS parallelizes the builds, and error messages from
> different projects are mixed in the output.

You have Build and Build order variant for the output window. (in
regular workflow it's rarely needed, enter a failed build I hit the
"build-project only" variant immediately.

> For the moment, if
> I can't find the error quickly, I'll copy paste the entire
> output pane into vim, then run a Python script
> (SortOutputByProject.py) over it, then search for error. Once
> I know which project isn't building correctly, I can build only
> it, and get some usable error output.

The project itself is properly noted in the 'error list' that should be
the primary source of navigation, output is only for the weird cases.
There's a convenient option to auto-switch error list on errors too.

> It only seems to be an issue when you create new projects.
> Except for VS completely rewriting your filter files whenever
> you add or remove a file.

It rewrites everything. Fortunately Git Extensions provide convenient
way to reset unintended lines from change or post-edit the file.

>> If you use some naming schema that fits with the available string
>> functions you can make it much simpler. I'd put .EndsWith("64") or
>> .IndexOf to locate substrings. That IMO could save most of the edits in
>> a practical system.
>
> We do. The problem is that the conditionals only support ==, !=
> and HasTrailingSlash for strings.

Do you say '$(solutionname).Endswith("64")' == 'true' does not work?

>> But even with the raw form,
>> compared to all the crap I face everyday I would not consider to mention
>> that as a minor nuisance. Yes, you have to configure the stuff somewhere
>> -- so have one file that maps solution names to a set of attribute
>> values, and the projects work with the latter. And include the mapper up
>> front.
>
>> Sure in my practice there's no proliferation of .sln files, others may
>> not be so fortunate.
>
>> http://msdn.microsoft.com/en-us/library/dd633440.aspx
>
> This seems to apply to the MSBuild framework, and not to the
> project files; at least, it talks of tasks, which aren't present
> in the .vcxproj files (at least not that I've seen).

The vcxproj file is just a top level thing that includes the real
content from other .props and .targets files. You probably should read
the Microsoft.Cpp.targets to see how the build is arranged (including
details of prebuild step), then add your own .targets that define your
code generator in the native way, dropping prebuild madness for good.

[Balog Pal]

On 3/17/2013 3:14 PM, Balog Pal wrote:
> On 3/15/2013 6:18 PM, James Kanze wrote:
>> We do. The problem is that the conditionals only support ==, !=
>> and HasTrailingSlash for strings.
>
> Do you say '$(solutionname).Endswith("64")' == 'true' does not work?

And if it doesn't directly for any reason, you can use a property to do
the job. I.e. I have in a propertygroup:

<PROJ_UPPER>$(projectname.Replace(' ','_').ToUpper())</PROJ_UPPER>
that is later used as $(PROJ_UPPER) for useful things.

In a similar way you can set properties derived from solutionname and
use them in the conditions.

[James Kanze]

On Sunday, 17 March 2013 14:14:54 UTC, Balog Pal wrote:
> On 3/15/2013 6:18 PM, James Kanze wrote:

> >> I'm not so proficient in msbuild to provide actual counterexample code
> >> but am 99% positive that claim is false. You can use a wide range of
> >> string manipulation and other functions -- I do in practice. [it was a
> >> year ago when I had to fix the build of or project]. I recall i could
> >> use anything you can do with a C# String.

> > I'm basing my statement on the reference
> > (http://msdn.microsoft.com/en-us/library/7szfhaft.aspx).

> That is certainly true, but only half of it. The condition itself is
> only == but you can use expressions with lhs and rhs.

[reordered...]

> Do you say '$(solutionname).Endswith("64")' == 'true' does not work?

Brilliant. That is exactly what I was looking for. In
practice, I have two known variants I have to support, one of
whose solution files always ends with a common string. (There's
still the third party library issues, but generally, they should
be using the other variant&mdash;there is one which even uses
a completely different version of Visual Studios, but they
accept that they're on their own there, and I do document what
I've done, so that they can duplicate the effects if they need
them) So basically, I'll end up with something like:

<MyAttribute Condition="'$(solutionname).Endswith("ABC")' == 'true'>for IFG</MyAttribute>
<MyAttribute Condition="'$(MyAttribute)' == ''>not for IFG</MyAttribute>

(The set of solutions whose name ends with "ABC" is open, and
has been added to more than once. This used to be a pain, but
I think you've given me the solution. A thousand thanks.)

[...]

> Well, I see your case from the other branch -- indeed it has some
> challenges.

Yes. What I can do, sort of, however, is impose naming
conventions and suggest default configurations (which we know
work). Beyond that... different groups who want to do just
anything are sort of on their own anyway. We can't test that
the code works in a configuration we've never heard about.

> > I deliver library components, which other groups merge into
> > their final product. I can't make an exhaustive list of all
> > solutions, because I don't even know all of my clients.

> I recall two approaches for such situations. One compiles the component
> in several versions, distribute the binaries (that have suffixes for
> versions) and .h, the latter has magic to figure out the proper variant
> and sets it as defaultlib.

> The other is to compile from source -- with that it is natural
> expectation to follow all the prescribed steps to add the project or
> project group.

Our solution has been for the clients to integrat our library
into their solution files, and compile from source. I don't
really agree with this&mdash;I think it would make sense to
establish a company wide policy with regards to what variants we
support, and how we deliver them (generally in a separate
directory for the DLLs, and of course, the headers are
independent of this). But for various reasons, this doesn't fly
politically.

> And here it's possible to map configs in the build manager -- the
> solution has the usual 2 (debug/release), and for your project selects
> the desired variant of the 8).

We are actually moving to supporting thre configurations. It
turns out that when you have iterator debugging active, some of
parts of the library are so slow that you cannot effectively
debug with real data sets. (You can't debug if it takes you four
hours to reach a breakpoint.) So our debug builds have iterator
debugging disactivated (which in turn means that until VS 2010,
we couldn't use std::string). Still, we've seen more than a few
problems which would have been caught immediatly by iterator
debugging. (Including one case where end() was dereferenced,
which caused one, and only one machine to give wrong results.)
So we want two different Debug configurations, one for tracking
down errors that only show up with real data, and another with
iterator debugging (which hopefully will cause most such cases
to show up in our test suite).

[...]

> > Except for VS completely rewriting your filter files whenever
> > you add or remove a file.

> It rewrites everything. Fortunately Git Extensions provide convenient
> way to reset unintended lines from change or post-edit the file.

We're not using git, but I would like to see a Subversion plugin
used to rewrite the filter file. (It's easy to do---just throw
out all of the ItemGroup except the first.)

[...]

> The vcxproj file is just a top level thing that includes the real
> content from other .props and .targets files. You probably should read
> the Microsoft.Cpp.targets to see how the build is arranged (including
> details of prebuild step), then add your own .targets that define your
> code generator in the native way, dropping prebuild madness for good.

I'm aware of the .props. I'll have to look into the .targets.
Maybe that's the answer.

And thanks again for the tip with regards to how to use the
expressions in a conditional. That's already made my life
significantly simpler.

--
James

[James Kanze]

On Monday, 18 March 2013 14:10:46 UTC, James Kanze wrote:
> On Sunday, 17 March 2013 14:14:54 UTC, Balog Pal wrote:

> > Do you say '$(solutionname).Endswith("64")' == 'true' does not work?

> Brilliant.

Except that it doesn't work. This is part of the definition of
a property:

<MyProp Condition=" '$(SolutionName).Endswith("ABC")' == 'true' ">xxx</MyProp>

VS won't load the file&mdash;from the error message (something
about token ABC not acceptable), I gather that it doesn't like
the " character in the condition. I've tried replacing the
"ABC" with &quot;ABC&quot;. In that case, the solution loads
correctly (this is in a property file included in almost all of
the projects in the solution), but the condition is never
met&mdash;MyProp is never xxx.

I'm probably missing something obvious, but I can't find it in
the Microsoft documentation.

--
James

[Tobias Müller]

Balog Pal <pa...@lib.hu> wrote:
> Hm, IMO using the 'project dependencies' is a thing that should be banned
> (except for C# mix and similar handicapped stuff). And project reference
> be the only allowed way.

In VS 2005, 'project dependencies' were the only possible way C++ projects.

Specifying dependencies in the solution has also advantages, especially if
multiple libraries share the same interface. You can then compile and link
against different libraries in different solutions.

But in 99% of the cases project 'references' are what you want. But I don't
understand why the referenced projects are not implicitly added to the
solution.

Tobi

[Balog Pal]

On 3/18/2013 3:48 PM, James Kanze wrote:
> On Monday, 18 March 2013 14:10:46 UTC, James Kanze wrote:
>> On Sunday, 17 March 2013 14:14:54 UTC, Balog Pal wrote:
>
>>> Do you say '$(solutionname).Endswith("64")' == 'true' does not work?
>
>> Brilliant.
>
> Except that it doesn't work. This is part of the definition of
> a property:
>
> <MyProp Condition=" '$(SolutionName).Endswith("ABC")' == 'true' ">xxx</MyProp>

That's what I hinted in the other message -- I guess the quotes cause
the problem. But the simple workaround must work fine:

<MyPropTest>'$(SolutionName).Endswith("ABC")</MyPropTest>
...
<MyProp Condition=" '$(MyPropTest)' == 'true' ">xxx</MyProp>

> VS won't load the file&mdash;from the error message (something
> about token ABC not acceptable), I gather that it doesn't like
> the " character in the condition. I've tried replacing the
> "ABC" with &quot;ABC&quot;. In that case, the solution loads
> correctly (this is in a property file included in almost all of
> the projects in the solution), but the condition is never
> met&mdash;MyProp is never xxx.
>
> I'm probably missing something obvious, but I can't find it in
> the Microsoft documentation.

My guess is the grammar is simplistic, so quotes are hosed. But as
there's no limit on properties, should not matter so much.

[pasa]

On Mar 18, 3:48 pm, James Kanze <james.ka...@gmail.com> wrote:
> > > Do you say '$(solutionname).Endswith("64")' == 'true' does not work?
>

> Except that it doesn't work.

I tried this sln.props:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/
developer/msbuild/2003">
<PropertyGroup Label="UserMacros">
<SLNU>$(SolutionName.ToUpper())</SLNU>
<ST1>$(SolutionName.EndsWith("st"))</ST1>
<ST2>$(SolutionName.EndsWith("ab"))</ST2>
<ST3>$(SolutionName.IndexOf("vs"))</ST3>
<ST4>$(SolutionName.IndexOf("ab"))</ST4>
</PropertyGroup>

<ItemDefinitionGroup>
<ClCompile>
<PreprocessorDefinitions>SLN="$(SLNU)";ST1="$(ST1)";ST2="$
(ST2)";ST3="$(ST3)";ST4="$(ST4)";%(PreprocessorDefinitions)</
PreprocessorDefinitions>
<PreprocessorDefinitions Condition="'$
(ST1)'=='True'">COND1="First";%(PreprocessorDefinitions)</
PreprocessorDefinitions>
<PreprocessorDefinitions Condition="'$(ST1)'!
='True'">COND1="Not First";%(PreprocessorDefinitions)</
PreprocessorDefinitions>
<PreprocessorDefinitions Condition="'$(ST3)'!='-1'">COND2="vs
found";%(PreprocessorDefinitions)</PreprocessorDefinitions>
<PreprocessorDefinitions Condition="'$(ST3)'=='-1'">COND2="vs
not found";%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ClCompile>
</ItemDefinitionGroup>

</Project>

included in a project, in pvst.sln and abab.sln -- works fine and
changes the options as expected

[woodb...@gmail.com]

On Friday, March 8, 2013 2:01:51 AM UTC-6, Ian Collins wrote:
>
> In my opinion Solaris (and the numerous OpenSolaris derivatives) have
>
> better developer tools than Linux, especially for analysing applications
>
> (and the OS) in a production0n environment.
>
>

I asked about this subject on a Linux newsgroup
here in Minnesota. Here's the reply from Florin Lucha.

Dtrace is a better system performance evaluation tool, and that's
about the only thing that *Solaris has 'better' than Linux at this
point. The Sun^WOracle Studio C/C++ compilers runs just fine under
Linux as well, if you need second set of diagnostics (it usually helps
to keep code clean and portable).

I used to run it in a KVM virtual machine, just for testing purposes.
I tried to run it on bare metal, but the lack of hardware support
reminds me of Linux circa '97. Case in point, I have motherboard
(EVGA with dual onboard Gigabit 3COM/Marvell controllers) that Linux
runs smoothly on. Solaris works as well, and even has driver for the
family of NICs that include my particular model, but my NICs PCI ids
are blacklisted due to some bug that was sitting in a bugzilla for two
years. It did not reach critical mass with enthusiasts so it does
have a bleak future for hobbyists.

OpenSolaris is slowly becoming like MacOS - it only runs on certain
hardware configurations. The 'uber' UNIX hackers at Sun wanted to
keep all the goodness for themselves... now, they can have it, since
nobody else can run it, should they want to. The *BSDs have much
better hardware support.

-------------------------------------------------

[Ian Collins]

woodb...@gmail.com wrote:
> On Friday, March 8, 2013 2:01:51 AM UTC-6, Ian Collins wrote:
>>
>> In my opinion Solaris (and the numerous OpenSolaris derivatives) have
>>
>> better developer tools than Linux, especially for analysing applications
>>
>> (and the OS) in a production0n environment.
>>
>>
>
> I asked about this subject on a Linux newsgroup
> here in Minnesota. Here's the reply from Florin Lucha.
>
> Dtrace is a better system performance evaluation tool, and that's
> about the only thing that *Solaris has 'better' than Linux at this
> point. The Sun^WOracle Studio C/C++ compilers runs just fine under
> Linux as well, if you need second set of diagnostics (it usually helps
> to keep code clean and portable).

DTrace can make a big difference and is one of the main reasons we (my
clients and I) use Solaris bases OSs. Being able to probe a running
application without having to restart or mess about with logging levels
is a huge win. It also helps keep the source free of messy logging
code. An excellent real world example is PostgeSQL:

https://wiki.postgresql.org/wiki/DTrace

> OpenSolaris is slowly becoming like MacOS - it only runs on certain
> hardware configurations. The 'uber' UNIX hackers at Sun wanted to
> keep all the goodness for themselves... now, they can have it, since
> nobody else can run it, should they want to. The *BSDs have much
> better hardware support.

It runs on just about anything modern and I always fit a decent NIC if
the motherboard has a grotty one...

--
Ian Collins